Cross-site Scripting-sårbarheter har utnyttjats av angripare sedan början av 2000-talet, och XSS har varit på OWASP Top 10-listan över kritiska säkerhetsrisker för webbapplikationer från och med 2004. Men många utvecklare, systemadministratörer och till och med vissa penetrationstestare tar det fortfarande inte på allvar. För att bli en effektiv webbapplikationshacker eller försvarare måste du förstå grunderna för hur man förhindrar XSS-attacker.
XSS-attacker är fortfarande problem
Cross-site scripting är en typ av webbapplikationssårbarhet som gör det möjligt för angripare att injicera och köra skadlig kod på klientsidan i offrets webbläsare i en legitim webbapplikation.
effekten och svårighetsgraden av framgångsrika XSS-attacker kan variera. XSS-attacker kan leda till kapning av sessioner, stulna tokens, stulna sessionscookies och förfalskningsattacker över flera platser. Dessa attacker kan leda till att användarkonton äventyras.
en lyckad XSS-attack kan också göra det möjligt för en angripare att använda stulna eller förfalskade cookies för att efterlikna giltiga användare. I de fall där den giltiga användaren har administrativa rättigheter i programmet kan angriparen sedan använda dessa behörigheter för att ändra sidor eller utföra fjärrkodkörning på serversidan av programmet.
typer av XSS-attacker
det finns tre typer av XSS-attacker: lagrad, reflekterad och Dokumentobjektmodell (DOM) baserad.
- en lagrad XSS-attack gör det möjligt för en angripare att bädda in ett skadligt skript i en sårbar sida, som sedan körs när ett offer tittar på sidan. Lagrad XSS anses vara den mest skadliga typen av XSS-attack. När en angripare till exempel injicerar en skadlig JavaScript-nyttolast direkt i en sårbar webbapplikation sparar webbläsaren den injicerade JavaScript-nyttolasten. Sedan, varje gång offret besöker den webbplatsen eller webbapplikationen, körs den skadliga koden.
- en reflekterad XSS-attack inträffar när den skadliga nyttolasten är inbäddad i en länk och aktiveras endast när användaren klickar på länken. Här lagras inte den skadliga nyttolasten utan visas bara på webbsidan i form av en URL-eller postdata.
- en DOM-baserad XSS-sårbarhet uppstår när DOM används för att generera dynamiskt innehåll som innehåller användarinmatning som kan bearbetas utan kontroll. Denna typ av attack utförs med JavaScript i offrets webbläsare
XSS attack prevention
för att förhindra XSS-attacker måste utvecklare validera användarinmatning genom att korrekt filtrera bort eller fly från specialtecken och sedan koda utmatningen för att förhindra lagrade XSS-attacker och reflekterade XSS-attacker. Följande specialtecken ska alltid filtreras bort eller undvikas för att förhindra att de utnyttjas skadligt:
< |
> |
” |
’ |
) |
( |
& |
utvecklare bör validera användarinmatning-källor – och koda utmatningen-sänkor-för att förhindra DOM-baserade XSS-attacker. Egenskapen input source är där DOM läser från, och källan är där angriparen kan injicera skadlig kod för att utnyttja XSS-sårbarheten. Följande källegenskaper bör undvikas:
- URL
- documentURI
- plats
- href
- sök
- hash
sänkor är de punkter där DOM kör skadliga tecken eller kod från ingången-källan-som i sin tur får matas ut till webbsidan. Dessa sänkor bör undvikas för att förhindra denial-of-service-baserade XSS-attacker:
- innerHTML
- outerHTML
- skriv
om du vill bli bättre på att förstå och förebygga XSS-attacker har Google byggt en XSS-spelwebbplats för att lära dig hur dessa attacker fungerar och hur man bättre kan förhindra dem. Mutillidae 2-projektet från OWASP erbjuder också ett inlärningsmål för webbsäkerhetspersonal att skärpa sina XSS-attackförsvar.