Влияние
Злоумышленник может украсть конфиденциальные, проверенные данные у пользователей уязвимого приложения [S2]. Если пользователь посещает вредоносный веб-сайт, войдя в уязвимое приложение, вредоносный сайт может отправлять запросы между источниками к API приложения и читать ответы [S1][S2]. Это может привести к краже частной информации, включая профили пользователей, токены CSRF или личные сообщения [S2].
Основная причина
CORS — это механизм на основе HTTP-заголовка, который позволяет серверам указывать, каким источникам (домену, схеме или порту) разрешено загружать ресурсы [S1]. Уязвимости обычно возникают, когда политика сервера CORS слишком гибкая или плохо реализована [S2]:
- Отраженный заголовок источника: Некоторые серверы считывают заголовок
Originиз клиентского запроса и отображают его обратно в заголовке ответаAccess-Control-Allow-Origin(ACAO) [S2]. Это фактически позволяет любому веб-сайту получить доступ к ресурсу [S2]. - Неправильно настроенные подстановочные знаки: Хотя подстановочный знак
*позволяет любому источнику получить доступ к ресурсу, его нельзя использовать для запросов, требующих учетных данных (например, файлов cookie или заголовков авторизации) [S3]. Разработчики часто пытаются обойти это, динамически генерируя заголовок ACAO на основе запроса [S2]. - Внесение в белый список нулевого значения: некоторые приложения вносят в белый список источник
null, что может быть вызвано перенаправленными запросами или локальными файлами, что позволяет вредоносным сайтам маскироваться под источникnullдля получения доступа к [S2][S3]. - Ошибки анализа: Ошибки в регулярном выражении или сопоставлении строк при проверке заголовка
Originмогут позволить злоумышленникам использовать такие домены, какtrusted-domain.com.attacker.com[S2].
Важно отметить, что CORS не является защитой от подделки межсайтовых запросов (CSRF) [S2].
Конкретные исправления
- Используйте статический белый список. Избегайте динамического создания заголовка
Access-Control-Allow-Originиз заголовкаOriginзапроса [S2]. Вместо этого сравните источник запроса с жестко закодированным списком доверенных доменов [S3]. - Избегайте нулевого источника происхождения: Никогда не включайте
nullв белый список разрешенных источников [S2]. - Ограничить учетные данные: Устанавливайте
Access-Control-Allow-Credentials: trueтолько в том случае, если это абсолютно необходимо для конкретного взаимодействия между источниками [S3]. - Используйте правильную проверку. Если вам необходимо поддерживать несколько источников, убедитесь, что логика проверки для заголовка
Originнадежна и не может быть обойдена поддоменами или похожими доменами [S2].
Как FixVibe проверяет это
FixVibe теперь включает это как закрытую активную проверку. После проверки домена active.cors отправляет запросы API того же происхождения с искусственным источником злоумышленника и проверяет заголовки ответов CORS. В отчетах отражены произвольные источники, учетные данные с подстановочными знаками CORS и широко открытый CORS на закрытых конечных точках API, избегая при этом шума общедоступных активов.
