Данный проект реализует избирательный корпоративный доступ к прокси-серверу на основе членства в доменной группе Active Directory:

1. Active Directory & GPO как шлюз авторизации:
   • Доставка расширения и распространение токена extToken осуществляются исключительно через Group Policy с использованием Security Filtering на группу SEC-Proxy-VPN.
   • Пользователи, не входящие в группу, не получают расширение и ключ доступа.
2. Аутентификация management-API (двухтокенная модель):
   • Fleet-токен EXT_SHARED_TOKEN (заголовок X-Ext-Token) — низкопривилегированный: аутентифицирует расширения на /creds и /api/sync и намеренно зашивается в публичные артефакты (CRX, GPO .reg). Компрометация fleet-токена НЕ даёт доступа к админке.
   • Админ-токен ADMIN_TOKEN (заголовок X-Admin-Token) открывает все management-API (/api/builder/*, /api/routing/*, /api/rotation/*, /api/instances/*, /api/config, /api/status), не покидает сервер и никогда не попадает в артефакты. Обязателен при NODE_ENV=production; должен отличаться от fleet-токена.
   • Строгая изоляция: fleet-токен на админ-роутах → 401; admin-токен на fleet-роутах → 403.
   • Публичными остаются только /healthz, /proxy.pac, /updates/* (для автообновлений Chrome через GPO), /api/ip-echo и /api/sync (последний проверяет fleet-токен внутри роутера со своим rate limiter'ом). Скачивание ZIP-архива расширения (/api/extension/download-zip) требует аутентификации администратора (сессионная кука + CSRF или X-Admin-Token) и ограничено rate limiter'ом (10 запросов в минуту).
   • Веб-панель не передает токен в браузер: аутентификация по логину и паролю (scrypt-хеш на сервере) с сессионной cookie (HttpOnly, SameSite=Strict).
3. Защита от Timing Attacks:
   • Токен сравнивается по SHA-256-дайджестам через crypto.timingSafeEqual (без утечки длины).
4. Защита от сниффинга пароля в локальной сети:
   • Рекомендуется использовать директиву HTTPS xray-host:10809 в PAC-файле (Secure Web Proxy). В этом случае соединение между браузером и прокси шифруется TLS, что исключает перехват заголовка Proxy-Authorization: Basic ... в локальной корпоративной сети.
5. Защита от DNS-утечек:
   • В PAC-скриптах следует использовать строковые проверки доменов (dnsDomainIs, shExpMatch) без обращения к dnsResolve, чтобы исключить преждевременные запросы к локальному корпоративному DNS.
6. Ротация учетных данных:
   • Пароль прокси-инбаунда ротируется через API 3x-ui криптографически стойким генератором (crypto.randomBytes).
   • При недоступности панели креды не меняются (защита от рассинхрона флота); standalone-режим — только осознанно, без настроенной панели.
   • Запись файла учетных данных на сервере производится атомарно с правами доступа 0600.
7. Подпись пакетов расширения:
   • .crx подписывается в формате CRX3 (RSA-SHA256, protobuf), совместимом с Chrome 70+.
   • Приватный ключ хранится в extension/key.pem (gitignored, режим 0600); при деплое в Docker сохраняйте том pec_extension, чтобы ID расширения оставался стабильным.
8. Публичный PAC-эндпоинт (принятый риск):
   • GET /proxy.pac и /updates/* не аутентифицируются: браузеры запрашивают PAC-скрипт и CRX-обновления без HTTP-заголовков, авторизация на этом пути технически невозможна.
   • Следствие: любой, у кого есть сетевой доступ к серверу, может прочитать хост/порт прокси и политику маршрутизации (домены разделения).
   • Митигация: сетевая сегментация — сервер PAC-раздачи должен быть доступен только из корпоративных сегментов (firewall / security groups). Для nginx в deploy/nginx-proxy.conf есть закомментированный пример allow/deny для location /proxy.pac и location /updates/.
   • Учетные данные прокси этот эндпоинт не раскрывает: они выдаются только на /creds по fleet-токену.
9. Семантика CIDR-правил PAC (осознанное изменение):
   • isInNet(host, ...) с DNS-именем заставляла браузер делать синхронный DNS-резолв на каждый запрос — при медленном корпоративном DNS это фризило UI пользователей.
   • Теперь CIDR-правила применяются только к host, являющемуся IP-литералом (/^\d{1,3}(\.\d{1,3}){3}$/). Хосты, резолвящиеся в RFC1918, покрываются доменными правилами (*.corp.local и т.п.); URL с literal-IP продолжают матчиться.

Если вы обнаружили уязвимость в безопасности проекта:

1. Не создавайте публичные Issue в GitHub.
2. Направьте подробное описание уязвимости ответственным администраторам информационной безопасности компании.
3. Сообщение должно содержать шаги для воспроизведения и оценку потенциального воздействия.