FixVibe
Covered by FixVibehigh

CORS Няправільная канфігурацыя: рызыкі празмерна дазвольнай палітыкі

Сумеснае выкарыстанне рэсурсаў (CORS) - гэта механізм браўзера, прызначаны для змякчэння Палітыкі аднолькавага паходжання (SOP). Нягледзячы на ​​тое, што гэта неабходна для сучасных вэб-праграм, няправільная рэалізацыя — напрыклад, паўтарэнне загалоўка Origin запытальніка або ўнясенне ў белы спіс «нулявога» паходжання — можа дазволіць шкоднасным сайтам выкрасці прыватныя даныя карыстальнікаў.

CWE-942

Уплыў

Зламыснік можа скрасці канфідэнцыяльныя, аўтэнтыфікаваныя даныя ў карыстальнікаў уразлівага прыкладання [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, пазбягаючы шуму публічных актываў.