سیم اوریجن پالیسی اور ویب پراکسی: ایک تکنیکی سیکیورٹی تجزیہ

جب ہم نے ProxyOrb بنایا تو ہمیں ہر ڈیزائن فیصلے پر ایک بنیادی تضاد کا سامنا کرنا پڑا: ایک ویب پراکسی سیکیورٹی اس لیے کام کرتی ہے کیونکہ وہ براؤزر کو یہ یقین دلاتی ہے کہ تھرڈ پارٹی کا کانٹینٹ سیم اوریجن کانٹینٹ ہے۔ یعنی بنیادی طور پر یہ براؤزر کے کور سیکیورٹی ماڈل کو دھوکہ دینا ہے۔ لیکن جدید براؤزرز نے پندرہ سال سے اس قسم کی اوریجن کنفیوژن کے خلاف تہہ در تہہ سخت ترین دفاع تعمیر کیے ہیں۔

یہ آرٹیکل اس کشمکش کو بنیادی اصولوں سے دیکھتا ہے۔ اگر آپ ایک سیکیورٹی ریسرچر، پینیٹریشن ٹیسٹر، یا براؤزر سیکیورٹی انجینئر ہیں جو یہ جاننا چاہتے ہیں کہ ویب پراکسی سرور دراصل سیم اوریجن پالیسی کے ساتھ کیسے تعامل کرتی ہیں — نہ صرف تصوراتی سطح پر بلکہ HTTP ہیڈرز، Chromium سورس کوڈ، اور پروڈکشن انجینئرنگ ٹریڈ آفس کی سطح پر — تو یہ آرٹیکل آپ کے لیے ہے۔

ہم SOP کی بنیاد، URL ری رائٹنگ، CORS، CORB/CORP، COEP/COOP، Service Workers، iframes، اور پراکسی آپریٹرز اور ان کے صارفین دونوں کے لیے سیکیورٹی مضمرات پر بات کریں گے۔

۱۔ سیم اوریجن پالیسی کی بنیاد

سیم اوریجن پالیسی (SOP) تین عناصر سے مل کر بنتی ہے: scheme + host + port۔ دو URLs تبھی سیم اوریجن ہوتے ہیں جب تینوں اجزا بالکل ایک جیسے ہوں۔ https://example.com:443 اور http://example.com:80 کراس اوریجن ہیں، چاہے وہ ایک ہی سرور کی طرف اشارہ کریں۔

جو بات اکثر غلط سمجھی جاتی ہے وہ یہ ہے کہ SOP دراصل کیا روکتی ہے بمقابلہ کیا اجازت دیتی ہے۔ SOP نہیں روکتی:

• اوریجنز کے پار امیجز لوڈ کرنا (<img src>)
• اوریجنز کے پار اسکرپٹس لوڈ کرنا (<script src>)
• اوریجنز کے پار اسٹائل شیٹس لوڈ کرنا (<link rel="stylesheet">)
• اوریجنز کے پار iframes ایمبیڈ کرنا (البتہ ایمبیڈڈ ڈاکیومنٹ کا کانٹینٹ آئسولیٹڈ رہتا ہے)
• اوریجنز کے پار فارم سبمیشنز بھیجنا (<form action>)

SOP جو روکتی ہے وہ یہ ہے کہ fetch() یا XMLHttpRequest کے ذریعے کی گئی کراس اوریجن ریکوئسٹس کے ریسپانس کو پڑھنا۔ ریکوئسٹ جاتی ہے — نیٹ ورک راؤنڈ ٹرپ ہوتا ہے — لیکن ریسپانس باڈی اور ہیڈرز کسی مختلف اوریجن میں چلنے والے JavaScript سے چھپا لیے جاتے ہیں۔

یہ فرق ویب پراکسیز کے لیے انتہائی اہمیت رکھتا ہے۔ پراکسی کا پورا کام یہ ہے کہ دو اوریجنز (پراکسی سرور اور ٹارگٹ سرور) کو ایک میں ملا دے، کراس اوریجن باؤنڈری کو ختم کر دے۔ جب تمام ریسورسز https://proxyorb.com سے آتے دکھتے ہیں، تو براؤزر کی SOP پر مبنی ریسپانس پڑھنے کی پابندیاں لاگو ہی نہیں ہوتیں۔

وہ "جائز جگہ" جسے ویب پراکسیز استعمال کرتی ہیں وہ URL ری رائٹنگ ہے: https://example.com/api/data کی بجائے ہر ریکوئسٹ https://proxyorb.com/api/data?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ== بن جاتی ہے۔ براؤزر کے نقطہ نظر سے یہ سیم اوریجن ریکوئسٹ ہے۔ SOP کو بائی پاس نہیں کیا گیا — اسے تمام کانٹینٹ کے ظاہری اوریجن کو بدل کر غیر متعلق کر دیا گیا ہے۔

۲۔ ProxyOrb کا URL ری رائٹنگ آرکیٹیکچر

سیکیورٹی مضمرات سمجھنے کے لیے آپ کو انکوڈنگ میکانزم سمجھنا ہوگا۔ ProxyOrb ایک URL پیرامیٹر __pot (proxy origin token) استعمال کرتا ہے جس میں ٹارگٹ اوریجن Base64 انکوڈ ہوتا ہے۔

__pot پیرامیٹر

پیرامیٹر __pot ہمیشہ ٹارگٹ کا اوریجن (scheme + host، کوئی path نہیں) انکوڈ کرتا ہے، نہ کہ پوری URL۔ اس کا مطلب ہے کہ https://example.com/some/deep/path?foo=bar اور https://example.com/other/page دونوں ایک ہی __pot ویلیو جنریٹ کرتے ہیں: aHR0cHM6Ly9leGFtcGxlLmNvbQ== (https://example.com کا Base64 انکوڈنگ)۔ اصل path اور query string پراکسی URL کے اپنے path اور query string میں بعینہ محفوظ رہتے ہیں۔

جب کوئی صارف https://proxyorb.com/?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ== پر جاتا ہے، گیٹ وے اسے ڈی کوڈ کر کے اصل URL دوبارہ بناتا ہے:

-- Gateway pseudocode: decoding the proxy request

function resolve_original_url(proxy_url):
    pot_value = parse_query_param(proxy_url, "__pot")
    if not pot_value:
        return error("Missing origin token")

    original_origin = base64_decode(pot_value)
    -- e.g. "https://example.com"

    validate_not_private_ip(original_origin)  -- SSRF protection

    -- Replace the proxy host with the target host, keep path/query intact
    original_url = replace_origin(proxy_url, original_origin)
    return original_url

پھر گیٹ وے ریکوئسٹ کو اصل ٹارگٹ سرور کو فارورڈ کرتا ہے، Origin ہیڈر ری رائٹ کرتا ہے تاکہ اپ اسٹریم سرور پراکسی ڈومین کی بجائے اپنا ڈومین دیکھے:

-- Set outbound headers toward the target server

request.headers["Host"]   = target_host
request.headers["Origin"] = target_origin   -- e.g. "https://example.com"
-- Remove all internal proxy headers before forwarding

Service Worker کے ذریعے کلائنٹ سائڈ URL ری رائٹنگ

گیٹ وے سرور سائڈ سنبھالتا ہے۔ کلائنٹ سائڈ — HTML، JavaScript، اور CSS ریسپانسز میں URLs ری رائٹ کرنا تاکہ تمام سب ریکوئسٹس پراکسی سے گزرتی رہیں — یہ کام Service Worker انجام دیتا ہے۔

بنیادی ٹرانسفارمیشن پیج کانٹینٹ میں ملنے والی کسی بھی URL کو پراکسی فارمیٹ میں بدلتی ہے:

-- Service Worker pseudocode: toProxyURL()

function toProxyURL(originalUrl, currentPageUrl):
    if isSameOrigin(originalUrl, currentPageUrl):
        return originalUrl   -- already proxy-origin, no rewrite needed

    -- Extract path/query/hash from the original URL
    -- Build a new URL rooted at the proxy origin
    proxyPath   = extractPathAndQuery(originalUrl)
    potValue    = base64encode(extractOrigin(originalUrl))
    proxyUrl    = proxy_origin + proxyPath + "?__pot=" + potValue

    return proxyUrl

مثال کے طور پر، پراکسی ہوتے ہوئے کسی پیج میں موجود https://cdn.example.com/bundle.js بن جاتا ہے https://proxyorb.com/bundle.js?__pot=aHR0cHM6Ly9jZG4uZXhhbXBsZS5jb20=۔

یہ ری رائٹنگ جامع ہے: اس میں fetch()، XMLHttpRequest، <script src>، <img src>، WebSocket کنکشنز، اور <link> ٹیگز شامل ہیں۔ جب پیج کی ہر URL پراکسی اوریجن کی طرف اشارہ کرے، تو براؤزر کبھی کراس اوریجن ریکوئسٹ نہیں کرتا — ہر ریکوئسٹ بنیادی طور پر سیم اوریجن ہے۔

مکمل نیویگیشن کے بغیر __pot ریکور کرنا

ایک پیچیدہ ایج کیس اس وقت سامنے آتا ہے جب پراکسیڈ پیج کے اندر سے ریکوئسٹس آتی ہیں لیکن ان میں __pot پیرامیٹر نہیں ہوتا — مثلاً ایک ریلیٹو fetch('/api/data') جو Service Worker کے URL ری رائٹ کرنے سے پہلے فائر ہو جاتی ہے، یا کوئی ریکوئسٹ جو کسی ڈائنامکلی انجیکٹڈ اسکرپٹ سے آئی جو URL ری رائٹر سے بچ نکلی۔

Service Worker گم شدہ ٹوکن کو کاسکیڈنگ لک اپ کے ذریعے ریکور کرتا ہے:

-- Service Worker pseudocode: recovering the origin token

function resolveMissingPot(fetchEvent):
    candidates = [
        getUrlOfControlledTab(fetchEvent.clientId),   -- most reliable
        inferUrlFromFetchEvent(fetchEvent),             -- from clientId / resultingClientId
        fetchEvent.request.referrer,                    -- referrer header
    ]

    for url in candidates:
        pot = extractQueryParam(url, "__pot")
        if pot: return pot

    return null   -- cannot recover; let the gateway handle or reject

گیٹ وے کے پاس ایک متوازی ریکوری راستہ بھی ہے: اگر کوئی ریکوئسٹ __pot کے بغیر پہنچے لیکن اس کا Referer ہیڈر ایک ایسی سیم اوریجن URL کی طرف اشارہ کرے جس میں __pot موجود ہو، تو گیٹ وے ریفرر سے ٹوکن نکال کر موجودہ ریکوئسٹ میں لگا دیتا ہے۔ یہ ان نیویگیشن سیناریوز کو ہینڈل کرتا ہے جہاں پیج کے اپنے JavaScript نے گیٹ وے تک پہنچنے سے پہلے ٹوکن اسٹرپ کر دیا ہو۔

۳۔ CORS: واضح کراس اوریجن اجازت کا نظام

CORS (Cross-Origin Resource Sharing) اس لیے ڈیزائن کیا گیا تھا کہ سرور مخصوص ریسپانس ہیڈرز بھیج کر کراس اوریجن رسائی کو آپٹ ان کریں۔ پراکسی کے نقطہ نظر سے CORS دو الگ مسائل پیدا کرتا ہے۔

مسئلہ ۱: CORS پری فلائٹ انٹرسیپشن

جب کسی پیج پر چلنے والا JavaScript نان سمپل ہیڈرز (مثلاً Authorization، Content-Type: application/json) کے ساتھ fetch() ریکوئسٹ کرتا ہے، تو براؤزر پہلے ایک OPTIONS پری فلائٹ ریکوئسٹ بھیجتا ہے۔ اگر ٹارگٹ سرور کا پری فلائٹ ریسپانس پرمسیو CORS ہیڈرز شامل نہ کرے، تو اصل ریکوئسٹ بلاک ہو جاتی ہے۔

ProxyOrb کے آرکیٹیکچر میں، Service Worker تمام OPTIONS ریکوئسٹس کو انٹرسیپٹ کرتا ہے اور انہیں مصنوعی طور پر جواب دیتا ہے — گیٹ وے تک پہنچنے سے پہلے — ایسا ریسپانس لوٹاتا ہے جو اصل ریکوئسٹ کو بلاک سے نکالے:

-- Service Worker pseudocode: synthetic CORS preflight

function handlePreflight(request):
    origin = request.headers["Origin"] or "*"

    return Response(status=204, headers={
        "Access-Control-Allow-Origin":      origin,
        "Access-Control-Allow-Methods":     "GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD",
        "Access-Control-Allow-Headers":     "*",
        "Access-Control-Allow-Credentials": "true",
        "Access-Control-Max-Age":           "86400",
        "Vary":                             "Origin",
    })

گیٹ وے سطح پر، ہر پراکسیڈ ریسپانس کو مساوی CORS ہیڈرز ملتے ہیں:

-- Gateway pseudocode: set CORS on outbound response

response.headers["Access-Control-Allow-Origin"]      = original_origin
response.headers["Access-Control-Allow-Headers"]     = "*"
response.headers["Access-Control-Allow-Credentials"] = "true"

مسئلہ ۲: کریڈینشیلڈ ریکوئسٹس

Access-Control-Allow-Credentials: true اور نان وائلڈ کارڈ Access-Control-Allow-Origin کا مجموعہ اہم ہے۔ CORS کے لیے جب بھی کریڈینشیلز شامل ہوں تو ایک واضح اوریجن ویلیو (* نہیں) درکار ہوتی ہے۔ Service Worker تمام آؤٹ باؤنڈ ریکوئسٹس کو credentials: 'include' کے ساتھ بھیجتا ہے، اس لیے گیٹ وے کو وائلڈ کارڈ کی بجائے ریکوئسٹنگ اوریجن بعینہ واپس کرنا ہوتا ہے۔

اس کا مطلب ہے کہ proxyorb.com کے تحت ذخیرہ تمام کوکیز — جو صارف نے پراکسی کے ذریعے وزٹ کی ہر ٹارگٹ سائٹ سے جمع ہوئیں — ہر پراکسیڈ ریکوئسٹ کے ساتھ بھیجی جاتی ہیں۔ یہ جان بوجھ کر ہے (لاگ ان سائٹس کے لیے سیشن اسٹیٹ برقرار رکھتا ہے)، لیکن یہ ایک اہم سیکیورٹی تحفظ بھی ہے جس پر ہم سیکشن ۸ میں بات کریں گے۔

CORS ہیڈر اسٹرپ اینڈ ریپلیس پیٹرن

ایک پراکسیڈ ریسپانس میں ٹارگٹ سرور کے CORS ہیڈرز ہو سکتے ہیں جو براؤزر کے نقطہ نظر سے غلط ہیں (وہ پراکسی اوریجن کی بجائے ٹارگٹ اوریجن کا حوالہ دیتے ہیں)۔ Service Worker انہیں اسٹرپ اور ریپلیس کرتا ہے:

-- Service Worker pseudocode: sanitize response headers

function sanitizeResponseHeaders(response):
    headers = copy(response.headers)

    -- Remove target-site directives that would confuse the browser
    headers.delete("Content-Security-Policy")
    headers.delete("Content-Security-Policy-Report-Only")
    headers.delete("X-Frame-Options")
    headers.delete("X-Content-Type-Options")

    -- Replace with proxy-origin-correct CORS headers
    headers.set("Access-Control-Allow-Origin",      proxy_origin)
    headers.set("Access-Control-Allow-Credentials", "true")
    headers.set("Access-Control-Allow-Headers",     "*")
    headers.set("Vary", "Origin")

    return headers

۴۔ CORB اور CORP: Chromium کے سخت تر دفاع

CORS سرورز کی واضح آپٹ ان پر کام کرتا ہے۔ Chromium نے دو ایسے میکانزم شامل کیے جو CORS کنفیگریشن سے قطع نظر ڈیفالٹ طور پر ایکٹیو ہیں۔

کراس اوریجن ریڈ بلاکنگ (CORB)

CORB کو Chrome 67 (2018) میں Spectre کے تدارک کے حصے کے طور پر متعارف کرایا گیا۔ بنیادی بصیرت یہ تھی: یہاں تک کہ اگر کوئی کراس اوریجن ریسپانس کی باڈی JavaScript کبھی پڑھے نہیں، محض یہ حقیقت کہ اسے رینڈرر پروسیس نے فیچ اور ڈی کوڈ کیا — وہ اس پروسیس کے ایڈریس اسپیس میں موجود ہے۔ Spectre کلاس اٹیکس پھر اسے سائڈ چینلز کے ذریعے نکال سکتے ہیں۔

CORB بعض کراس اوریجن ریسپانسز کو رینڈرر پروسیس میں داخل ہونے سے روکتا ہے۔ خاص طور پر، جب ایک <script> یا <img> ٹیگ کوئی کراس اوریجن ریسپانس فیچ کرے اور اس کا Content-Type text/html، text/xml، یا application/json ہو، تو Chromium باڈی کا معائنہ کرتا ہے (CORB spec میں بیان کردہ MIME ٹائپ سنیفر استعمال کرتے ہوئے) اور اگر ٹائپ میچ ہو تو ریسپانس کو خالی سے بدل دیتا ہے، اس سے پہلے کہ رینڈرر اسے دیکھے۔

ایک ویب پراکسی کے لیے CORB تباہ کن ہو سکتی تھی اگر ریکوئسٹس واقعی کراس اوریجن ہوتیں۔ ایک <script> ٹیگ سے فیچ ہونے والا application/json ریٹرن کرنے والا API اینڈ پوائنٹ خاموشی سے خالی واپس کرتا۔ تاہم، چونکہ ProxyOrb تمام URLs کو سیم اوریجن بناتا ہے، CORB کی کراس اوریجن شرط کبھی ٹرگر نہیں ہوتی — براؤزر کبھی کراس اوریجن JSON ریسپانس نہیں دیکھتا، کیونکہ اس کے نقطہ نظر سے تمام ریسپانسز proxyorb.com سے آتے ہیں۔

وہ ایک کیس جہاں CORB اہمیت رکھتا ہے وہ ٹرانزیشن پیریڈ ہے جب Service Worker مکمل طور پر رجسٹرڈ اور ریکوئسٹس انٹرسیپٹ کرنے سے پہلے کی حالت ہوتی ہے۔ اگر اس دوران کوئی ریکوئسٹ URL ری رائٹنگ سے بچ نکلے، تو CORB اسے بلاک کر سکتا ہے۔ یہ ریس کنڈیشن اسی لیے ہے کہ ProxyOrb ایک مین تھریڈ انٹرسیپٹر لیئر بھی برقرار رکھتا ہے جو XMLHttpRequest، fetch، اور DOM ایٹریبیوٹ سیٹرز کو کسی بھی پیج JavaScript کے چلنے سے پہلے سنکرونوسلی پیچ کرتا ہے — Service Worker اسٹارٹ اپ کے دوران فال بیک فراہم کرتا ہے۔

یہ بھی قابل ذکر ہے کہ CORB کو جزوی طور پر Opaque Response Blocking (ORB) نے سپرسیڈ کیا ہے، جسے Chromium اڈاپٹ کرنے کے عمل میں ہے۔ ORB Spectre پروٹیکشنز برقرار رکھتے ہوئے فالس پازیٹیوز کم کرنے کے لیے CORB رولز کو بہتر بناتا ہے۔ پراکسی کمپیٹیبلٹی کے مضمرات ملتے جلتے ہیں۔

کراس اوریجن ریسورس پالیسی (CORP)

CORP، Fetch spec میں بیان کردہ، سرورز کو یہ اعلان کرنے دیتا ہے کہ ان کے ریسورسز صرف سیم اوریجن یا سیم سائٹ کانٹیکسٹ سے لوڈ ہونے چاہیئں:

Cross-Origin-Resource-Policy: same-origin

جب Chromium کسی کراس اوریجن سب ریسورس ریکوئسٹ پر یہ ہیڈر دیکھتا ہے، تو ریسپانس مکمل طور پر بلاک کر دیتا ہے۔ یہ CORB سے زیادہ جارحانہ ہے — یہ کانٹینٹ ٹائپ سے قطع نظر لاگو ہوتا ہے اور MIME سنیفنگ سے بائی پاس نہیں ہو سکتا۔

پھر بھی، چونکہ ProxyOrb کی URL ری رائٹنگ تمام ریکوئسٹس کو براؤزر کے نقطہ نظر سے سیم اوریجن بناتی ہے، ٹارگٹ سرورز کے CORP ہیڈرز بلاکنگ ٹرگر نہیں کرتے۔ گیٹ وے ان ہیڈرز کو احتیاطاً ریسپانسز سے بھی اسٹرپ کرتا ہے، کسی ایج کیس کو ہینڈل کرتے ہوئے جہاں کوئی ریکوئسٹ URL ری رائٹنگ کے بغیر گزر جائے۔

CORP کا گہرا مسئلہ دراصل وہ کیس ہے جہاں پراکسی آرکیٹیکچر کمپیٹیبلٹی میں مدد کرتا ہے: اگر https://api.example.com اور https://www.example.com دونوں پراکسی ہو رہے ہیں، تو دونوں ایک ہی پراکسی اوریجن پر میپ ہوتے ہیں، اس لیے ایک سے دوسرے پر ایک فیچ اب واقعی سیم اوریجن ہے — CORP پابندیاں ان کے درمیان مزید لاگو نہیں ہوتیں۔

۵۔ COEP اور COOP: کراس اوریجن آئسولیشن

Chrome 92 (2021) سے شروع ہو کر، SharedArrayBuffer تک رسائی — اور اس کے نتیجے میں بعض پرفارمنس APIs کے لیے ہائی ریزولیوشن ٹائمرز — ان صفحات تک محدود کر دی گئی جنہوں نے کراس اوریجن آئسولیشن کو آپٹ ان کیا ہو۔ اس آپٹ ان کے لیے دو ریسپانس ہیڈرز مل کر کام کرتے ہیں۔

Cross-Origin-Embedder-Policy (COEP)

Cross-Origin-Embedder-Policy: require-corp

جب کوئی پیج یہ ہیڈر بھیجتا ہے، تو براؤزر لازم کرتا ہے کہ اس پیج کے ذریعے لوڈ ہونے والا ہر سب ریسورس یا تو:

1. سیم اوریجن ہو، یا
2. واضح طور پر Cross-Origin-Resource-Policy: cross-origin بھیجے، یا
3. کریڈینشیلڈ فیچ کے لیے پرمسیو CORS ریسپانس ہو

ویب پراکسیز کے لیے مسئلہ: اگر کوئی ٹارگٹ سائٹ اپنے مین ڈاکیومنٹ پر COEP: require-corp بھیجے، اور وہ ڈاکیومنٹ ہیڈر محفوظ رکھتے ہوئے پراکسی کے ذریعے سرو ہو، تو براؤزر اب ہر سب ریسورس سے بھی آپٹ ان کا مطالبہ کرتا ہے۔ جو ریسورس ایسا نہ کرے — اور زیادہ تر نہیں کریں گے — نیٹ ورک ایرر کا سبب بنتا ہے۔

Cross-Origin-Opener-Policy (COOP)

Cross-Origin-Opener-Policy: same-origin

COOP کنٹرول کرتا ہے کہ کوئی پیج کراس اوریجن صفحات کے ساتھ براؤزنگ کانٹیکسٹ گروپ شیئر کر سکتا ہے یا نہیں۔ same-origin سیٹ ہونے پر، کراس اوریجن نیویگیشن ایک نیا براؤزنگ کانٹیکسٹ گروپ کھولتی ہے، window.opener ریفرنسز اور پیج اور کسی بھی کراس اوریجن اوپنرز کے درمیان postMessage چینلز توڑ دیتی ہے۔

پراکسی کے لیے، COOP COEP کے مقابلے کم فوری طور پر نقصاندہ ہے، لیکن یہ پھر بھی ان سائٹس کو توڑ دیتا ہے جو کراس اوریجن postMessage فلوز (OAuth پاپ اپ فلوز سب سے عام مثال ہیں) پر انحصار کرتی ہیں۔

پراکسی آپریٹر کا مخمصہ

ProxyOrb میں یہ سب سے مشکل ٹریڈ آف ہے:

آپشن A: ریسپانسز سے COEP اور COOP اسٹرپ کریں۔

• فائدہ: سب ریسورس لوڈنگ نارمل کام کرتی ہے؛ پراکسیڈ پیج ان پابندیوں کو لاگو نہیں کرتا۔
• نقصان: ہم وہ سیکیورٹی ہیڈرز ہٹا رہے ہیں جو ٹارگٹ سائٹ نے جان بوجھ کر سیٹ کیے تھے۔ اگر سائٹ Spectre کلاس اٹیکس سے حساس ڈیٹا محفوظ رکھنے کے لیے کراس اوریجن آئسولیشن استعمال کر رہی تھی، تو یہ ہیڈرز اسٹرپ کرنا وہ خطرہ دوبارہ ظاہر کرتا ہے۔

آپشن B: COEP اور COOP محفوظ رکھیں۔

• فائدہ: ٹارگٹ سائٹ کا سیکیورٹی ارادہ مانا جاتا ہے۔
• نقصان: کوئی بھی سب ریسورس جو واضح طور پر CORP: cross-origin سیٹ نہ کرے لوڈ نہیں ہوگا، زیادہ تر پیچیدہ ویب ایپلیکیشنز ٹوٹ جائیں گی۔

ProxyOrb کی موجودہ حکمت عملی آپشن A ہے: گیٹ وے ریسپانسز سے Cross-Origin-Embedder-Policy اور Cross-Origin-Opener-Policy اسٹرپ کرتا ہے۔ یہ سائٹ کمپیٹیبلٹی کو زیادہ سے زیادہ کرتا ہے۔ سیکیورٹی ٹریڈ آف شعوری طور پر کیا گیا ہے: ویب پراکسی کے صارفین یہ قبول کر رہے ہیں کہ وہ کانٹینٹ کو اس کی مطلوبہ ڈیپلائمنٹ کانٹیکسٹ سے مختلف ماحول میں چلا رہے ہیں۔

ہر نیا براؤزر سیکیورٹی میکانزم ایک پیٹرن کی پیروی کرتا ہے: آپٹ ان کے طور پر متعارف ہوتا ہے، پھر آہستہ آہستہ نئے APIs کے لیے ڈیفالٹ بن جاتا ہے، اور آخرکار لازمی انفورسمنٹ کے لیے غور کیا جاتا ہے۔ COEP نے یہ راستہ طے کیا: Chrome 83 میں اختیاری، Chrome 91 میں SharedArrayBuffer کے لیے ضروری۔ جن سائٹس نے بنا کوآرڈینیشن کے تھرڈ پارٹی کانٹینٹ ایمبیڈ کیا انہوں نے اپنا کانٹینٹ ٹوٹا ہوا پایا۔ ویب پراکسیز اس مسئلے کو مرکب کرتی ہیں کیونکہ وہ بنیادی طور پر تھرڈ پارٹی کانٹینٹ کی ثالث ہیں۔

براؤزر سیکیورٹی کمیونٹی اس مسئلے سے آگاہ ہے۔ ابھرتی ہوئی Document-Isolation-Policy تجویز پروسیس آئسولیشن کو کراس اوریجن آئسولیشن کی ضروریات سے الگ کرنے کا ارادہ رکھتی ہے، ممکنہ طور پر تمام سب ریسورسز سے آپٹ ان کی ضرورت کے بغیر Spectre تدارک ممکن بناتی ہے۔ جب وہ آئے گا، آئسولیشن ہیڈرز کے ساتھ پراکسی کمپیٹیبلٹی بہتر ہو سکتی ہے۔

۶۔ Service Worker بطور براؤزر سائڈ ٹرسٹ لیئر

Service Worker محض ایک آپٹیمائزیشن نہیں — یہ ProxyOrb کے سیکیورٹی ماڈل کے لیے آرکیٹیکچرلی ضروری ہے۔ وجہ یہ ہے۔

رجسٹریشن اسکوپ اوریجن سے منسلک ہوتا ہے

ایک Service Worker ایک scope کے ساتھ رجسٹر ہوتا ہے جو ہمیشہ رجسٹر کرنے والے پیج کے اوریجن کے اندر ہوتا ہے۔ جب ProxyOrb اپنا Service Worker رجسٹر کرتا ہے، تو اسکوپ https://proxyorb.com/ ہوتا ہے، یعنی یہ اس اوریجن کے تحت کسی بھی پیج سے ہر فیچ کو انٹرسیپٹ کرتا ہے۔

یہ وہ بنیادی وجہ ہے جس کی وجہ سے سیم اوریجن پر URL ری رائٹنگ کام کرتی ہے: ایک بار جب SW کوئی کلائنٹ کنٹرول کرے، اس کلائنٹ سے ہر نیٹ ورک ریکوئسٹ — قطع نظر اس سے کہ پیج میں JavaScript کون سی URL فیچ کرنے کی کوشش کرتا ہے — پہلے Service Worker سے گزرتی ہے۔

// Service Worker entry point
self.addEventListener('fetch', (event) => {
  event.respondWith(handleProxyRequest(event))
})

انٹرسیپشن پائپ لائن

جب Service Worker کوئی ریکوئسٹ انٹرسیپٹ کرتا ہے، تو یہ کئی فیصلہ مراحل سے گزرتی ہے:

-- Service Worker pseudocode: request interception pipeline

function handleProxyRequest(fetchEvent):
    request = fetchEvent.request

    -- Stage 1: Synthetic CORS preflight (never hits the network)
    if request.method == "OPTIONS":
        return syntheticCORSResponse(request)

    -- Stage 2: Pass through requests that shouldn't be proxied
    if shouldBypass(request.url):
        return originalFetch(request)

    -- Stage 3: Ensure __pot is present; recover from context if missing
    enrichedRequest = attachOriginToken(request, fetchEvent)

    -- Stage 4: Forward to gateway
    response = originalFetch(enrichedRequest)

    -- Stage 5: Strip and replace security headers in the response
    return sanitizeAndReturn(response)

ٹرانسپیرنٹ ہیڈر فارورڈنگ

ایک باریک چیلنج: براؤزر JavaScript کو Fetch API کے ذریعے بعض "فاربڈن" ریکوئسٹ ہیڈرز (Host، Origin، Referer، وغیرہ) سیٹ کرنے سے روکتا ہے۔ Service Worker اس مسئلے کا حل یہ نکالتا ہے کہ محدود ہیڈرز کو ایک سنگل کسٹم پاس تھرو ہیڈر میں انکوڈ کرتا ہے؛ گیٹ وے پھر انہیں ڈی کوڈ کر کے ٹارگٹ سرور کو فارورڈ کرنے سے پہلے لگا دیتا ہے:

-- Pseudocode: encode browser-restricted headers for the gateway

function addPassthroughHeaders(request, outboundHeaders):
    restricted = {}
    for name, value in request.headers:
        if name not in COMMON_ALLOWED_HEADERS:
            restricted[name] = value

    if restricted is not empty:
        outboundHeaders["X-Proxy-Passthrough"] = json_encode(restricted)

-- Gateway side: decode and apply before forwarding upstream
function applyPassthroughHeaders(incomingHeaders):
    encoded = incomingHeaders["X-Proxy-Passthrough"]
    if encoded:
        for name, value in json_decode(encoded):
            request.headers[name] = value
        request.headers.delete("X-Proxy-Passthrough")

SW بطور قابل اعتماد واسطہ: سیکیورٹی مضمرات

سیکیورٹی کے نقطہ نظر سے، Service Worker ایک مراعات یافتہ پوزیشن رکھتا ہے: یہ اپنے اسکوپ کے کسی بھی پیج سے کی گئی کسی بھی ریکوئسٹ کا معائنہ، ترمیم، اور جعل سازی کر سکتا ہے۔ جائز پراکسی استعمال کے لیے، یہی پورا نقطہ ہے۔ لیکن ایک ملیشس پراکسی کے لیے، یہ ایک انتہائی طاقتور اٹیک سرفیس ہوگا۔

یہی وجہ ہے کہ Service Worker اسکرپٹ کی اپنی قابل اعتمادی سب سے اہم ہے۔ ProxyOrb انٹرسیپٹر اسکرپٹ کو اپنے اوریجن سے HTTPS پر سخت کیش کنٹرولز کے ساتھ سرو کرتا ہے۔ اگر کوئی حملہ آور ایک ترمیم شدہ Service Worker انجیکٹ کر سکے، تو وہ متاثرہ صارفین کی تمام ٹریفک انٹرسیپٹ کر سکتا ہے — صرف پراکسی ٹریفک نہیں، بلکہ اس اوریجن کے تحت صفحات سے کوئی بھی ریکوئسٹ۔

۷۔ iframes: فریم اینسیسٹرز کا مسئلہ

iframes باقاعدہ سب ریسورسز سے ایک الگ چیلنج پیش کرتے ہیں کیونکہ ان میں ایک نیسٹڈ براؤزنگ کانٹیکسٹ ہوتا ہے جس کی اپنی نیویگیشن، اپنی SOP باؤنڈری، اور اپنے ایمبیڈنگ پابندیوں کا سیٹ ہوتا ہے۔

X-Frame-Options اور frame-ancestors

دو میکانزم صفحات کو iframes میں ایمبیڈ ہونے سے روکتے ہیں:

لیگیسی: X-Frame-Options: DENY یا X-Frame-Options: SAMEORIGIN

جدید: Content-Security-Policy: frame-ancestors 'none' یا frame-ancestors 'self'

جب گیٹ وے ایک ایسے ٹارگٹ پیج کو پراکسی کرتا ہے جو ان میں سے کوئی بھی بھیجتا ہے، تو پیج پراکسی اوریجن کے تحت iframe میں ایمبیڈ نہیں ہو سکتا۔ چونکہ X-Frame-Options: SAMEORIGIN ٹارگٹ اوریجن (example.com) کا حوالہ دیتا ہے، اور پراکسی پیج کو proxyorb.com سے سرو کرتی ہے، تو براؤزر کا سیم اوریجن چیک فیل ہو جاتا ہے۔

پراکسی کو پراکسیڈ ریسپانسز سے یہ ہیڈرز اسٹرپ کرنے اور CSP کو پرمسیو ورژن سے بدلنا ہوتا ہے:

-- Gateway pseudocode: override embedding-restrictive headers

response.headers.delete("X-Frame-Options")
response.headers.delete("Content-Security-Policy")
response.headers.delete("Content-Security-Policy-Report-Only")

-- Set a permissive replacement that allows the proxy to embed content
response.headers["Content-Security-Policy"] =
    "upgrade-insecure-requests; frame-ancestors 'self'; " +
    "default-src * data: blob: about: ws: wss: 'unsafe-inline' 'unsafe-eval'"

Iframe انٹرسیپشن اور اسکرپٹ انجیکشن

ایمبیڈڈ iframes ایک دوسرا مسئلہ پیش کرتے ہیں: ان کا کانٹینٹ پراکسی سے لوڈ ہوتا ہے، لیکن iframe کی براؤزنگ کانٹیکسٹ میں خودبخود Service Worker یا مین تھریڈ انٹرسیپٹر ایکٹیو نہیں ہوتا۔ اگر پراکسیڈ پیج <iframe src="https://widget.example.com/..."> بناتا ہے، تو وہ iframe URL بھی پراکسی فارمیٹ میں ری رائٹ ہونی چاہیے، اور پراکسی کی انٹرسیپٹر اسکرپٹس iframe کے ڈاکیومنٹ میں انجیکٹ ہونی چاہیئں۔

iframe انٹرسیپٹر دو سطحوں پر کام کرتا ہے:

سطح ۱ — پروٹوٹائپ پیچنگ (پروگرامیٹک iframe تخلیق پکڑتا ہے):

-- Pseudocode: intercept iframe src assignment

override HTMLIFrameElement.prototype.src setter:
    if value is not already a proxy URL:
        value = toProxyURL(value)   -- rewrite to proxy format
    call original setter(value)
    scheduleProxyInjection(this)    -- inject interceptor into iframe document

سطح ۲ — MutationObserver فال بیک (DOM میں داخل iframes پکڑتا ہے):

-- Pseudocode: observe DOM for dynamically added iframes

observer = new MutationObserver(mutations):
    for mutation in mutations:
        for node in mutation.addedNodes:
            if node is an <iframe>:
                rewriteSrcIfNeeded(node)
                injectProxyScript(node)

observer.observe(document, { childList: true, subtree: true })

sandbox ایٹریبیوٹ کا مسئلہ

HTML کا sandbox ایٹریبیوٹ اس بات کو محدود کرتا ہے کہ iframe کیا کر سکتا ہے: sandbox="allow-scripts allow-same-origin" اسکرپٹ ایگزیکیوشن، فارم سبمیشن، کراس اوریجن رسائی وغیرہ کنٹرول کرتا ہے۔ پراکسی انجیکشن کے لیے، iframe کو اسکرپٹس چلانے اور پیرنٹ کی پراکسی کانٹیکسٹ تک رسائی کی ضرورت ہے۔

allow-same-origin ٹوکن خاص طور پر پیچیدہ ہے: جب allow-scripts کے ساتھ موجود ہو، تو یہ سینڈ باکس کی اوریجن آئسولیشن ختم کر دیتا ہے — iframe ایمبیڈنگ پیج کے اوریجن کے ساتھ چلتا ہے۔ جب غیر موجود ہو، تو iframe کو ایک منفرد اوپیک اوریجن ملتا ہے، جو پراکسی اسکرپٹ انجیکشن کو مکمل طور پر توڑ دے گا۔

ProxyOrb کا موجودہ طریقہ کار سینڈ باکس ایٹریبیوٹس کے لیے پراکسی اسکرپٹ انجیکٹ کرنے سے پہلے sandbox ایٹریبیوٹ کو مکمل طور پر ہٹانا ہے:

-- Pseudocode: handle sandbox attribute before proxy injection

function handleSandboxedIframe(iframe):
    if iframe.hasAttribute("sandbox"):
        -- Remove so the proxy can inject scripts and access contentWindow
        iframe.removeAttribute("sandbox")
    injectProxyScript(iframe)

یہ ایک اہم سیکیورٹی ٹریڈ آف ہے: سینڈ باکسنگ اصل سائٹ نے جان بوجھ کر ایمبیڈڈ کانٹینٹ کی صلاحیتوں کو محدود کرنے کے لیے لگائی تھی۔ اسے ہٹانا اس کانٹینٹ کے کاموں کو بڑھا دیتا ہے۔ یہ اس قسم کا فیصلہ ہے جو آخری صارفین کو نظر نہیں آتا لیکن پراکسی سیشن کے سیکیورٹی پوسچر کو مادی طور پر متاثر کرتا ہے۔

۸۔ پراکسی آپریٹرز کے لیے سیکیورٹی مضمرات

اٹیک سرفیس لینڈ اسکیپ

جب صارفین ProxyOrb کے ذریعے براؤز کرتے ہیں، تو حساس ڈیٹا کی کئی کیٹیگریاں پراکسی کے اوریجن سے گزرتی ہیں:

سیشن کوکیز: چونکہ تمام ٹارگٹ سائٹس proxyorb.com کے ذریعے پراکسی ہوتی ہیں، کوکیز اس اوریجن کے تحت ذخیرہ ہوتی ہیں۔ بینک، ای میل، اور سوشل میڈیا کے ساتھ صارف کے تمام مصدقہ سیشنز ایک ہی ڈومین کے تحت کوکیز ہیں۔ Service Worker کا credentials: 'include' مطلب ہے کہ یہ کوکیز ہر پراکسیڈ ریکوئسٹ کے ساتھ جاتی ہیں۔

Referer ہیڈرز: اپ اسٹریم سرورز کو بھیجا گیا Referer ہیڈر ظاہر کرتا ہے کہ صارف کون سا پیج دیکھ رہا تھا۔ پراکسی ٹارگٹ سرور کو فارورڈ کرنے سے پہلے ریفرر ویلیوز سے اپنا ڈومین احتیاط سے اسٹرپ کرتی ہے۔ اگر کوئی ریکوئسٹ https://proxyorb.com/some/path?__pot=... سے آتی ہے، تو آؤٹ باؤنڈ Referer ہیڈر اصل ٹارگٹ URL (https://example.com/some/path) کے طور پر دوبارہ بنایا جاتا ہے — پراکسی ڈومین کبھی اپ اسٹریم سرورز کو لیک نہیں ہوتا۔

-- Pseudocode: normalize referer before forwarding upstream

function sanitizeReferer(referer):
    if referer is a proxy URL:
        return reconstruct_original_url(referer)   -- e.g. "https://example.com/path"
    if referer's origin equals proxy_origin:
        return ""   -- suppress: don't leak proxy domain to upstream
    return referer

JavaScript ایگزیکیوشن کانٹیکسٹ: پراکسی کے ذریعے سرو کی گئی ہر JavaScript فائل ترمیم شدہ (URLs ری رائٹ) ہوتی ہے اور پراکسی کے اوریجن میں ایگزیکیوٹ ہوتی ہے۔ ProxyOrb کے ذریعے پراکسی ہوتی evil.example.com کی ایک ملیشس اسکرپٹ proxyorb.com اوریجن میں چلتی ہے اور اس اوریجن کے لوکل اسٹوریج، کوکیز، اور IndexedDB تک مکمل رسائی رکھتی ہے — جس میں ہر دوسری ٹارگٹ سائٹ کا ڈیٹا شامل ہے جو صارف نے پراکسی کے ذریعے ایکسیس کیا۔

ملیشس پراکسی تھریٹ ماڈل

تعلیمی مقاصد کے لیے، یہ واضح کرنا ضروری ہے کہ ایک ملیشس پراکسی کیا کر سکتی ہے جو ProxyOrb جان بوجھ کر نہیں کرتا:

1. کریڈینشیل ہارویسٹنگ: ایک ملیشس پراکسی گیٹ وے سے گزرتے وقت ہر ریکوئسٹ باڈی (جس میں پاسورڈز اور فارم ڈیٹا ہو) لاگ کر سکتی ہے۔

2. سیشن ہائی جیکنگ: چونکہ تمام ٹارگٹ سائٹ کوکیز پراکسی ڈومین کے تحت ذخیرہ ہیں، ایک ملیشس پراکسی آپریٹر گیٹ وے کے ذریعے سرور سائڈ پر ان کوکیز تک رسائی حاصل کر سکتا ہے۔

3. کانٹینٹ انجیکشن: پراکسی لازماً پیج کانٹینٹ ترمیم کرتی ہے (Service Worker انجیکٹ کرنے اور URLs ری رائٹ کرنے کے لیے)۔ ایک ملیشس پراکسی صارف کو پوشیدہ رہتے ہوئے من مانی JavaScript — کی لاگرز، کرپٹو مائنرز، ایڈ فراڈ اسکرپٹس — انجیکٹ کر سکتی ہے۔

4. SSL اسٹرپنگ: اگر پراکسی گیٹ وے سے صارف تک HTTPS کنکشنز کو HTTP پر ڈاؤن گریڈ کرے، تو تمام ٹریفک پلین ٹیکسٹ ہوگی۔

ProxyOrb مکمل طور پر اینڈ ٹو اینڈ HTTPS پر کام کرتا ہے اور ریکوئسٹ باڈیز لاگ نہیں کرتا۔ کسی بھی ویب پراکسی کے آپریٹر کے پاس یہ صلاحیتیں ہیں، یہی وجہ ہے کہ قابل اعتماد پراکسی آپریٹر چننا VPN فراہم کنندہ چننے کی طرح اتنا ہی اہم ہے۔

مکسڈ کانٹینٹ

جدید براؤزرز مکسڈ کانٹینٹ بلاکنگ نافذ کرتے ہیں: ایک HTTPS پیج HTTP سب ریسورسز لوڈ نہیں کر سکتا۔ ProxyOrb اسے گیٹ وے سے آؤٹ باؤنڈ تمام کنکشنز پر HTTPS نافذ کر کے ہینڈل کرتا ہے، یہاں تک کہ جب ٹارگٹ URL HTTP استعمال کرتی ہو۔ CSP اوور رائڈ میں upgrade-insecure-requests شامل ہے تاکہ براؤزر کو کوئی بھی HTTP سب ریسورس URL کو لوڈ کرنے سے پہلے HTTPS میں اپ گریڈ کرنے کی ہدایت ہو۔

یہ عموماً مطلوب ہے، لیکن یہ ان سائٹس کو توڑ سکتا ہے جو جان بوجھ کر HTTP پر ریسورسز سرو کرتی ہیں (لیگیسی CDNs، لوکل ہوسٹ ریسورسز وغیرہ)۔

۹۔ جاری ہتھیاروں کی دوڑ: نتیجہ

جب ہم نے ProxyOrb بنانا شروع کیا، بنیادی کمپیٹیبلٹی چیلنجز CORS اور X-Frame-Options تھے۔ تب سے، Chromium نے CORB، CORP، COEP، COOP شپ کی ہے اور Document-Isolation-Policy ڈویلپ کر رہا ہے۔ سفر کی سمت واضح ہے: براؤزرز کراس اوریجن باؤنڈریز نافذ کرنے میں زیادہ جارحانہ ہوتے جا رہے ہیں، اور ہر نیا میکانزم پراکسی انفراسٹرکچر کو اڈاپٹ کرنے کی ضرورت دیتا ہے۔

سب سے اہم آنے والا چیلنج ممکنہ طور پر بڑی ویب ایپلیکیشنز میں COEP کی مکمل ڈیپلائمنٹ ہے۔ جو سائٹس پرفارمنس کے لیے SharedArrayBuffer استعمال کرتی ہیں (ویڈیو ایڈیٹرز، IDEs، کولیبوریشن ٹولز) تیزی سے COEP: require-corp سیٹ کر رہی ہیں۔ چونکہ ProxyOrb کمپیٹیبلٹی برقرار رکھنے کے لیے یہ ہیڈر اسٹرپ کرتا ہے، جن صارفین کو COEP فعال کرنے والی ہائی پرفارمنس خصوصیات کی ضرورت ہے وہ پراکسی کانٹیکسٹ میں انہیں ڈیگریڈڈ پائیں گے۔

سیکیورٹی ریسرچرز کے لیے، پراکسی آرکیٹیکچر کچھ اہم ظاہر کرتا ہے: سیم اوریجن پالیسی فائر وال نہیں ہے۔ یہ URL ڈھانچے پر مبنی اعتماد کا ماڈل ہے۔ ویب پراکسیز اس حقیقت کا فائدہ اٹھاتی ہیں کہ SOP "یہ دو ریسورسز قانونی طور پر سیم اوریجن ہیں" اور "یہ دو ریسورسز سیم اوریجن لگنے کے لیے URL ری رائٹ کیے گئے ہیں" کے درمیان کوئی فطری فرق نہیں کرتی۔ SOP کے اوپر پورا براؤزر سیکیورٹی اسٹیک — CORS، CORB، CORP، COEP، COOP — کو URL پر مبنی اوریجن شناخت سے زیادہ مضبوط دفاع شامل کرنے کی کوشش کے طور پر دیکھا جا سکتا ہے۔

یہ سمجھنا ہر اس شخص کے لیے ضروری ہے جو پراکسی سروسز کا آڈٹ کر رہا ہے، براؤزر سیکیورٹی پالیسیاں ڈیزائن کر رہا ہے، یا ان ایپلیکیشنز کے حقیقی دنیا کے سیکیورٹی پوسچر کا جائزہ لے رہا ہے جو پراکسیز کے ذریعے ایکسیس ہو سکتی ہیں۔

اکثر پوچھے جانے والے سوالات

کیا ویب پراکسی سیم اوریجن پالیسی کو بائی پاس کرتی ہے؟

بالکل نہیں۔ ویب پراکسی URL ری رائٹنگ کے ذریعے کام کرتی ہے: یہ تمام کراس اوریجن URLs کو سیم اوریجن URLs میں تبدیل کرتی ہے، SOP کی کراس اوریجن پابندیوں کو بائی پاس کرنے کی بجائے غیر متعلق بنا دیتی ہے۔ براؤزر کے نقطہ نظر سے، تمام کانٹینٹ پراکسی کے اپنے اوریجن سے آتا دکھتا ہے، اس لیے کوئی کراس اوریجن باؤنڈری عبور نہیں ہوتی۔ یہ آرکیٹیکچرلی بائی پاس سے مختلف ہے — SOP اپنے قواعد نافذ کرتی رہتی ہے؛ پراکسی بس کانٹینٹ کو اس طرح انجینئر کرتی ہے کہ وہ قواعد کبھی ٹرگر نہ ہوں۔

CORS ویب پراکسی سرورز کو کیسے متاثر کرتا ہے؟

CORS پراکسی سرورز کو دو سطحوں پر متاثر کرتا ہے۔ پہلا، پراکسی کو OPTIONS پری فلائٹ ریکوئسٹس انٹرسیپٹ کرنی ہوتی ہیں اور پرمسیو CORS ہیڈرز کے ساتھ جواب دینا ہوتا ہے، کیونکہ اصل ٹارگٹ سرور کا پری فلائٹ ریسپانس (ٹارگٹ اوریجن کا حوالہ دیتا ہوا) پراکسی اوریجن کے لیے براؤزر کے CORS چیک کو پورا نہیں کرے گا۔ دوسرا، پراکسی کو ٹارگٹ سرور ریسپانسز سے CORS ہیڈرز اسٹرپ کرنے اور پراکسی اوریجن کا حوالہ دینے والے ہیڈرز سے بدلنے ہوتے ہیں۔ Access-Control-Allow-Credentials: true سیٹنگ، Service Worker میں credentials: 'include' کے ساتھ مل کر، مطلب ہے کہ پراکسی کے اوریجن کی تمام کوکیز ہر پراکسیڈ ریکوئسٹ کے ساتھ جاتی ہیں۔

CORB کیا ہے اور یہ پراکسی سروسز کو کیسے متاثر کرتا ہے؟

کراس اوریجن ریڈ بلاکنگ (CORB) ایک Chromium دفاع ہے جو بعض حساس کراس اوریجن ریسپانسز (HTML، JSON، XML) کو رینڈرر پروسیس میں داخل ہونے سے روکتا ہے جب کراس اوریجن سب ریسورسز کے طور پر لوڈ ہوں۔ درست طور پر کنفیگر ویب پراکسیز کے لیے، CORB عموماً ٹرگر نہیں ہوتا کیونکہ URL ری رائٹنگ تمام ریکوئسٹس کو سیم اوریجن بنا دیتی ہے۔ تاہم، CORB ان مسائل کا سبب بن سکتا ہے جب Service Worker مکمل طور پر رجسٹرڈ نہ ہو، جب کچھ ریکوئسٹس URL ری رائٹنگ سے بچ کر حقیقی کراس اوریجن ریکوئسٹس کے طور پر بھیجی جائیں۔ CORB کو Spectre تدارک کے طور پر متعارف کرایا گیا اور WHATWG Fetch specification میں بیان کیا گیا ہے۔

کیا ویب پراکسیز HTTP-only کوکیز ایکسیس کر سکتی ہیں؟

نہیں۔ HttpOnly کوکیز ٹارگٹ سرور کی طرف سے سیٹ ہوتی ہیں اور JavaScript کے ذریعے پڑھی نہیں جا سکتیں — بشمول Service Worker میں چلنے والے JavaScript۔ تاہم، گیٹ وے صارف کی جانب سے ریکوئسٹس فارورڈ کرتے وقت یہ کوکیز وصول کرتا ہے، کیونکہ براؤزر انہیں ریکوئسٹ ہیڈرز میں بھیجتا ہے۔ HttpOnly فلیگ کلائنٹ سائڈ JavaScript چوری سے بچاتا ہے لیکن پراکسی سرور کو ٹرانزٹ میں کوکی ویلیوز دیکھنے سے نہیں روکتا۔ یہ اس طرح ہے جیسے HttpOnly XSS سے بچاتا ہے لیکن سرور سائڈ انٹرسیپشن سے نہیں۔

کیا ویب پراکسی استعمال کرنا براؤزر سیکیورٹی کے نقطہ نظر سے محفوظ ہے؟

یہ تھریٹ ماڈل پر منحصر ہے۔ براؤزر کے نقطہ نظر سے، ویب پراکسی کے ذریعے سرو ہونے والا تمام کانٹینٹ پراکسی کے اوریجن میں چلتا ہے، یعنی کسی ایک پراکسیڈ سائٹ کے JavaScript میں کمزوری ممکنہ طور پر دوسری پراکسیڈ سائٹ کے سیشن کے ڈیٹا تک رسائی حاصل کر سکتی ہے (کیونکہ وہ ایک ہی اوریجن کی کوکی جار اور اسٹوریج شیئر کرتے ہیں)۔ پراکسی کا آپریٹر بھی ایک قابل اعتماد فریق ہے جسے ٹرانزٹ میں تمام ٹریفک تک رسائی ہے۔ پابندی والے ماحول میں غیر حساس کانٹینٹ ایکسیس کرنے کے لیے، خطرہ عموماً قابل قبول ہے۔ حساس سروسز (بینکنگ، ہیلتھ کیئر، گورنمنٹ) کے ساتھ مصدقہ سیشنز کے لیے، صارفین کو سمجھنا چاہیے کہ پراکسی آپریٹر کے پاس اس ٹریفک کا مشاہدہ کرنے کی تکنیکی صلاحیت ہے، اور صرف ان پراکسی سروسز کا استعمال کریں جن کے آڈٹ ایبل نو لاگ پالیسیز اور مضبوط آپریشنل سیکیورٹی پریکٹسز ہوں۔

یہ آرٹیکل سن ۲۰۲۶ کے اوائل تک ProxyOrb کے آرکیٹیکچر کی عکاسی کرتا ہے۔ براؤزر سیکیورٹی میکانزم تیزی سے ارتقاء پذیر ہیں؛ قارئین کو تازہ ترین معلومات کے لیے WHATWG Fetch Standard، W3C Content Security Policy specification، اور Chromium کے سیکیورٹی ڈیزائن دستاویزات دیکھنے کی ترغیب دی جاتی ہے۔