Влијание
Напаѓачот може да украде чувствителни, автентификувани податоци од корисници на ранлива апликација [S2]. Ако корисникот посети злонамерна веб-локација додека е најавен во ранливата апликација, злонамерната локација може да поднесе барања за вкрстено потекло до API на апликацијата и да ги чита одговорите [S1][S2]. Ова може да доведе до кражба на приватни информации, вклучувајќи кориснички профили, CSRF токени или приватни пораки [S2].
Основна причина
CORS е механизам базиран на HTTP-заглавија кој им овозможува на серверите да одредат кое потекло (домен, шема или порта) им е дозволено да ги вчитаат ресурсите [S1]. Ранливостите обично се појавуваат кога политиката CORS на серверот е премногу флексибилна или слабо имплементирана [S2]:
- Заглавие со рефлектирано потекло: Некои сервери го читаат заглавието
Originод барање на клиентот и го повторуваат назад во заглавието за одговорAccess-Control-Allow-Origin(ACAO) [S2]. Ова ефикасно им овозможува на секоја веб-локација да пристапи до ресурсот [S2]. - Погрешно конфигурирани џокери: додека џокерот
*дозволува секое потекло да пристапи до ресурс, не може да се користи за барања за кои се потребни ингеренции (како колачиња или заглавија за авторизација) [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, притоа избегнувајќи бучава од јавниот имот.
