Indvirkning
En angriber kan stjæle følsomme, autentificerede data fra brugere af en sårbar applikation [S2]. Hvis en bruger besøger et ondsindet websted, mens han er logget ind på den sårbare app, kan det ondsindede websted foretage krydsoprindelsesanmodninger til appens API og læse svarene [S1][S2]. Dette kan føre til tyveri af private oplysninger, herunder brugerprofiler, CSRF-tokens eller private beskeder [S2].
Grundårsag
CORS er en HTTP-header-baseret mekanisme, der gør det muligt for servere at angive, hvilke oprindelser (domæne, skema eller port) der har tilladelse til at indlæse ressourcer [S1]. Sårbarheder opstår typisk, når en servers CORS-politik er for fleksibel eller dårligt implementeret [S2]:
- Reflected Origin Header: Nogle servere læser
Origin-headeren fra en klientanmodning og ekko den tilbage iAccess-Control-Allow-Origin(ACAO)-svarheaderen [S2]. Dette giver effektivt ethvert websted adgang til ressourcen [S2]. - Forkert konfigurerede jokertegn: Mens jokertegnet
*tillader enhver oprindelse at få adgang til en ressource, kan det ikke bruges til anmodninger, der kræver legitimationsoplysninger (som cookies eller autorisationsoverskrifter) [S3]. Udviklere forsøger ofte at omgå dette ved dynamisk at generere ACAO-headeren baseret på anmodningen [S2]. - Whitelisting 'null': Nogle applikationer hvidlister
null-oprindelsen, som kan udløses af omdirigerede anmodninger eller lokale filer, hvilket gør det muligt for ondsindede websteder at udgive sig som ennull-oprindelse for at få adgang ZXCVIXVIBETOKEN2ZVFXCVIZ. - Parsingsfejl: Fejl i regex eller strengmatchning ved validering af
Origin-headeren kan tillade angribere at bruge domæner somtrusted-domain.com.attacker.com[S2].
Det er vigtigt at bemærke, at CORS ikke er en beskyttelse mod Cross-Site Request Forgery (CSRF) [S2].
Konkrete rettelser
- Brug en statisk hvidliste: Undgå dynamisk generering af
Access-Control-Allow-Origin-headeren fra anmodningensOrigin-header [S2]. Sammenlign i stedet anmodningens oprindelse med en hårdkodet liste over betroede domæner [S3]. - Undgå "null"-oprindelsen: Inkluder aldrig
nullpå din hvidliste over tilladte oprindelser [S2]. - Begræns legitimationsoplysninger: Indstil kun
Access-Control-Allow-Credentials: true, hvis det er absolut nødvendigt for den specifikke krydsoprindelsesinteraktion [S3]. - Brug korrekt validering: Hvis du skal understøtte flere oprindelser, skal du sikre dig, at valideringslogikken for
Origin-headeren er robust og ikke kan omgås af underdomæner eller domæner med lignende udseende [S2].
Hvordan FixVibe tester for det
FixVibe inkluderer nu dette som en gated aktiv check. Efter domænebekræftelse sender active.cors API-anmodninger med samme oprindelse med en syntetisk angriberoprindelse og gennemgår CORS-svarheaders. Den rapporterer afspejlet vilkårlig oprindelse, wildcard-legitimationsoplysninger CORS og vidåbne CORS på ikke-offentlige API-endepunkter, mens støj fra offentlige aktiver undgås.
