Cross-Site Scripting (XSS)

Reflekterade XSS-attacker

I reflekterade XSS-attacker injiceras det skadliga skriptet i en HTTP-förfrågan (vanligtvis genom en särskilt utformad länk som tillhandahålls användaren). I den enklaste varianten används inmatningsparametrar i HTTP-förfrågan som lätt kan manipuleras för att inkludera det skadliga skriptinnehållet. Det skadliga skriptet reflekteras sedan från servern i ett HTTP-svar och körs i offrets webbläsare.

I det här fallet fungerar det som en lagrad XSS utan att faktiskt lagra skadliga data på servern.

Här är ett exempel på en reflekterad XSS-attack:

Låt oss säga att example.com/profile innehåller en namnparameter. URL:en för begäran skulle se ut så här: https://example.com/profile?user=Tammy. Baserat på denna inmatning skulle webbapplikationen alltså svara med ”Hi Tammy” högst upp på sidan. Om parametrarna inte valideras för att säkerställa att de endast innehåller förväntade data, kan en angripare få en användare att besöka en skadlig version av URL:en, till exempel så här: https://example.com/profile?user<script>some_malicious_code</script>.

När svaret skickas till webbläsaren innehåller det det skadliga skriptet, som sedan körs i webbläsaren, sannolikt utan att användaren vet om det. Detta är ett exempel på en reflekterad XSS-attack, eftersom den skadliga koden omedelbart ”reflekteras” tillbaka till användaren som gör begäran.

Stored XSS-attacker

I en så kallad lagrad eller persistent XSS-attack levereras skadligt innehåll direkt tillsammans med serverns svar när användaren laddar en webbsida. Innehållet är alltså redan lagrat i webbplatsens databas (därav namnet på sådana attacker). Användarna går sedan helt enkelt in på den hackade webbsidan och faller offer för sådana attacker.

Varje enskild användare som öppnar en sådan komprometterad webbplats riskerar alltså att få sina personuppgifter stulna, och därför kan detta anses vara den farligaste typen av XSS-attack.

Men hur kommer det skadliga innehållet in i databasen till att börja med? I de flesta fall introduceras det genom oskyddade formulär på webbsidan där användarinmatningen inte valideras och renodlas ordentligt. Om de uppgifter som en hackare matar in inte valideras på både klient- och serversidan kommer de att sparas i databasen. Sådan inmatning kan till exempel omfatta ett textområde för kommentarer, en redigerare för inläggstext, en redigerare för personuppgifter eller andra formulär.

När en angripare lyckas skicka skadligt innehåll till servern och det innehållet visas ofiltrerat på en webbsida blir alla användare potentiella offer.Det vanligaste botemedlet mot lagrade XSS-attacker är att rensa inmatningen på både fram- och baksidan av applikationen. Sanitizing innebär en kombination av validering av data och undvikande av specialtecken eller fullständig filtrering av dessa och är en vanlig bästa praxis för webb- och JavaScript-säkerhet.

DOM-baserade XSS-attacker

Document Object Model (DOM) är ett gränssnitt som gör det möjligt för program att läsa och manipulera strukturen på en webbsida, dess innehåll och stil. I en DOM-baserad XSS-attack ligger sårbarheten i skriptkoden på webbläsarsidan och kan utnyttjas utan någon serverinteraktion alls, vilket ändrar miljön i det intet ont anande offrets webbläsare.

Undertiden liknar DOM-baserade XSS-attacker reflekterade attacker. Ovanstående exempel på en reflekterad XSS-attack kan tillämpas i det här fallet med ett enda antagande: Webbprogrammet läser data direkt från en frågesträng.

Säg att programmet använder frågeparametern ”name” för att omedelbart visa användarens namn på skärmen medan man väntar på att resten av sidan ska laddas. Utan korrekt validering kan detta ge samma resultat som vid en reflekterad attack, om hackaren lyckas få offret att öppna en misstänkt länk.

För att förhindra reflekterade och DOM-baserade attacker bör utvecklare, precis som vid lagrad XSS, implementera datavalidering och undvika att visa obearbetad användarinmatning, oavsett om det finns eller inte finns någon kommunikation med servern.

Vilka angreppsvektorer för Cross-site Scripting?

Det finns flera vektorer som ofta används vid XSS-attacker:

• <script> taggen: En script-tagg kan användas för att referera till extern JavaScript-kod, vilket gör detta till den enklaste XSS-punkten. Angripare kan också bädda in den skadliga koden i skripttaggen.
• JavaScript-händelser: En annan populär XSS-vektor som används av angripare, händelseattribut, kan användas i en mängd olika taggar. Sådana attribut som ”onerror” och ”onload” är exempel.
• <body> taggen: Händelseattribut kan också vara källan till skriptet när de tillhandahålls via ”body”-taggen.
• <img> taggen: Händelseattribut kan också vara källan till skriptet när de tillhandahålls via ”body”-taggen: Beroende på vilken webbläsare som används kan det här attributet användas av angripare för att köra JavaScript-koden.
• <iframe>: Den här vektorn är särskilt effektiv för phishing-attacker och gör det möjligt för XSS-attacken att bädda in en annan HTML-sida i den aktuella sidan.
• <input>-taggen: Vissa webbläsare tillåter manipulation genom denna vektor, som kan användas för att bädda in ett skript.
• <link> taggen: Den här taggen kan innehålla ett skript, i stället för den normala användningen av länkar till externa formatmallar.
• <table> taggen: Om bakgrundsattributet normalt hänvisar till en bild, kan det äventyras så att det hänvisar till det felande skriptet.
• <div> taggen: Denna tagg innehåller också en bakgrundsreferens och kan användas på samma sätt som <table> för att hänvisa till ett skript.
• <object> tagg: Det finns andra vektorer som XSS-attackerare använder för att stjäla information och äventyra webbplatser, men dessa är några av de vanligaste metoderna. Utvecklare måste följa korrekta rutiner för att skydda sig mot sådana attacker.
  

  Vilken inverkan har XSS-sårbarheter?

  XSS har potential att orsaka förödelse i program och på webbplatser. Det faktum att XSS har funnits med på alla OWASP:s topp 10-listor illustrerar behovet av att skydda webbapplikationer från denna sårbarhet.

  Avhängigt av angriparen och dennes illvilliga avsikt kan XSS-attacker leda till olika konsekvenser, bland annat:

  • Hijacking a user’s session, utilizing credentials to access other sites or redirect the user to unintended websites,
  • alternating website pages or inserting sections into a web page,
  • executing scripts to extract sensitive information from cookies or databases,
  • Om offret har administratörsrättigheter kan angreppet utvidgas till serverns sida, vilket orsakar ytterligare skada eller hämtar ytterligare känslig information.

  Hur testar man Cross-site Scripting?

  Testning av XSS-sårbarhet börjar redan i konstruktionsfasen, med beaktande av bästa praxis från början. Webbplatsdesigners bör bygga in säkerhetsåtgärder, inte lägga till dem i efterhand.
  De första testerna omfattar bench scans av kod för att identifiera användningen av vanliga XSS-attackvektorer som utgör potentiella sårbarheter. Detta gör det möjligt att mildra svagheterna innan den egentliga testningen av applikationen börjar.

  Nyckelsteg vid testning av XSS-sårbarheter för kritiska webbapplikationer är:

  • Användning av ett verktyg för kodskanning för att upptäcka sårbarheter som gör det möjligt att korrigera koden under utvecklingsprocessen,
  • Implementering av automatiserad testfunktionalitet som avslöjar potentiella sårbarheter grundligt och snabbt.

  Testa din kod för XSS-sårbarheter

  Automatiskt hitta, prioritera och åtgärda sårbarheter i de beroenden av öppen källkod som används för att bygga dina molnbaserade applikationer

  Vad är ett exempel på Cross-site Scripting?

  Cross-site scripting kan utnyttjas när en webbapplikation använder data som tillhandahålls av webbläsaren för att skapa svar på användarens förfrågningar. Ett mycket förenklat exempel skulle vara ett fall där en webbapplikation använder sig av en parameter i URL:en för att ge ett anpassat svar till användaren.

  Vad sägs om exmple.com/profile innehåller en namnparameter. URL:en för begäran skulle se ut som https://example.com/profile?user=Tammy. Webbapplikationen svarar med ”Hi Tammy” högst upp på sidan baserat på denna inmatning.

  Om användarparametern inte valideras för att säkerställa att den endast innehåller förväntade data, kan en angripare få en användare att besöka en skadlig version av URL:n som ser ut så här:
  https://example.com/profile?user<script>some_malicious_code</script>.
  När svaret sänds till webbläsaren innehåller det det skadliga skriptet som sedan exekveras i webbläsaren, troligen utan att användaren ens vet om det. Detta är ett exempel på en reflekterad XSS-attack. Den skadliga koden ”reflekteras” omedelbart tillbaka till användaren som gör förfrågan.

  Hur förhindrar man Cross-site Scripting?

  Det finns flera viktiga åtgärder för att förhindra XSS-attacker: öka utbildningen och medvetenheten hos dina utvecklare, granska och validera datainmatningen och skanna koden efter sårbarheter.