Hatás
A támadók bizalmas, hitelesített adatokat lophatnak el egy sebezhető [S2] alkalmazás felhasználóitól. Ha egy felhasználó meglátogat egy rosszindulatú webhelyet, miközben be van jelentkezve a sérülékeny alkalmazásba, a rosszindulatú webhely több eredetű kérelmet küldhet az alkalmazás API címére, és elolvashatja a [S1][S2] válaszokat. Ez személyes adatok ellopásához vezethet, beleértve a felhasználói profilokat, CSRF-tokeneket vagy privát üzeneteket. [S2].
Kiváltó ok
A CORS egy HTTP-fejléc alapú mechanizmus, amely lehetővé teszi a kiszolgálók számára, hogy meghatározzák, hogy mely források (tartomány, séma vagy port) tölthetik be az erőforrásokat [S1]. A sérülékenységek általában akkor keletkeznek, ha a kiszolgáló CORS házirendje túl rugalmas, vagy rosszul van megvalósítva: [S2]:
- Reflected Origin Header: Egyes szerverek beolvassák a
Originfejlécet az ügyfél kéréséből, és visszaadják azt aAccess-Control-Allow-Origin(ACAO) válaszfejlécben [S2]. Ezzel gyakorlatilag bármely webhely hozzáférhet a [S2] erőforráshoz. - Hibásan konfigurált helyettesítő karakterek: Bár a
*helyettesítő karakter lehetővé teszi bármely forrás hozzáférését az erőforrásokhoz, nem használható olyan kérésekhez, amelyekhez hitelesítési adatok (például cookie-k vagy engedélyezési fejlécek) szükségesek. [S3]. A fejlesztők ezt gyakran úgy próbálják megkerülni, hogy dinamikusan generálják az ACAO fejlécet a [S2] kérés alapján. - Null engedélyezési lista: Egyes alkalmazások engedélyezőlistára teszik a
nulleredetet, amelyet átirányított kérések vagy helyi fájlok válthatnak ki, lehetővé téve a rosszindulatú webhelyek számára, hogynulleredetnek álcázzák magukat. [S2][S3]. - Elemzési hibák: A
Originfejléc érvényesítése során előforduló hibák a reguláris kifejezésben vagy a karakterlánc-egyeztetésben lehetővé tehetik a támadók számára, hogy olyan tartományokat használjanak, mint atrusted-domain.com.attacker.com[S2].
Fontos megjegyezni, hogy a CORS nem jelent védelmet a Cross-Site Request Forgery (CSRF) [S2] ellen.
Konkrét javítások
- Használjon statikus engedélyezőlistát: Kerülje a
Access-Control-Allow-Originfejléc dinamikus generálását a kérelemOrigin[S2] fejlécéből. Ehelyett hasonlítsa össze a kérés eredetét a megbízható tartományok kódolt listájával ([S3]). - Kerülje a „null” eredetet: Soha ne vegye fel a
nullelemet az engedélyezett eredet [S2] engedélyezési listájára. - Hitelesítési adatok korlátozása: Csak akkor állítsa be a
Access-Control-Allow-Credentials: trueértéket, ha feltétlenül szükséges a [S3] konkrét, több eredetű interakcióhoz. - Használjon megfelelő érvényesítést: Ha több forrást kell támogatnia, győződjön meg arról, hogy a
Originfejléc érvényesítési logikája robusztus, és nem kerülheti meg aldomainekkel vagy hasonló megjelenésű tartományokkal ([S2]).
Hogyan teszteli a FixVibe
A FixVibe ezt most kapuzott aktív ellenőrzésként tartalmazza. A tartomány ellenőrzése után a active.cors azonos eredetű API kéréseket küld szintetikus támadói eredettel, és felülvizsgálja a CORS válaszfejlécet. Tetszőleges eredetet, helyettesítő karakteres hitelesítésű CORS és széles körű CORS jelentéseket jelent a nem nyilvános API végpontokon, miközben elkerüli a nyilvános eszközök zaját.
