Основы веб-безопасности: разбираем SSRF, CSRF и CORS

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

Сегодня мы погрузимся в три критически важных понятия, которые должен знать каждый веб-разработчик: SSRF, CSRF и CORS. Хотя они могут звучать как «алфавитный суп», они представляют собой передовую линию защиты веб-приложений.

1. SSRF (Подделка запроса со стороны сервера)

SSRF — это уязвимость, при которой злоумышленник может заставить серверное приложение отправлять HTTP-запросы на произвольный домен по выбору злоумышленника.

Как это работает

Представьте себе веб-приложение, которое принимает URL-адрес в качестве входных данных (например, для получения фотографии профиля или предварительного просмотра ссылки), а затем выполняет запрос к этому URL-адресу с сервера. Если приложение не проверяет этот URL должным образом, злоумышленник может указать внутренний IP-адрес или адрес обратной связи (127.0.0.1).

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

• Метаданные облака: доступ к 169.254.169.254 на AWS/GCP для получения учетных данных IAM.
• Внутренние панели администратора: доступ к внутренним инструментам, таким как Jenkins или панели управления Kubernetes.
• Сканирование портов: обнаружение других служб, работающих во внутренней сети.

Предотвращение

• Белые списки (Allowlisting): разрешайте запросы только к заранее определенному списку доверенных доменов.
• Валидация входных данных: убедитесь, что URL использует разрешенные протоколы (например, только https://) и не указывает на внутренние диапазоны IP-адресов.
• Сетевая сегментация: убедитесь, что веб-сервер имеет ограниченный доступ к внутренним ресурсам.

2. CSRF (Межсайтовая подделка запроса)

CSRF — это атака, которая обманом заставляет браузер жертвы выполнить нежелательное действие на другом веб-сайте, где жертва в данный момент аутентифицирована.

Как это работает

Эта атака использует тот факт, что браузеры автоматически включают учетные данные — например, сессионные куки — в каждый запрос к домену.

1. Пользователь входит в bank.com.
2. Пользователь посещает вредоносный сайт evil.com в другой вкладке.
3. evil.com содержит скрытую форму, которая отправляет POST-запрос на bank.com/transfer?amount=1000&to=attacker.
4. Браузер отправляет запрос вместе с сессионной кукой пользователя для bank.com.
5. bank.com видит действительную сессию и обрабатывает перевод.

Предотвращение

• Anti-CSRF токены: включайте уникальный, секретный и непредсказуемый токен в каждый запрос, изменяющий состояние. Сервер проверяет этот токен перед обработкой.
• SameSite куки: установите атрибут SameSite для кук в значение Strict или Lax, чтобы предотвратить их отправку при межсайтовых запросах.
• Пользовательские заголовки: для AJAX-запросов требуйте пользовательский заголовок (например, X-Requested-With), который не может быть установлен стандартной HTML-формой.

3. CORS (Совместное использование ресурсов из разных источников)

В отличие от SSRF и CSRF, CORS сам по себе не является уязвимостью, а является механизмом безопасности. Это способ для серверов сообщить браузеру: «Это нормально, что этот конкретный внешний источник обращается к моим ресурсам».

Почему он существует

По умолчанию браузеры применяют Политику одного источника (SOP), которая запрещает скрипту на одном сайте читать данные с другого сайта. Это не позволяет evil.com читать ваши электронные письма на gmail.com.

CORS позволяет серверам безопасно смягчать эту политику. Когда веб-приложение делает кросс-доменный запрос, браузер отправляет заголовок Origin. Сервер отвечает заголовком Access-Control-Allow-Origin.

Распространенные ошибки конфигурации

• Универсальный источник (*): разрешение всех источников. Хотя это допустимо для публичных API, это опасно, если сочетается с Access-Control-Allow-Credentials: true.
• Отражение источника: динамическая установка разрешенного источника на основе заголовка Origin без валидации. Это фактически полностью обходит SOP.

Лучшие практики

• Будьте конкретны: разрешайте только те домены, которым действительно нужен доступ.
• Избегайте передачи учетных данных, если это возможно: если вашему API не нужны куки или заголовки Authorization, не разрешайте их.
• Используйте промежуточное ПО для безопасности: используйте проверенные библиотеки для настройки CORS вместо ручного управления заголовками.

Сводное сравнение

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

Оставайтесь в безопасности и удачного программирования!