Въздействие
Нападателят може да открадне чувствителни, удостоверени данни от потребители на уязвимо приложение [S2]. Ако потребител посети злонамерен уебсайт, докато е влязъл в уязвимото приложение, злонамереният сайт може да направи кръстосани заявки към API на приложението и да прочете отговорите [S1][S2]. Това може да доведе до кражба на лична информация, включително потребителски профили, CSRF токени или лични съобщения [S2].
Първопричина
CORS е базиран на HTTP-заглавие механизъм, който позволява на сървърите да определят кои източници (домейн, схема или порт) имат право да зареждат ресурси [S1]. Уязвимости обикновено възникват, когато CORS политиката на сървъра е твърде гъвкава или лошо внедрена [S2]:
- Отразена заглавка на произхода: Някои сървъри четат заглавката
Originот клиентска заявка и я отразяват обратно в заглавката на отговораAccess-Control-Allow-Origin(ACAO) [S2]. Това ефективно позволява на всеки уебсайт да има достъп до ресурса [S2]. - Неправилно конфигурирани заместващи символи: Въпреки че заместващият знак
*позволява на всеки източник достъп до ресурс, той не може да се използва за заявки, които изискват идентификационни данни (като бисквитки или заглавки за оторизация) [S3]. Разработчиците често се опитват да заобиколят това чрез динамично генериране на ACAO заглавката въз основа на заявката [S2]. - Бели списъци 'null': Някои приложения поставят в белия списък източника на
null, който може да бъде задействан от пренасочени заявки или локални файлове, което позволява на злонамерените сайтове да се маскират като източник наnull, за да получат достъп [S2][S3]. - Грешки при анализиране: Грешки в съвпадението на regex или низ при валидиране на заглавката
Originмогат да позволят на атакуващите да използват домейни катоtrusted-domain.com.attacker.com[S2].
Важно е да се отбележи, че CORS не е защита срещу Cross-Site Request Forgery (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 крайни точки, като същевременно избягва шума от публичните активи.
