FixVibe
Covered by FixVibehigh

CORS Felkonfiguration: risker för alltför tillåtande policyer

Cross-Origin Resource Sharing (CORS) är en webbläsarmekanism utformad för att slappna av Same-Origin Policy (SOP). Även om det är nödvändigt för moderna webbappar, kan felaktig implementering – som att återskapa begärandens ursprungshuvud eller vitlista med "null"-ursprunget – tillåta skadliga webbplatser att exfiltrera privat användardata.

CWE-942

Inverkan

En angripare kan stjäla känslig, autentiserad data från användare av en sårbar applikation [S2]. Om en användare besöker en skadlig webbplats medan den är inloggad på den sårbara appen, kan den skadliga webbplatsen göra förfrågningar om kors ursprung till appens API och läsa svaren [S1][S2]. Detta kan leda till stöld av privat information, inklusive användarprofiler, CSRF-tokens eller privata meddelanden [S2].

Rotorsak

CORS är en HTTP-headerbaserad mekanism som tillåter servrar att specificera vilka ursprung (domän, schema eller port) som tillåts ladda resurser [S1]. Sårbarheter uppstår vanligtvis när en servers CORS-policy är för flexibel eller dåligt implementerad [S2]:

  • Reflected Origin Header: Vissa servrar läser Origin-huvudet från en klientförfrågan och ekar det tillbaka i Access-Control-Allow-Origin (ACAO) svarshuvudet [S2]. Detta tillåter effektivt vilken webbplats som helst att komma åt resursen [S2].
  • Felkonfigurerade jokertecken: Även om jokertecken * tillåter vilket ursprung som helst att komma åt en resurs, kan det inte användas för förfrågningar som kräver autentiseringsuppgifter (som cookies eller auktoriseringsrubriker) [S3]. Utvecklare försöker ofta kringgå detta genom att dynamiskt generera ACAO-huvudet baserat på begäran [S2].
  • Vitlistning "null": Vissa applikationer vitlistar null-ursprunget, vilket kan utlösas av omdirigerade förfrågningar eller lokala filer, vilket gör att skadliga webbplatser kan maskera sig som ett null-ursprung för att få åtkomst ZXCVIXVIBETOKEN2ZVFXCVIX.
  • Parsingsfel: Fel i regex eller strängmatchning vid validering av Origin-huvudet kan tillåta angripare att använda domäner som trusted-domain.com.attacker.com [S2].

Det är viktigt att notera att CORS inte är ett skydd mot Cross-Site Request Forgery (CSRF) [S2].

Betongfixar

  • Använd en statisk vitlista: Undvik att dynamiskt generera Access-Control-Allow-Origin-huvudet från begärans Origin-huvud [S2]. Jämför istället begärans ursprung med en hårdkodad lista över betrodda domäner [S3].
  • Undvik "null" ursprung: Inkludera aldrig null i din vitlista över tillåtna ursprung [S2].
  • Begränsa autentiseringsuppgifter: Ställ bara in Access-Control-Allow-Credentials: true om det är absolut nödvändigt för den specifika korsoriginella interaktionen [S3].
  • Använd korrekt validering: Om du måste stödja flera ursprung, se till att valideringslogiken för Origin-huvudet är robust och inte kan kringgås av underdomäner eller liknande utseende domäner [S2].

Hur FixVibe testar det

FixVibe inkluderar nu detta som en gated aktiv kontroll. Efter domänverifiering skickar active.cors API-förfrågningar med samma ursprung med ett syntetiskt angriparursprung och granskar CORS-svarsrubriker. Den rapporterar reflekterade godtyckliga ursprung, CORS med jokertecken och vidöppna CORS på icke-offentliga API-slutpunkter samtidigt som man undviker buller från offentliga tillgångar.