Vaikutus
Hyökkääjä voi varastaa arkaluonteisia, todennettuja tietoja haavoittuvan sovelluksen [S2] käyttäjiltä. Jos käyttäjä vierailee haitallisella verkkosivustolla ollessaan kirjautuneena haavoittuvaan sovellukseen, haitallinen sivusto voi tehdä sovelluksen API-alkuperäisiä pyyntöjä ja lukea vastaukset [S1][S2]. Tämä voi johtaa henkilökohtaisten tietojen, mukaan lukien käyttäjäprofiilien, CSRF-tunnuksien tai yksityisviestien, varastamiseen [S2].
Perussyy
CORS on HTTP-otsikkopohjainen mekanismi, jonka avulla palvelimet voivat määrittää, mitkä alkuperät (verkkoalue, malli tai portti) saavat ladata resursseja [S1]. Haavoittuvuuksia syntyy yleensä, kun palvelimen CORS-käytäntö on liian joustava tai huonosti toteutettu [S2]:
- Reflected Origin Header: Jotkut palvelimet lukevat
Origin-otsikon asiakaspyynnöstä ja toistavat sen takaisinAccess-Control-Allow-Origin(ACAO) -vastausotsikossa [S2]. Tämä mahdollistaa tehokkaasti minkä tahansa verkkosivuston pääsyn resurssiin [S2]. - Väärin määritetyt jokerimerkit: Vaikka jokerimerkki
*sallii minkä tahansa alkuperän päästä käsiksi resurssiin, sitä ei voi käyttää pyyntöihin, jotka vaativat kirjautumistiedot (kuten evästeet tai valtuutusotsikot). [S3]. Kehittäjät yrittävät usein ohittaa tämän luomalla dynaamisesti ACAO-otsikon pyynnön [S2] perusteella. - Nulla sallittujen luetteloon: Jotkut sovellukset lisäävät sallittujen luetteloon
null-alkuperän, joka voidaan käynnistää uudelleenohjatuilla pyynnöillä tai paikallisilla tiedostoilla, jolloin haitalliset sivustot voivat naamioituanull-alkuperäksi. [S2][S3]. - Jäsennysvirheet: Virheet säännöllisissä lausekkeissa tai merkkijonojen vastaavuudessa
Origin-otsikon vahvistamisen yhteydessä voivat antaa hyökkääjille mahdollisuuden käyttää verkkotunnuksia, kutentrusted-domain.com.attacker.com[S2].
On tärkeää huomata, että CORS ei ole suoja sivustojen välistä pyyntöväärennöstä (CSRF) [S2] vastaan.
Betonikorjauksia
- Käytä staattista sallittua luetteloa: Vältä
Access-Control-Allow-Origin-otsikon dynaamista luomista pyynnönOrigin-otsikosta [S2]. Vertaa sen sijaan pyynnön alkuperää kovakoodattuihin luotettujen verkkotunnusten luetteloon [S3]. - Vältä "nolla-alkuperää": Älä koskaan sisällytä
nullsallittujen alkulähteiden luetteloon [S2]. - Rajoita valtuustietoja: Aseta vain
Access-Control-Allow-Credentials: true, jos se on ehdottoman välttämätöntä tietylle eri lähteiden väliselle vuorovaikutukselle [S3]. - Käytä asianmukaista vahvistusta: Jos sinun on tuettava useita lähtökohtia, varmista, että
Origin-otsikon vahvistuslogiikka on vankka eikä sitä voi ohittaa aliverkkotunnuksilla tai samannäköisillä verkkotunnuksilla [S2].
Kuinka FixVibe testaa sitä
FixVibe sisältää nyt tämän portitetun aktiivisena tarkistuksena. Verkkotunnuksen vahvistamisen jälkeen active.cors lähettää samaa alkuperää olevia API-pyyntöjä, joissa on synteettinen hyökkääjän alkuperä, ja tarkistaa CORS-vastausotsikot. Se raportoi mielivaltaisista lähteistä, jokerimerkillä varustetuista CORS-tunnisteista ja laajasti avoinna olevista CORS-päätepisteistä ei-julkisissa API-päätepisteissä välttäen samalla julkisen omaisuuden kohinaa.
