CORS i taket
När vi tänker webbapplikationstester så förs tankarna ofta till OWASP Top 10 och dess kategorier av tester. Men vad vi ofta går miste om är de många andra kategorier av sårbarheter som existerar för webbapplikationer. I detta blogginlägg tänkte jag diskutera en mindre diskuterad sårbarhet som kan ha stora konsekvenser.
CORS står för Cross-Origin Resource Sharing och som namnet antyder så är det en policy för webbapplikationer som beskriver vilka andra hemsidor eller servrar som webbapplikationen får dela med sig information till. Stöter vi på en webbapplikation med en felkonfigurerad CORS-policy så kan vi vissa fall utnyttja detta för att extrahera känslig information tillhörande en användare. Denna typ av attack går under namnet Cross-origin Resource Scrutiny eller i vissa fall bara CORS-attack.
Attacken är i teorin simpel att exekvera men kan i praktiken ofta vara strulig och kräver en viss kunskap om hur webbapplikationen är uppbyggd.
Nedan följer en beskrivning på hur sårbarheten kan identifieras och därefter utnyttjas.
Steg 1: Identifiera en felkonfigurerad CORS-policy
När vi skickar en förfrågan mot en webbapplikation så skickas en ”Origin”-flagga med. Denna flagga talar om för webbapplikationen vart förfrågan skickats från. Vi kan kontrollera att webbapplikationen accepterar svar från valfri server och att svaret kan skickas med behörigheter genom att manipulera en förfrågan med en transparent proxy. Exempelvis Burp Suite.
I ovanstående bild så har ”Origin”-flaggan modifierats från corstest.se till https://simovits.com.
Vi observerar nu svaret från servern och ser att den svarar med Access-Control-Allow-Origin: https://simovits.com och Access-Control-Allow-Credentials: true. Detta visar att servern accepterar svar från vår sida samt att den ger ett OK på att skicka förfrågningar med behörigheter i form av en sessionstoken. Vi är nu rätt så säkra på att vi har hittat en sårbarhet i CORS-protokollet för webbapplikationen.
Steg 2: Konstruera vår phishing-sida
För att kunna utnyttja sårbarheten så måste vi först konstruera en phishing-sida dit vi kan lura in vårt offer. Medan attacken går väldigt fort och enbart kräver att offret laddar hemsidan så dekorerar vi vårt exempel med en vacker bild så att offret i ska ana odåd.
Nu måste vi bara lura in offret medan denna har en aktiv inloggad session på den sårbara webbapplikationen.
Medan offret beundrar bilden så exekverar ett underläggande skript som hämtar den resurs vi är ute efter och levererar den till oss utan användarens vetskap.
För källkoden till skriptet så hänvisas läsaren till Geekboy:s artikel. En länk finns i slutet av blogginlägget.
Steg 3: Observera
Om allting gått som det ska så har vi nu i våra webbserverloggar ett svar som innehåller detaljer från den resurs tillhörande användaren som vi efterfrågat.
Slutsats
Medan det exempel som togs upp ovan visar på en rätt så simpel kedja för att identifiera och utnyttja en CORS-sårbarhet så är det i praktiken ofta inte lika lätt. Vissa webbläsare har inbyggt skydd mot CORS-attacker (Exempelvis Firefox). Andra gånger så kan pekaren mot de resurser vi är ute efter att vara så pass komplex att vi inte kan gissa oss fram till den. Exempelvis då ett 32-tecken långt slumpmässigt ID används för att hämta resursen.
För mer detaljer kring CORS-sårbarheter rekommenderar jag OWASP:s sida om CORS https://www.owasp.org/index.php/CORS_OriginHeaderScrutiny och Geekboys mer ingående artikel på hur en CORS-attack går tillväga https://www.geekboy.ninja/blog/exploiting-misconfigured-cors-cross-origin-resource-sharing/