সেম-অরিজিন পলিসি এবং ওয়েব প্রক্সি: একটি টেকনিক্যাল সিকিউরিটি অ্যানালাইসিস

ProxyOrb বানাতে গিয়ে আমরা প্রতিটা ডিজাইন ডিসিশনে একটা মৌলিক প্যারাডক্সের মুখে পড়েছি: একটা ওয়েব প্রক্সির কাজই হলো ব্রাউজারকে বিশ্বাস করানো যে থার্ড-পার্টি কন্টেন্ট আসলে সেম-অরিজিন কন্টেন্ট। অর্থাৎ, সংজ্ঞার দিক থেকে এটা ব্রাউজারের কোর সিকিউরিটি মডেলকে ধোঁকা দেওয়া। অথচ আধুনিক ব্রাউজারগুলো পনেরো বছর ধরে ঠিক এই ধরনের অরিজিন কনফিউশনের বিরুদ্ধে ক্রমশ পরিশীলিত প্রতিরক্ষা স্তর তৈরি করে আসছে।

এই আর্টিকেলে আমরা সেই টানাপোড়েনটাকে একদম গোড়া থেকে দেখব। আপনি যদি সিকিউরিটি রিসার্চার, পেনিট্রেশন টেস্টার, বা ব্রাউজার সিকিউরিটি ইঞ্জিনিয়ার হন এবং জানতে চান ওয়েব প্রক্সি আসলে সেম-অরিজিন পলিসির সাথে কীভাবে ইন্টারঅ্যাক্ট করে — শুধু কনসেপ্চুয়াল লেভেলে নয়, HTTP হেডার, Chromium সোর্স কোড এবং প্রোডাকশন ইঞ্জিনিয়ারিং ট্রেড-অফের স্তরে — এই লেখাটা আপনার জন্য।

আমরা SOP ফাউন্ডেশন, URL রিরাইটিং, CORS, CORB/CORP, COEP/COOP, Service Workers, iframe, এবং প্রক্সি অপারেটর ও ব্যবহারকারী উভয়ের জন্য সিকিউরিটি ইম্প্লিকেশন কভার করব।

১. সেম-অরিজিন পলিসির ভিত্তি

সেম-অরিজিন পলিসি (SOP) একটি তিন-টুপল দিয়ে সংজ্ঞায়িত: scheme + host + port। দুটো URL কেবল তখনই সেম-অরিজিন যখন তিনটি কম্পোনেন্ট হুবহু মিলে যায়। https://example.com:443 এবং http://example.com:80 একই সার্ভারে পয়েন্ট করলেও ক্রস-অরিজিন।

প্রায়ই ভুল বোঝা যায় যে SOP আসলে কী প্রতিরোধ করে আর কী করে না। SOP নিচেরগুলো ব্লক করে না:

ইমেজ লোড করা (<img src>) ক্রস-অরিজিন থেকে
স্ক্রিপ্ট লোড করা (<script src>) ক্রস-অরিজিন থেকে
স্টাইলশিট লোড করা (<link rel="stylesheet">) ক্রস-অরিজিন থেকে
iframe এমবেড করা ক্রস-অরিজিন থেকে (যদিও এমবেড করা ডকুমেন্টের কন্টেন্ট আইসোলেটেড থাকে)
ফর্ম সাবমিশন পাঠানো (<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 __pot (proxy origin token) নামের একটা URL প্যারামিটার ব্যবহার করে যেখানে টার্গেট অরিজিনের Base64-এনকোডেড ভ্যালু থাকে।

`__pot` প্যারামিটার

__pot প্যারামিটার সবসময় টার্গেটের অরিজিন এনকোড করে (scheme + host, কোনো পাথ নেই) — পুরো URL নয়। এর মানে https://example.com/some/deep/path?foo=bar এবং https://example.com/other/page দুটোই একই __pot ভ্যালু জেনারেট করে: aHR0cHM6Ly9leGFtcGxlLmNvbQ== (যা https://example.com-এর Base64 এনকোডিং)। আসল পাথ এবং কোয়েরি স্ট্রিং প্রক্সি URL-এর নিজস্ব পাথ ও কোয়েরি স্ট্রিংয়ে হুবহু সংরক্ষিত থাকে।

কোনো ব্যবহারকারী 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 রেসপন্সে URL রিরাইট করা যাতে সব সাব-রিকোয়েস্ট প্রক্সির মধ্য দিয়ে যায় — সেটা 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 প্যারামিটার নেই — যেমন, Service Worker URL রিরাইট করার আগে একটা রিলেটিভ fetch('/api/data') ফায়ার হয়ে যায়, বা 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 যখন নন-সিম্পল হেডার সহ fetch() রিকোয়েস্ট করে (যেমন Authorization, Content-Type: application/json), ব্রাউজার আগে একটা 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 স্পেকে সংজ্ঞায়িত MIME-টাইপ স্নিফার ব্যবহার করে) এবং টাইপ মিলে গেলে রেন্ডারার সেটা দেখার আগেই খালি রেসপন্স দিয়ে রিপ্লেস করে।

একটা ওয়েব প্রক্সির জন্য CORB মারাত্মক হতো যদি রিকোয়েস্টগুলো আসলেই ক্রস-অরিজিন হতো। <script> ট্যাগ থেকে ফেচ করা application/json রিটার্নকারী একটা API এন্ডপয়েন্ট চুপচাপ খালি ফিরিয়ে দিত। কিন্তু ProxyOrb যেহেতু সব URL সেম-অরিজিন করে রিরাইট করে, CORB-এর ক্রস-অরিজিন কন্ডিশন কখনো ট্রিগার হয় না — ব্রাউজার কখনো ক্রস-অরিজিন JSON রেসপন্স দেখে না, কারণ তার দৃষ্টিকোণ থেকে সব রেসপন্স proxyorb.com থেকে আসছে।

CORB যেখানে গুরুত্বপূর্ণ হয় সেটা হলো Service Worker সম্পূর্ণভাবে রেজিস্টার হয়ে রিকোয়েস্ট ইন্টারসেপ্ট করার আগের ট্রানজিশন পিরিয়ড। সেই উইন্ডোতে কোনো রিকোয়েস্ট URL রিরাইটিং এড়িয়ে গেলে CORB সেটা ব্লক করতে পারে। এই রেস কন্ডিশনের কারণেই ProxyOrb একটা মেইন-থ্রেড ইন্টারসেপ্টর লেয়ার রাখে যা Service Worker স্টার্টআপের সময় ফলব্যাক হিসেবে পেজের যেকোনো JavaScript চলার আগেই XMLHttpRequest, fetch এবং DOM অ্যাট্রিবিউট সেটার সিঙ্ক্রোনাসলি প্যাচ করে।

উল্লেখযোগ্য যে CORB আংশিকভাবে Opaque Response Blocking (ORB) দিয়ে প্রতিস্থাপিত হচ্ছে, যেটা Chromium অ্যাডপ্ট করার প্রক্রিয়ায় আছে। ORB CORB নিয়মগুলো পরিমার্জন করে Spectre সুরক্ষা বজায় রেখে ফলস পজিটিভ কমায়। প্রক্সি কম্পাটিবিলিটির ইম্প্লিকেশন একই রকম।

ক্রস-অরিজিন রিসোর্স পলিসি (CORP)

CORP, Fetch স্পেকে সংজ্ঞায়িত, সার্ভারগুলোকে ঘোষণা করতে দেয় যে তাদের রিসোর্স কেবল সেম-অরিজিন বা সেম-সাইট কনটেক্সট থেকে লোড হওয়া উচিত:

Cross-Origin-Resource-Policy: same-origin

Chromium ক্রস-অরিজিন সাব-রিসোর্স রিকোয়েস্টে এই হেডার পেলে রেসপন্স সম্পূর্ণ ব্লক করে দেয়। এটা CORB-এর চেয়েও আক্রমণাত্মক — কন্টেন্ট টাইপ নির্বিশেষে প্রযোজ্য এবং MIME স্নিফিং দিয়ে বাইপাস করা যায় না।

আবার, ProxyOrb-এর URL রিরাইটিং ব্রাউজারের দৃষ্টিকোণ থেকে সব রিকোয়েস্ট সেম-অরিজিন নিশ্চিত করে বলে টার্গেট সার্ভারের CORP হেডার ব্লকিং ট্রিগার করে না। গেটওয়েও ডিফেনসিভলি রেসপন্স থেকে এই হেডারগুলো স্ট্রিপ করে, যেসব এজ কেসে রিকোয়েস্ট URL রিরাইটিং ছাড়া পার হয়ে যায় সেগুলো হ্যান্ডেল করতে।

CORP-এর আরও গভীর সমস্যাটা আসলে এমন একটা ক্ষেত্র যেখানে প্রক্সি আর্কিটেকচার কম্পাটিবিলিটিতে সাহায্য করে: যদি https://api.example.com এবং https://www.example.com উভয়ই প্রক্সি করা হচ্ছে, তাহলে দুটোই একই প্রক্সি অরিজিনে ম্যাপ হয়, তাই একটা থেকে অন্যটায় fetch এখন সত্যিকার অর্থেই সেম-অরিজিন — তাদের মধ্যে CORP বিধিনিষেধ আর প্রযোজ্য নয়।

৫. COEP এবং COOP: ক্রস-অরিজিন আইসোলেশন

Chrome 92 (2021) থেকে SharedArrayBuffer-এ অ্যাক্সেস — এবং তার সাথে নির্দিষ্ট পারফরম্যান্স API-র জন্য ব্যবহৃত হাই-রেজোলিউশন টাইমার — শুধুমাত্র সেই পেজগুলোতে সীমাবদ্ধ করা হয়েছে যেগুলো ক্রস-অরিজিন আইসোলেশন-এ অপ্ট ইন করেছে। এই অপ্ট-ইনের জন্য দুটো রেসপন্স হেডার একসাথে কাজ করতে হয়।

Cross-Origin-Embedder-Policy (COEP)

Cross-Origin-Embedder-Policy: require-corp

কোনো পেজ এই হেডার পাঠালে ব্রাউজার এনফোর্স করে যে সেই পেজ লোড করা প্রতিটা সাব-রিসোর্স হয়: ১. সেম-অরিজিন, অথবা ২. এক্সপ্লিসিটলি Cross-Origin-Resource-Policy: cross-origin পাঠায়, অথবা ৩. ক্রেডেনশিয়ালড fetch-এর জন্য পার্মিসিভ 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 স্ট্রিপ করে। এটা সাইট কম্পাটিবিলিটি সর্বোচ্চ করে। সিকিউরিটি ট্রেড-অফ সচেতনভাবে নেওয়া: ওয়েব প্রক্সির ব্যবহারকারীরা মেনে নিচ্ছেন যে তারা কন্টেন্ট তার উদ্দেশ্যমূলক ডেপ্লয়মেন্ট কনটেক্সট থেকে ভিন্ন পরিবেশে চালাচ্ছেন।

প্রতিটা নতুন ব্রাউজার সিকিউরিটি মেকানিজম একটা প্যাটার্ন অনুসরণ করে: অপ্ট-ইন হিসেবে পরিচিত হয় (সাইটগুলো সুরক্ষা চাইলে হেডার পাঠাতে পারে), তারপর ধীরে ধীরে নতুন API-এর জন্য ডিফল্ট হয়, এবং শেষমেশ বাধ্যতামূলক এনফোর্সমেন্ট বিবেচিত হয়। COEP এই পথে গেছে: Chrome 83-এ অপশনাল, Chrome 91-এ SharedArrayBuffer-এর জন্য বাধ্যতামূলক। থার্ড-পার্টি কন্টেন্ট এমবেড করা সাইটগুলো যেগুলো কো-অর্ডিনেশন ছাড়া কাজ করত তাদের কন্টেন্ট ভেঙে যেতে দেখল। ওয়েব প্রক্সি এই সমস্যা জটিল করে কারণ তারা সংজ্ঞার দিক থেকেই থার্ড-পার্টি কন্টেন্টের মধ্যস্থতা করে।

ব্রাউজার সিকিউরিটি কমিউনিটি এই সমস্যা সম্পর্কে সচেতন। উদীয়মান Document-Isolation-Policy প্রপোজালের লক্ষ্য হলো প্রসেস আইসোলেশনকে ক্রস-অরিজিন আইসোলেশন রিকোয়ারমেন্ট থেকে আলাদা করা, সম্ভাব্যভাবে সব সাব-রিসোর্সকে অপ্ট ইন করানো ছাড়াই Spectre মিটিগেশন পাওয়া সম্ভব করবে। সেটা শিপ হলে আইসোলেশন হেডারের সাথে প্রক্সি কম্পাটিবিলিটি উন্নত হতে পারে।

৬. Service Worker ব্রাউজার-সাইড ট্রাস্ট লেয়ার হিসেবে

Service Worker শুধু একটা অপ্টিমাইজেশন নয় — এটা আর্কিটেকচারালভাবে ProxyOrb-এর সিকিউরিটি মডেলের জন্য অপরিহার্য। কারণটা এখানে।

রেজিস্ট্রেশন স্কোপ অরিজিনের সাথে বাঁধা

Service Worker সবসময় রেজিস্ট্রেশনকারী পেজের অরিজিনের মধ্যে একটা scope দিয়ে রেজিস্টার হয়। ProxyOrb তার Service Worker রেজিস্টার করলে স্কোপ হয় https://proxyorb.com/, মানে সেই অরিজিনের যেকোনো পেজ থেকে প্রতিটা fetch ইন্টারসেপ্ট করে।

এটাই মূল কারণ কেন সেম-অরিজিনে URL রিরাইটিং কাজ করে: একবার SW কোনো ক্লায়েন্ট নিয়ন্ত্রণ করলে, সেই ক্লায়েন্ট থেকে প্রতিটা নেটওয়ার্ক রিকোয়েস্ট — পেজের JavaScript যাই ফেচ করার চেষ্টা করুক না কেন — আগে 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)

ট্রান্সপারেন্ট হেডার ফরওয়ার্ডিং

একটা সূক্ষ্ম চ্যালেঞ্জ হলো: ব্রাউজার Fetch API দিয়ে কিছু "forbidden" রিকোয়েস্ট হেডার (Host, Origin, Referer, ইত্যাদি) সেট করতে JavaScript-কে বাধা দেয়। 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 ইনজেক্ট করতে পারলে, তারা আক্রান্ত ব্যবহারকারীদের সব ট্র্যাফিক ইন্টারসেপ্ট করতে পারত — শুধু প্রক্সি ট্র্যাফিক নয়, সেই অরিজিনের পেজ থেকে যেকোনো রিকোয়েস্ট।

৭. iframe: ফ্রেম-অ্যান্সেস্টর্স সমস্যা

iframe সাধারণ সাব-রিসোর্স থেকে আলাদা চ্যালেঞ্জ কারণ এতে আলাদা নেভিগেশন, আলাদা SOP বাউন্ডারি এবং নিজস্ব এমবেডিং বিধিনিষেধ সহ একটা নেস্টেড ব্রাউজিং কনটেক্সট জড়িত।

`X-Frame-Options` এবং `frame-ancestors`

দুটো মেকানিজম পেজকে iframe-এ এমবেড হতে বাধা দেয়:

লিগ্যাসি: 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 ইন্টারসেপশন এবং স্ক্রিপ্ট ইনজেকশন

এমবেড করা iframe একটা দ্বিতীয় সমস্যা তৈরি করে: তাদের কন্টেন্ট প্রক্সি থেকে লোড হয়, কিন্তু 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-ইনসার্ট করা iframe ধরে):

-- 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 হেডার প্রকাশ করে ব্যবহারকারী কোন পেজ দেখছিল। প্রক্সি টার্গেট সার্ভারে ফরওয়ার্ড করার আগে 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 ফাইল মডিফাই করা হয় (URL রিরাইট করা হয়) এবং প্রক্সির অরিজিনে এক্সিকিউট হয়। ProxyOrb-এর মাধ্যমে প্রক্সি করা evil.example.com-এর একটা ম্যালিশাস স্ক্রিপ্ট proxyorb.com অরিজিনে চলে এবং সেই অরিজিনের লোকাল স্টোরেজ, কুকি এবং IndexedDB-তে সম্পূর্ণ অ্যাক্সেস পায় — যার মধ্যে প্রক্সির মাধ্যমে ব্যবহারকারী অ্যাক্সেস করা অন্য সব টার্গেট সাইটের ডেটাও আছে।

ম্যালিশাস প্রক্সি থ্রেট মডেল

শিক্ষামূলক উদ্দেশ্যে, একটা ম্যালিশাস প্রক্সি কী করতে পারত তা স্পষ্টভাবে বলা দরকার যা ProxyOrb ইচ্ছাকৃতভাবে করে না:

১. ক্রেডেনশিয়াল হার্ভেস্টিং: একটা ম্যালিশাস প্রক্সি গেটওয়ের মধ্য দিয়ে যাওয়া প্রতিটা রিকোয়েস্ট বডি (পাসওয়ার্ড ও ফর্ম ডেটা সহ) লগ করতে পারত।

২. সেশন হাইজ্যাকিং: সব টার্গেট সাইটের কুকি প্রক্সি ডোমেইনের অধীনে স্টোর হওয়ায়, একটা ম্যালিশাস প্রক্সি অপারেটর গেটওয়ের মাধ্যমে সার্ভার-সাইড থেকে সেই কুকি অ্যাক্সেস করতে পারত।

৩. কন্টেন্ট ইনজেকশন: প্রক্সি অবশ্যই পেজ কন্টেন্ট মডিফাই করে (Service Worker ইনজেক্ট করতে এবং URL রিরাইট করতে)। একটা ম্যালিশাস প্রক্সি আর্বিট্রারি JavaScript ইনজেক্ট করতে পারত — কীলগার, ক্রিপ্টো মাইনার, অ্যাড ফ্রড স্ক্রিপ্ট — ব্যবহারকারীর কাছে অদৃশ্য থেকে।

৪. SSL স্ট্রিপিং: প্রক্সি গেটওয়ে-থেকে-ব্যবহারকারী লেগের জন্য HTTPS কানেকশন HTTP-তে ডাউনগ্রেড করলে সব ট্র্যাফিক প্লেইনটেক্সট হয়ে যায়।

ProxyOrb এন্ড-টু-এন্ড HTTPS-এ কাজ করে এবং রিকোয়েস্ট বডি লগ করে না। যেকোনো ওয়েব প্রক্সির অপারেটরের এই ক্ষমতা থাকে, তাই একটা বিশ্বস্ত প্রক্সি অপারেটর বেছে নেওয়া একটা বিশ্বস্ত VPN প্রোভাইডার বেছে নেওয়ার মতোই গুরুত্বপূর্ণ।

মিক্সড কন্টেন্ট

আধুনিক ব্রাউজার মিক্সড কন্টেন্ট ব্লকিং এনফোর্স করে: একটা HTTPS পেজ HTTP সাব-রিসোর্স লোড করতে পারে না। ProxyOrb এটা হ্যান্ডেল করে গেটওয়ে থেকে সব আউটবাউন্ড কানেকশনে HTTPS এনফোর্স করে, টার্গেট URL HTTP ব্যবহার করলেও। CSP ওভাররাইডে upgrade-insecure-requests আছে যা ব্রাউজারকে লোড করার আগে যেকোনো HTTP সাব-রিসোর্স URL HTTPS-এ আপগ্রেড করতে বলে।

এটা সাধারণত কাম্য, কিন্তু ইচ্ছাকৃতভাবে HTTP-তে রিসোর্স সার্ভ করা সাইট ভাঙতে পারে (লিগ্যাসি CDN, লোকালহোস্ট রিসোর্স, ইত্যাদি)।

৯. চলমান আর্মস রেস: উপসংহার

ProxyOrb বানাতে শুরু করার সময় প্রাথমিক কম্পাটিবিলিটি চ্যালেঞ্জ ছিল CORS এবং X-Frame-Options। তারপর থেকে Chromium CORB, CORP, COEP, COOP শিপ করেছে এবং Document-Isolation-Policy ডেভেলপ করছে। যাত্রার দিক স্পষ্ট: ব্রাউজারগুলো ক্রস-অরিজিন বাউন্ডারি এনফোর্সে ক্রমশ আক্রমণাত্মক হচ্ছে, এবং প্রতিটা নতুন মেকানিজম প্রক্সি ইনফ্রাস্ট্রাকচারকে মানিয়ে নিতে বাধ্য করছে।

সবচেয়ে উল্লেখযোগ্য আসন্ন চ্যালেঞ্জ সম্ভবত প্রধান ওয়েব অ্যাপ্লিকেশনে COEP-এর পূর্ণ ডেপ্লয়মেন্ট। পারফরম্যান্সের জন্য SharedArrayBuffer ব্যবহার করা সাইটগুলো (ভিডিও এডিটর, IDE, কোলাবোরেশন টুল) ক্রমশ COEP: require-corp সেট করছে। ProxyOrb কম্পাটিবিলিটি রক্ষায় এই হেডার স্ট্রিপ করায়, COEP এনেবল হাই-পারফরম্যান্স ফিচার প্রয়োজন এমন ব্যবহারকারীরা প্রক্সি কনটেক্সটে সেগুলো ডিগ্রেডেড পাবেন।

সিকিউরিটি রিসার্চারদের জন্য, প্রক্সি আর্কিটেকচার একটা গুরুত্বপূর্ণ বিষয় প্রকাশ করে: সেম-অরিজিন পলিসি কোনো ফায়ারওয়াল নয়। এটা URL স্ট্রাকচারের উপর ভিত্তি করে বিশ্বাসের একটা মডেল। ওয়েব প্রক্সি এই সত্যটা কাজে লাগায় যে SOP "এই দুটো রিসোর্স আসলেই সেম-অরিজিন" এবং "এই দুটো রিসোর্স সেম-অরিজিন দেখানোর জন্য URL-রিরাইট করা হয়েছে"-এর মধ্যে কোনো অন্তর্নিহিত পার্থক্য করে না। SOP-এর উপরে পুরো ব্রাউজার সিকিউরিটি স্ট্যাক — CORS, CORB, CORP, COEP, COOP — URL-ভিত্তিক অরিজিন আইডেন্টিটির চেয়ে আরও শক্তিশালী প্রতিরক্ষা যোগ করার প্রচেষ্টা হিসেবে দেখা যায়।

প্রক্সি সার্ভিস অডিট করা, ব্রাউজার সিকিউরিটি পলিসি ডিজাইন করা, বা প্রক্সির মাধ্যমে অ্যাক্সেস হতে পারে এমন অ্যাপ্লিকেশনের বাস্তব-বিশ্ব সিকিউরিটি পস্চার মূল্যায়ন করা যে কারো জন্য এটা বোঝা অপরিহার্য।

সচরাচর জিজ্ঞাসা

ওয়েব প্রক্সি কি সেম-অরিজিন পলিসি বাইপাস করে?

ঠিক তা নয়। ওয়েব প্রক্সি URL রিরাইটিংয়ের মাধ্যমে কাজ করে: এটা সব ক্রস-অরিজিন URL-কে সেম-অরিজিন URL-এ রূপান্তরিত করে, SOP-এর ক্রস-অরিজিন বিধিনিষেধ বাইপাস করার বদলে অপ্রাসঙ্গিক করে তোলে। ব্রাউজারের দৃষ্টিকোণ থেকে সব কন্টেন্ট প্রক্সির নিজস্ব অরিজিন থেকে আসছে বলে মনে হয়, তাই কোনো ক্রস-অরিজিন বাউন্ডারি অতিক্রম করা হয় না। এটা আর্কিটেকচারালভাবে বাইপাস থেকে আলাদা — SOP এখনো তার নিয়ম প্রয়োগ করে; প্রক্সি শুধু কন্টেন্ট এমনভাবে তৈরি করে যাতে সেই নিয়মগুলো কখনো ট্রিগার না হয়।

CORS ওয়েব প্রক্সি সার্ভারকে কীভাবে প্রভাবিত করে?

CORS প্রক্সি সার্ভারকে দুটো স্তরে প্রভাবিত করে। প্রথমত, প্রক্সিকে OPTIONS প্রিফ্লাইট রিকোয়েস্ট ইন্টারসেপ্ট করে পার্মিসিভ CORS হেডার দিয়ে জবাব দিতে হবে, কারণ আসল টার্গেট সার্ভারের প্রিফ্লাইট রেসপন্স (টার্গেট অরিজিন রেফারেন্স করে) প্রক্সি অরিজিনের জন্য ব্রাউজারের CORS চেক পাস করবে না। দ্বিতীয়ত, প্রক্সিকে টার্গেট সার্ভার রেসপন্স থেকে CORS হেডার স্ট্রিপ করে প্রক্সি অরিজিন রেফারেন্স করা হেডার দিয়ে রিপ্লেস করতে হবে। Service Worker-এ credentials: 'include'-এর সাথে Access-Control-Allow-Credentials: true সেটিং মানে প্রক্সির অরিজিনের সব কুকি প্রতিটা প্রক্সি রিকোয়েস্টের সাথে যায়।

CORB কী এবং এটা প্রক্সি সার্ভিসকে কীভাবে প্রভাবিত করে?

ক্রস-অরিজিন রিড ব্লকিং (CORB) হলো একটা Chromium প্রতিরক্ষা যা নির্দিষ্ট সেনসিটিভ ক্রস-অরিজিন রেসপন্স (HTML, JSON, XML) ক্রস-অরিজিন সাব-রিসোর্স হিসেবে লোড হলে রেন্ডারার প্রসেসে প্রবেশ করতে বাধা দেয়। সঠিকভাবে কনফিগার করা ওয়েব প্রক্সির জন্য, CORB সাধারণত ট্রিগার হয় না কারণ URL রিরাইটিং সব রিকোয়েস্ট সেম-অরিজিন করে। তবে, Service Worker সম্পূর্ণ রেজিস্টার হওয়ার আগের পিরিয়ডে CORB সমস্যা করতে পারে, যখন কিছু রিকোয়েস্ট URL রিরাইটিং এড়িয়ে সত্যিকার ক্রস-অরিজিন রিকোয়েস্ট হিসেবে পাঠানো হতে পারে। CORB Spectre মিটিগেশন হিসেবে চালু হয়েছিল এবং WHATWG Fetch স্পেসিফিকেশনে সংজ্ঞায়িত।

ওয়েব প্রক্সি কি HTTP-only কুকি অ্যাক্সেস করতে পারে?

না। HttpOnly কুকি টার্গেট সার্ভার সেট করে এবং JavaScript দিয়ে পড়া যায় না — Service Worker-এ চলা JavaScript সহ। তবে, গেটওয়ে এই কুকি পায় যখন ব্যবহারকারীর পক্ষে রিকোয়েস্ট ফরওয়ার্ড করে, কারণ ব্রাউজার সেগুলো রিকোয়েস্ট হেডারে পাঠায়। HttpOnly ফ্ল্যাগ ক্লায়েন্ট-সাইড JavaScript চুরি থেকে সুরক্ষা দেয় কিন্তু প্রক্সি সার্ভার নিজে ট্রানজিটে কুকি ভ্যালু দেখতে পারে। এটা অনেকটা সেরকম: HttpOnly XSS থেকে রক্ষা করে কিন্তু সার্ভার-সাইড ইন্টারসেপশন থেকে নয়।

ব্রাউজার সিকিউরিটির দৃষ্টিকোণ থেকে ওয়েব প্রক্সি ব্যবহার কি নিরাপদ?

এটা থ্রেট মডেলের উপর নির্ভর করে। ব্রাউজারের দৃষ্টিকোণ থেকে, ওয়েব প্রক্সির মাধ্যমে সার্ভ করা সব কন্টেন্ট প্রক্সির অরিজিনে চলে, মানে একটা প্রক্সি করা সাইটের JavaScript-এ দুর্বলতা অন্য প্রক্সি করা সাইটের সেশন ডেটা অ্যাক্সেস করতে পারে (যেহেতু তারা একই অরিজিনের কুকি জার এবং স্টোরেজ শেয়ার করে)। প্রক্সির অপারেটরও একটা ট্রাস্টেড পার্টি যার ট্রানজিটে সব ট্র্যাফিকে অ্যাক্সেস আছে। সীমাবদ্ধ পরিবেশে নন-সেনসিটিভ কন্টেন্ট অ্যাক্সেস করার জন্য ঝুঁকি সাধারণত গ্রহণযোগ্য। সেনসিটিভ সার্ভিসের (ব্যাংকিং, স্বাস্থ্যসেবা, সরকার) অথেনটিকেটেড সেশনের জন্য, ব্যবহারকারীদের বোঝা উচিত যে প্রক্সি অপারেটরের সেই ট্র্যাফিক পর্যবেক্ষণের টেকনিক্যাল ক্ষমতা আছে, এবং কেবল অডিটেবল নো-লগ পলিসি ও শক্তিশালী অপারেশনাল সিকিউরিটি প্র্যাকটিস সম্পন্ন প্রক্সি সার্ভিস ব্যবহার করা উচিত।

এই আর্টিকেলটা ২০২৬ সালের প্রথম দিকে ProxyOrb-এর আর্কিটেকচার প্রতিফলিত করে। ব্রাউজার সিকিউরিটি মেকানিজম দ্রুত পরিবর্তিত হয়; পাঠকদের সর্বশেষ তথ্যের জন্য WHATWG Fetch Standard, W3C Content Security Policy specification, এবং Chromium-এর সিকিউরিটি ডিজাইন ডকুমেন্ট দেখার পরামর্শ দেওয়া হচ্ছে।