FindRiskbeta — тестовый запуск

Практическое руководство FindRisk

Безопасность reverse proxy: HTTP-запросы, Host и общий кэш

Каждый посредник может менять протокол, заголовки и правила кэша. Поэтому исправность отдельного Nginx или приложения не подтверждает безопасность всей цепочки. Начните с схемы пути запроса и явно определите границы доверия.

Что сделать

  1. 1Зафиксируйте все посредники, версии компонентов и преобразования HTTP-протоколов.
  2. 2Настройте отклонение неоднозначных запросов и согласуйте framing на каждом узле.
  3. 3Ограничьте допустимые Host и доверенные proxy; перезаписывайте входящие forwarded-заголовки.
  4. 4Проверьте, что приложение самостоятельно контролирует права, а приватные ответы не попадают в общий кэш.
  5. 5Используйте безопасный API для заголовков и проверьте итоговые ответы после посредников.
  6. 6Добавьте проверки разрешённого трафика и отказов в изолированном контуре до изменения production.

Материалы по теме

CRLF Injection: внедрение заголовков и HTTP Response Splitting

Как переводы строк в недоверенных значениях нарушают структуру HTTP-заголовков и почему нужно использовать безопасный API ответа.

СреднийВеб-рискНужна ручная проверкаВеб-приложения

Web Cache Deception и Poisoning: защита ответов в CDN и proxy

Чем утечка приватного ответа через кэш отличается от подмены общего ответа и как согласовать cache key, маршрутизацию и политику хранения.

ВысокийВеб-рискНужна ручная проверкаВеб-приложения
Весь каталог

Источники и границы

  • Нельзя проверять рассогласование запросов на общих production-соединениях пользователей.
  • Заголовки одного ответа не раскрывают настройки всех посредников и cache key.