Cross-Site Scripting (XSS)

Reflekterede XSS-angreb

I reflekterede XSS-angreb injiceres det skadelige script i en HTTP-forespørgsel (normalt via et specifikt udformet link, der leveres til brugeren). Som den enkleste variant bruger den inputparametre i HTTP-anmodningen, der let kan manipuleres til at inkludere det skadelige scriptindhold. Det skadelige script reflekteres derefter fra serveren i et HTTP-svar og bliver udført i offerets browser.

I dette tilfælde fungerer det som et gemt XSS uden faktisk at lagre skadelige data på serveren.

Her er et eksempel på et reflekteret XSS-angreb:

Lad os sige, at example.com/profile indeholder en name-parameter. URL’en for anmodningen ville se således ud: https://example.com/profile?user=Tammy. På baggrund af dette input ville webapplikationen således svare med “Hej Tammy” øverst på siden. Hvis parametrene ikke valideres for at sikre, at de kun indeholder forventede data, kan en angriber få en bruger til at besøge en skadelig version af URL’en som denne: https://example.com/profile?user<script>some_malicious_code</script>.

Når svaret sendes til browseren, indeholder det dette ondsindede script, som derefter udføres i browseren, sandsynligvis uden at brugeren selv ved det. Dette er et eksempel på et reflekteret XSS-angreb, da den skadelige kode straks “reflekteres” tilbage til den bruger, der foretager anmodningen.

Stored XSS-angreb

I det, der kaldes et gemt eller vedvarende XSS-angreb, leveres skadeligt indhold direkte sammen med serverens svar, når brugeren indlæser en webside. Indholdet er således allerede gemt i webstedets database (deraf navnet for sådanne angreb). Brugerne går derefter blot ind på den hackede webside og bliver ofre for sådanne angreb.

Hver eneste bruger, der åbner et sådant kompromitteret websted, risikerer således at få stjålet sine personlige data, og dette kan derfor betragtes som den farligste type XSS-angreb.

Men hvordan kommer det skadelige indhold ind i databasen til at begynde med? I de fleste tilfælde indføres det gennem ubeskyttede websideformularer, hvor brugerinput ikke er valideret og renset ordentligt. Hvis de data, der indtastes af en hacker, ikke valideres på både klient- og serversiden, vil de blive gemt i databasen. Et sådant input kan f.eks. omfatte et tekstområde til kommentarer, en teksteditor til indlæg, en editor til personlige data eller andre formularer.

Når det lykkes en angriber at sende skadeligt indhold til serveren, og dette indhold vises ufiltreret på en webside, bliver alle brugere potentielle ofre.

Det almindelige middel mod lagrede XSS-angreb er at rense input på både frontend og backend af applikationen. Sanitizing indebærer en kombination af validering af data og escaping af specialtegn eller fuldstændig filtrering af disse og er en almindelig bedste praksis for web- og JavaScript-sikkerhed.

DOM-baserede XSS-angreb

Document Object Model (DOM) er en grænseflade, der gør det muligt for programmer at læse og manipulere strukturen af en webside, dens indhold og stil. I et DOM-baseret XSS-angreb ligger sårbarheden i scriptkoden på browsersiden og kan udnyttes uden nogen som helst serverinteraktion, idet miljøet i det intetanende offers browser ændres.

Sommetider minder DOM-baserede XSS-angreb om reflekterede angreb. Ovenstående eksempel på et reflekteret XSS-angreb kan anvendes i dette tilfælde med en enkelt antagelse: Webapplikationen læser data direkte fra en forespørgselsstreng.

Lad os sige, at applikationen bruger forespørgselsparameteren “name” for straks at vise brugerens navn på skærmen, mens den venter på, at resten af en side indlæses. Uden korrekt validering kan dette give det samme resultat som ved et reflekteret angreb, hvis det lykkes hackeren at få offeret til at åbne et mistænkeligt link.

Som med lagret XSS bør udviklere for at forhindre reflekterede og DOM-baserede angreb implementere datavalidering og undgå at vise rå brugerinput, uanset om der er kommunikation med serveren eller ej.

Hvad er Cross-site Scripting-angrebsvektorer?

Der er flere vektorer, der almindeligvis anvendes i XSS-angreb:

• <script> tag: Et script-tag kan bruges til at henvise til ekstern JavaScript-kode, hvilket gør dette til det mest enkle XSS-punkt. Angribere kan også indlejre den skadelige kode i script-tagget.
• JavaScript-hændelser: En anden populær XSS-vektor, der bruges af angribere, er begivenhedsattributter, der kan anvendes i en række forskellige tags. Sådanne attributter som “onerror” og “onload” er eksempler.
• < <body> tag: Event-attributter kan også være kilden til scriptet, når de leveres via “body”-tagget.
• <img> tag: Afhængigt af den anvendte browser kan denne attribut være nyttig for angribere til at udføre JavaScript-kode.
• <iframe> tag: Denne vektor, der er særlig effektiv til phishing-angreb, gør det muligt for XSS-angrebet at indlejre en anden HTML-side i den aktuelle side.
• <input>-tag: Nogle browsere tillader manipulation via denne vektor, som kan bruges til at indlejre et script.
• <link> tag: Dette tag kan indeholde et script i stedet for den normale brug af link til eksterne stilark.
• <table> tag: Hvor baggrundsattributten normalt henviser til et billede, kan dette være kompromitteret til at henvise til det ulovlige script.
• <div>-tag: Dette tag indeholder også en baggrundsreference og kan bruges på samme måde som <table> til at henvise til et script.
• <object> tag: Skripter fra et eksternt websted kan inkluderes ved hjælp af dette tag.

Selv om der er andre vektorer, som XSS-angribere bruger i deres forsøg på at stjæle oplysninger og kompromittere websteder, er disse nogle af de mest almindeligt anvendte metoder. Udviklere skal overholde korrekte escaping- og sanitizing-praksis for at beskytte sig mod sådanne angreb.

Lad os sige, at exmple.com/profile indeholder en name-parameter. URL’en for anmodningen ville se ud som https://example.com/profile?user=Tammy. Webapplikationen svarer med “Hej Tammy” øverst på siden baseret på dette input.

Hvis brugerparameteren ikke valideres for at sikre, at den kun indeholder forventede data, kan en angriber få en bruger til at besøge en ondsindet version af URL’en, der ser således ud:
https://example.com/profile?user<script>some_malicious_code</script>.
Når svaret sendes til browseren, indeholder det dette ondsindede script, som derefter udføres i browseren, sandsynligvis uden at brugeren selv ved det. Dette er et eksempel på et reflekteret XSS-angreb. Den skadelige kode “reflekteres” straks tilbage til brugeren, der foretager anmodningen.