Перейти к основному содержанию

Политика одного источника и веб-прокси: технический разбор безопасности

Автор
Smith
Smith
Время чтения
1 мин чтения
Опубликовано
2 мар. 2026 г.
Политика одного источника и веб-прокси: технический разбор безопасности

Когда мы строили ProxyOrb, на каждом шагу нас преследовал фундаментальный парадокс: веб-прокси работает именно потому, что заставляет браузер считать контент третьих сторон контентом того же источника. По сути, это намеренный обман базовой модели безопасности браузера. При этом современные браузеры последние пятнадцать лет методично добавляют всё более изощрённые защитные слои именно против подобной путаницы с источниками.

В этой статье мы разберём это противоречие с первых принципов. Если вы — исследователь безопасности, пентестер или инженер по браузерной безопасности и хотите понять, как веб-прокси реально взаимодействует с политикой одного источника — не на концептуальном уровне, а на уровне HTTP-заголовков, исходников Chromium и инженерных компромиссов в production — эта статья для вас.

Мы разберём: основы SOP, перезапись URL, CORS, CORB/CORP, COEP/COOP, Service Workers, iframes и последствия для безопасности — как для операторов прокси, так и для их пользователей.

1. Фундамент политики одного источника

Политика одного источника (SOP) определяется тройкой: схема + хост + порт. Два URL считаются одноисточниковыми только при точном совпадении всех трёх компонентов. https://example.com:443 и http://example.com:80 — разные источники, несмотря на то что указывают на один сервер.

Что чаще всего понимают неправильно — это что именно SOP запрещает, а что разрешает. SOP не блокирует:

  • Загрузку изображений (<img src>) из других источников
  • Загрузку скриптов (<script src>) из других источников
  • Загрузку стилей (<link rel="stylesheet">) из других источников
  • Встраивание iframes из других источников (хотя содержимое встроенного документа изолировано)
  • Отправку форм (<form action>) на другие источники

SOP запрещает именно чтение ответа на кросс-оригинные запросы через fetch() или XMLHttpRequest. Запрос уходит — сетевой round-trip происходит — но тело ответа и заголовки скрываются от JavaScript, работающего в другом источнике.

Это различие критично для понимания веб-прокси. Вся задача прокси — свернуть два источника (сервер прокси и целевой сервер) в один, устранив кросс-оригинную границу. Когда все ресурсы как будто приходят с https://proxyorb.com, ограничения SOP на чтение ответов просто перестают применяться.

«Легальная лазейка», которую эксплуатируют веб-прокси — это перезапись URL: вместо https://example.com/api/data каждый запрос превращается в https://proxyorb.com/api/data?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ==. С точки зрения браузера — это запрос к тому же источнику. SOP не обходится — он становится нерелевантным, потому что видимый источник всего контента изменён.

2. Архитектура перезаписи URL в ProxyOrb

Чтобы понять последствия для безопасности, нужно разобраться в механизме кодирования. ProxyOrb использует URL-параметр __pot (proxy origin token) — Base64-кодированный целевой источник.

Параметр __pot

Параметр __pot всегда кодирует именно источник (схема + хост, без пути) цели, а не полный URL. Это значит, что https://example.com/some/deep/path?foo=bar и https://example.com/other/page дают одинаковое значение __pot: aHR0cHM6Ly9leGFtcGxlLmNvbQ== (Base64 от https://example.com). Реальный путь и строка запроса сохраняются как есть в пути и строке запроса 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 так, чтобы upstream-сервер видел свой собственный домен, а не домен прокси:

-- 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

Перезапись URL на стороне клиента через Service Worker

Шлюз закрывает серверную сторону. Клиентская часть — перезапись URL в HTML, JavaScript и CSS ответах, чтобы все подзапросы продолжали идти через прокси — реализована через 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 страницы до того, как шлюз получил запрос.

3. CORS: явная система разрешений для кросс-оригинного доступа

CORS (Cross-Origin Resource Sharing) создавался для того, чтобы серверы могли явно разрешать кросс-оригинный доступ, отправляя специальные заголовки ответа. С точки зрения прокси, CORS создаёт две отдельные проблемы.

Проблема 1: перехват CORS preflight

Когда JavaScript на странице делает запрос fetch() с нестандартными заголовками (например, Authorization, Content-Type: application/json), браузер сначала отправляет предварительный OPTIONS-запрос. Если ответ целевого сервера на preflight не содержит разрешающих 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"

Проблема 2: запросы с учётными данными

Сочетание Access-Control-Allow-Credentials: true и не-wildcard значения Access-Control-Allow-Origin принципиально важно. CORS требует явного значения источника (не *) при наличии учётных данных. Service Worker делает все исходящие запросы с credentials: 'include', поэтому шлюз должен возвращать точно тот источник запроса, а не wildcard.

Это означает, что все куки, накопленные под proxyorb.com — со всех целевых сайтов, которые пользователь посетил через прокси — отправляются с каждым проксируемым запросом. Это сделано намеренно (поддержание состояния сессии для авторизованных сайтов), но это также важный аспект безопасности, который мы рассматриваем в разделе 8.

Паттерн «удалить и заменить» 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

4. CORB и CORP: более жёсткая защита от Chromium

CORS работает на явном согласии серверов. Chromium добавил два механизма, которые активны по умолчанию — вне зависимости от конфигурации CORS.

Cross-Origin Read Blocking (CORB)

CORB появился в Chrome 67 (2018) как часть мер против атак типа Spectre. Ключевая идея: даже если тело кросс-оригинного ответа никогда не читается JavaScript, сам факт его получения и декодирования процессом рендерера означает, что оно существует в адресном пространстве этого процесса. Атаки класса Spectre могут затем извлечь его через side-каналы.

CORB не даёт определённым кросс-оригинным ответам попасть в процесс рендерера вовсе. Конкретно: когда тег <script> или <img> получает кросс-оригинный ответ с Content-Type равным text/html, text/xml или application/json, Chromium инспектирует тело (используя MIME-type sniffer из спецификации CORB) и, если тип совпадает, подменяет ответ пустым, прежде чем рендерер его увидит.

Для веб-прокси CORB был бы катастрофой, если бы запросы действительно были кросс-оригинными. API-endpoint, возвращающий application/json и загруженный тегом <script>, молча вернул бы пустоту. Однако поскольку ProxyOrb переписывает все URL в одноисточниковые, условие кросс-оригинности для CORB никогда не срабатывает — браузер не видит кросс-оригинных JSON-ответов, потому что с его точки зрения все ответы приходят с proxyorb.com.

Случай, когда CORB имеет значение — это переходный период до того, как Service Worker полностью зарегистрирован и начал перехватывать запросы. Если какой-то запрос успел уйти без перезаписи URL в этом окне, CORB может его заблокировать. Это гонка состояний — именно поэтому ProxyOrb поддерживает основной перехватчик в главном потоке, который синхронно патчит XMLHttpRequest, fetch и сеттеры атрибутов DOM ещё до запуска любого JavaScript страницы — как запасной вариант на время старта Service Worker.

Стоит отметить, что CORB частично вытесняется Opaque Response Blocking (ORB), который Chromium постепенно внедряет. ORB уточняет правила CORB, чтобы уменьшить ложные срабатывания, сохраняя защиту от Spectre. Последствия для совместимости прокси — схожие.

Cross-Origin Resource Policy (CORP)

CORP, определённый в спецификации Fetch, позволяет серверам объявить, что их ресурсы должны загружаться только из того же источника или того же сайта:

Cross-Origin-Resource-Policy: same-origin

Когда Chromium встречает этот заголовок на кросс-оригинном запросе подресурса, ответ блокируется полностью. Это агрессивнее, чем CORB — применяется независимо от типа контента и не обходится через MIME-sniffing.

Снова: поскольку перезапись URL в ProxyOrb делает все запросы одноисточниковыми с точки зрения браузера, заголовки CORP от целевых серверов не вызывают блокировки. Шлюз также превентивно удаляет эти заголовки из ответов, обрабатывая граничные случаи, когда запрос прошёл без перезаписи URL.

Более глубокая проблема с CORP — это случай, когда архитектура прокси улучшает совместимость: если https://api.example.com и https://www.example.com оба проксируются, оба отображаются на один источник прокси, поэтому запрос от одного к другому становится по-настоящему одноисточниковым — ограничения CORP между ними перестают действовать.

5. COEP и COOP: кросс-оригин изоляция

Начиная с Chrome 92 (2021), доступ к SharedArrayBuffer — и соответственно к высокоточным таймерам, используемым в определённых performance API — был ограничен страницами, выбравшими кросс-оригин изоляцию. Для этого требуется совместная работа двух заголовков ответа.

Cross-Origin-Embedder-Policy (COEP)

Cross-Origin-Embedder-Policy: require-corp

Когда страница отправляет этот заголовок, браузер требует, чтобы каждый подресурс, загружаемый этой страницей, либо:

  1. Был из того же источника, ИЛИ
  2. Явно отправлял Cross-Origin-Resource-Policy: cross-origin, ИЛИ
  3. Имел разрешающий CORS-ответ для credentialed fetch

Проблема для веб-прокси: если целевой сайт отправляет 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:

Вариант А: удалить COEP и COOP из ответов.

  • Плюс: загрузка подресурсов работает нормально; проксируемая страница не применяет эти ограничения.
  • Минус: мы удаляем заголовки безопасности, которые целевой сайт намеренно выставил. Если сайт использовал кросс-оригин изоляцию для защиты чувствительных данных от атак класса Spectre, удаление этих заголовков восстанавливает этот риск.

Вариант Б: сохранить COEP и COOP.

  • Плюс: намерение целевого сайта по безопасности соблюдается.
  • Минус: любой подресурс, не установивший явно CORP: cross-origin, не загрузится, что сломает большинство сложных веб-приложений.

Текущая стратегия ProxyOrb — Вариант А: шлюз удаляет Cross-Origin-Embedder-Policy и Cross-Origin-Opener-Policy из ответов. Это максимизирует совместимость с сайтами. Компромисс по безопасности принимается осознанно: пользователи веб-прокси принимают, что они запускают контент в среде, отличной от его целевого контекста развёртывания.

Каждый новый механизм безопасности браузера следует одной схеме: сначала вводится как opt-in (сайты могут добавить заголовок, если хотят защиту), затем постепенно становится обязательным для новых API, и в итоге рассматривается для принудительного применения. COEP следовал этому пути: опционален в Chrome 83, обязателен для SharedArrayBuffer в Chrome 91. Сайты, встраивающие сторонний контент без предварительной договорённости, обнаружили, что контент сломался. Веб-прокси усугубляют эту проблему, потому что по определению посредничают с чужим контентом.

Сообщество браузерной безопасности знает об этой проблеме. Разрабатываемый стандарт Document-Isolation-Policy призван разделить изоляцию процессов и требования кросс-оригин изоляции, что потенциально позволит получить защиту от Spectre без требования явного согласия от всех подресурсов. Когда это появится, совместимость прокси с заголовками изоляции может улучшиться.

6. Service Worker как доверенный слой на стороне браузера

Service Worker — не просто оптимизация. Он архитектурно необходим для модели безопасности ProxyOrb. Вот почему.

Область регистрации привязана к источнику

Service Worker регистрируется со scope, который всегда находится внутри источника регистрирующей страницы. Когда ProxyOrb регистрирует свой Service Worker, scope — https://proxyorb.com/, то есть он перехватывает каждый fetch с любой страницы под этим источником.

Это фундаментальная причина, почему перезапись URL в одноисточниковый работает: как только SW управляет клиентом, каждый сетевой запрос от этого клиента — независимо от того, к какому URL пытается обратиться 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)

Прозрачная передача заголовков

Тонкая задача: браузер запрещает JavaScript устанавливать определённые «запрещённые» заголовки запроса (Host, Origin, Referer и т.д.) через Fetch API. 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 является paramount. ProxyOrb раздаёт скрипт перехватчика со своего источника по HTTPS со строгими настройками кэша. Если злоумышленник смог бы внедрить модифицированный Service Worker, он мог бы перехватывать весь трафик затронутых пользователей — не только трафик прокси, но и любые запросы со страниц под этим источником.

7. iframes: проблема frame-ancestors

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/...">, URL этого iframe тоже должен быть переписан в формат прокси, а скрипты перехватчика прокси должны быть внедрены в документ iframe.

Перехватчик iframe работает на двух уровнях:

Уровень 1 — патчинг прототипа (перехватывает программное создание iframes):

-- 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

Уровень 2 — запасной вариант через MutationObserver (перехватывает iframe, вставленные в DOM):

-- 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 — полностью удалять атрибут 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)

Это существенный компромисс безопасности: изолирование было намеренно выставлено исходным сайтом для ограничения возможностей встраиваемого контента. Его удаление расширяет то, что этот контент может делать. Это именно такой вид решения, который невидим конечным пользователям, но материально влияет на постуру безопасности сессии прокси.

8. Последствия для безопасности операторов прокси

Карта поверхности атаки

Когда пользователи просматривают сайты через ProxyOrb, через источник прокси проходит несколько категорий чувствительных данных:

Сессионные куки: поскольку все целевые сайты проксируются через proxyorb.com, куки хранятся под этим источником. Авторизованные сессии пользователя с банком, почтой и социальными сетями — всё это куки под одним доменом. credentials: 'include' в Service Worker означает, что эти куки сопровождают каждый проксируемый запрос.

Заголовки Referer: заголовок Referer, отправляемый на upstream-серверы, раскрывает, какую страницу просматривал пользователь. Прокси тщательно убирает свой домен из значений реферера перед отправкой на целевой сервер. Если запрос исходит с https://proxyorb.com/some/path?__pot=..., исходящий заголовок Referer реконструируется как исходный целевой URL (https://example.com/some/path) — домен прокси никогда не утекает на upstream-серверы.

-- 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 переписываются) и выполняется в источнике прокси. Вредоносный скрипт с evil.example.com, проксируемый через ProxyOrb, работает в источнике proxyorb.com и имеет полный доступ к localStorage, кукам и IndexedDB этого источника — включая данные со всех других целевых сайтов, к которым пользователь обращался через прокси.

Модель угроз вредоносного прокси

В образовательных целях стоит прямо сказать, что вредоносный прокси мог бы делать то, чего ProxyOrb намеренно не делает:

  1. Сбор учётных данных: вредоносный прокси мог бы логировать каждое тело запроса (содержащее пароли и данные форм) при его прохождении через шлюз.

  2. Угон сессий: поскольку все куки целевых сайтов хранятся под доменом прокси, вредоносный оператор прокси мог бы получать доступ к этим кукам на стороне сервера через шлюз.

  3. Инъекция контента: прокси неизбежно модифицирует контент страниц (для внедрения Service Worker и перезаписи URL). Вредоносный прокси мог бы внедрять произвольный JavaScript — кейлоггеры, криптомайнеры, скрипты рекламного мошенничества — невидимые пользователю.

  4. SSL-стриппинг: если прокси понижает HTTPS-соединения до HTTP на участке шлюз-пользователь, весь трафик идёт открытым текстом.

ProxyOrb работает по HTTPS от начала до конца и не логирует тела запросов. Оператор любого веб-прокси обладает этими возможностями, и именно поэтому выбор надёжного оператора прокси так же важен, как выбор надёжного провайдера VPN.

Смешанный контент

Современные браузеры принудительно блокируют смешанный контент: HTTPS-страница не может загружать HTTP-подресурсы. ProxyOrb решает это, принудительно используя HTTPS для всех исходящих соединений от шлюза, даже когда целевой URL использует HTTP. Переопределение CSP включает upgrade-insecure-requests, чтобы инструктировать браузер обновлять все HTTP URL подресурсов до HTTPS перед загрузкой.

Как правило это желательно, но может сломать сайты, намеренно раздающие ресурсы через HTTP (устаревшие CDN, localhost-ресурсы и т.д.).

9. Гонка вооружений продолжается: заключение

Когда мы начинали строить 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 в одноисточниковые, делая кросс-оригинные ограничения SOP нерелевантными, а не обходя их. С точки зрения браузера, весь контент приходит с собственного источника прокси, так что кросс-оригинные границы не пересекаются. Это архитектурно отличается от обхода — SOP по-прежнему применяет свои правила; прокси просто инженерит контент так, чтобы эти правила никогда не срабатывали.

Как CORS влияет на веб-прокси серверы?

CORS влияет на прокси-серверы на двух уровнях. Во-первых, прокси должен перехватывать предварительные OPTIONS-запросы и отвечать разрешающими CORS-заголовками, поскольку ответ реального целевого сервера (ссылающийся на целевой источник) не удовлетворит проверку CORS браузера для источника прокси. Во-вторых, прокси должен удалять CORS-заголовки из ответов целевого сервера и заменять их заголовками, ссылающимися на источник прокси. Настройка Access-Control-Allow-Credentials: true в сочетании с credentials: 'include' в Service Worker означает, что все куки источника прокси сопровождают каждый проксируемый запрос.

Что такое CORB и как он влияет на прокси-сервисы?

Cross-Origin Read Blocking (CORB) — это защита Chromium, предотвращающая попадание определённых чувствительных кросс-оригинных ответов (HTML, JSON, XML) в процесс рендерера при загрузке в качестве кросс-оригинных подресурсов. Для правильно сконфигурированных веб-прокси CORB обычно не срабатывает, потому что перезапись URL делает все запросы одноисточниковыми. Однако CORB может вызывать проблемы в период до полной регистрации Service Worker, когда некоторые запросы могут уйти без перезаписи URL как настоящие кросс-оригинные запросы. CORB был введён как мера против Spectre и определён в спецификации WHATWG Fetch.

Могут ли веб-прокси получить доступ к HttpOnly-кукам?

Нет. Куки с флагом HttpOnly устанавливаются целевым сервером и не могут быть прочитаны JavaScript — включая JavaScript в Service Worker. Однако шлюз получает эти куки при пересылке запросов от имени пользователя, поскольку браузер отправляет их в заголовках запросов. Флаг HttpOnly предотвращает кражу через JavaScript на стороне клиента, но не мешает серверу прокси видеть значения кук в транзите. Это аналогично тому, как HttpOnly защищает от XSS, но не от серверного перехвата.

Безопасно ли использование веб-прокси с точки зрения безопасности браузера?

Зависит от модели угроз. С точки зрения браузера, весь контент через веб-прокси работает в источнике прокси, а значит уязвимость в JavaScript одного проксируемого сайта потенциально может получить доступ к данным сессии другого проксируемого сайта (поскольку они разделяют cookie jar и хранилище одного источника). Оператор прокси также является доверенной стороной с доступом ко всему трафику в транзите. Для доступа к несекретному контенту в ограниченных средах риск, как правило, приемлем. Для авторизованных сессий с чувствительными сервисами (банки, здравоохранение, госорганы) пользователям следует понимать, что оператор прокси технически способен наблюдать этот трафик, и использовать только прокси-сервисы с проверяемой политикой отсутствия логов и надёжной операционной безопасностью.

Эта статья отражает архитектуру ProxyOrb по состоянию на начало 2026 года. Механизмы безопасности браузеров развиваются быстро; читателям рекомендуется следить за стандартом WHATWG Fetch, спецификацией W3C Content Security Policy и документами по дизайну безопасности Chromium для получения актуальной информации.