DOM-XSS genomgång av Sveriges bästa sajter

Då och då kommer det verktyg som underlättar säkerhetsarbetet genom att göra säkerhetsanalys enkel och tillgänglig för många användare.

DOMinator är ett sådant verktyg och det höll Stefano Di Paola ett föredrag om på ett av OWASP Göteborgs seminarium.

DOMinator är ett program som automatiskt identifierar DOM-XSS-sårbarheter i webbapplikationer. Programmet är ett plugin till firebug i firefox och finns att ladda ner här http://code.google.com/p/dominator/downloads/list

Stefano gick genom hur han har byggt sitt program och hur man använder det. Han berättade att han behövde identifiera Sources och Sinks, där Sources är möjliga vägar att skicka in data till en applikation, exempelvis via adressfältet, cookie eller referrer. Sinks är det område i programkoden där en viss sårbarhet kan utnyttjas baserat på användarinmatad data, exempelvis kod som eval(), window.location.

Läs mer om sinks och sources på dessa länkar.
http://code.google.com/p/domxsswiki/wiki/Sinks
http://code.google.com/p/domxsswiki/wiki/Sources

Läs mer om hur DOMinator är uppbyggt i nedanstående PDF
http://dominator.googlecode.com/files/DOMinator_Control_Flow.pdf

IDG Topp 100

Samtidigt som jag provade DOMinator släppte internetworld sin årliga topplista med de 100 bästa sajterna i Sverige. Hela listan hittar du på IDG:s sajt http://internetworld.idg.se/topp100

Eftersom de är Sveriges bästa sajter så handlar det i stor utsträckning om framgångsrika och välbesökta sajter. Miriam Olsson Jeffery beskriver sajterna som är med på detta sätt

“Alla sajter på Internetworlds Topp100-lista är vinnare. De har valts ut bland hundratals andra och visar vägen för den svenska webbens utveckling. Det låter klyschigt, men så är det.”
http://internetworld.idg.se/2.1006/1.413218

Det väckte min nyfikenhet
Hur många av sajterna på IDGs topp 100-lista är sårbara för DOM-XSS?
Stefano hade testat de största sajterna på alexa. Resultatet från Stefanos undersökning hittar du här http://blog.mindedsecurity.com/2011/05/dominator-project.html

Om de visar vägen för svenska webbens utveckling så kanske det kan ge en fingervisning om hur framtiden för andra publika sajter ser ut, inom webbapplikationssäkerhet.

DOM-XSS

Innan jag fortsätter berätta om min analys av sajterna vill jag beskriva hur en DOM-XSS attack kan gå till.

XSS (Cross Site Scripting) finns i fler former, persistent XSS och ickepersistent XSS. Persistent XSS handlar om att säkerhetsproblemet är lagrat på servern, exempelvis i en databas. Om vi tänker oss ett blogginlägg så körs XSS-attacken varje gång någon visar det aktuella blogginlägget. Ickepersistent XSS handlar om sådant som inte lagras på servern men där servern tar emot det inmatade värdet och skriver ut det igen på sidan utan att det hanteras och därmed öppnar för attacker, ofta genom querystrings.

DOM-XSS, eller DOMbaserad XSS handlar om värden som javascript läser och använder igen på sidan, utan att servern nödvändigtvis behöver vara inblandad. Detta gör att det är väldigt svårt för systemadministratörer att upptäcka attacker mot sajten eftersom attacken kan göras utan att någon data som verkar farlig skickas till servern. Det gör att de säkerhetsverktyg (brandväggar, IDS och IPS) man möjligen har för att stoppa attacker blir verkningslösa.

Som exempel kan vi ta en sida med ett sökformulär. Sökningen sker via ajax, men för att kunna bokmärka eller skicka en sida med sökresultat till vänner så används hash-delen i url:en för att veta vilket sökresultat som skall hämtas. Föreställ dig att en sajt har följande url:
http://www.domain.com/search.aspx#search

Sedan lite kod för att skriva ut det man sökte på
<script>
document.write("Du sökte på "+document.location.hash);
</script>

Skickar vi då istället in
http://www.domain.com/search.aspx#<script>alert(/dom-xss/)</script>
så kommer en alertruta att visas i webbläsaren.

Det som skickas till servern är dock endast http://www.domain.com/search.aspx och alltså inte det som står efter hash-tecknet.

Analys

Jag utgick från IDGs topplista och bestämde mig för att utföra några enkla test på varje sajt. Jag analyserade ungefär 2-3 sidor per sajt. Detta kan givetvis innebära att fler sajter än vad jag hittade har säkerhetsproblem, eftersom säkerhetsproblem kan finnas på de sidor som jag inte analyserade. När jag hittat minst ett säkerhetsproblem gick jag vidare till nästa sajt. Många gånger fanns det flera säkerhetsproblem, men jag valde att koncentrera mig på DOM-XSS.

DOMinator har två sätt att varna. Dels genom alerts och dels genom warnings. I min analys har jag inte hittat någon sajt där DOMinator varnat med en alert som har varit en falsk positiv. Det är fullt möjligt att varningar på warnings-nivån också går att utnyttja, men jag har valt att endast fokusera på de sajter med alerts. För att säkerställa att DOMinator inte varnade falskt valde jag att manuellt validera 20 % av de sajter som var sårbara enligt DOMinator.

Den manuella valideringen underlättades av att DOMinator pekade på var i koden problemet var. Som exempel kan jag ta upp en sajt som hade en sårbarhet via källan location, mer specifikt querystring och att detta sedan skrevs ut på sidan.

När jag provade att escape:a strängen med enkel- och dubbelfnuttar så lyckades det inte.
Det visade sig att sajten hade en replace på dubbelfnuttar, men att den inte var global.
Såhär såg varningen i DOMinator ut

134 9:5:43.855 :[ http://www.domain.com/?#parameter=a%22 ]
Target: [ replace(",\")No global CallCount: 1 ]
Data:
a"

Om jag skrev två dubbelfnuttar så kunde hålet utnyttjas, exempelvis

http://www.domain.com/?#parameter=a""%2balert(1)%2b"

Det är inte alla webbläsare som tillåter användning av icke-enkodade specialtecken. På nedanstående länk finns en genomgång av webbläsare och vilka tecken som tillåts för exempelvis location-källan. Där kan man läsa att IE är den enda webbläsaren som tillåter icke-enkodade dubbelfnuttar för querystrings i searchdelen av en url. Om man däremot anger querystrings i hash-delen av url:en så är det tillåtet av både IE, Chrome och Opera. I mitt exempel angav jag parametern i hash-delen och därför kunde hålet utnyttjas via tre stora webbläsare.
http://code.google.com/p/domxsswiki/wiki/LocationSources

Sammanfattning av analys

När jag hade analyserat samtliga 100 sajter visade det sig att 41 av dessa var sårbara för DOM-XSS. Jag anser att 41 % är en oroväckande hög siffra för sajter som skall ligga i framkant. Resultatet visar att företagen ännu inte har säkerhetsarbete - på en tillräckligt hög nivå - som en del i utvecklingsarbetet.

Jag kontaktade samtliga företag och beskrev säkerhetsproblemen. Jag fick god respons och många åtgärdade problemen inom några dagar. Testerna utfördes mellan den 10-17 november 2011 vilket gör att när detta publiceras så har företagen haft mer än två månader på sig att åtgärda eventuella brister.

Hur du skyddar dig mot DOM-XSS

Läs mer om vad DOM-XXS är här https://www.owasp.org/index.php/DOM_Based_XSS

OWASP har ett cheat sheet som går igenom hur man skyddar sig mot DOM-XSS https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet



Inlägget är skrivet av Patrik Corneliusson, boardmedlem OWASP Göteborg

Om OWASP

OWASP Göteborg (Open Web Application Security Project) är en ideell global organisation som fokuserar på att hjälpa mjukvaruutvecklare skriva säker programkod. OWASP har lokalavdelningar i fler än 80 länder världen över. Drivkraften är att fler utvecklare skall bli bättre på att skriva säkra applikationer.