Cross-Site Scripting (XSS) og CSRF

Cross-Site Scripting (XSS) er en injeksjonssårbarhet på klientsiden der en angriper setter inn skadelige skript i nettsider som vises til andre brukere. I motsetning til SQL-injeksjon, som retter seg mot serveren, retter XSS seg mot offerets nettleser. Når nettleseren gjengir angriperens skript, kjører det med samme privilegier som legitime skript på siden – noe som muliggjør kapring av økter, tyveri av påloggingsinformasjon og levering av skadevare.

Reflektert XSS oppstår når et skadelig skript er innebygd i en URL, og serveren umiddelbart «reflekterer» det tilbake i HTTP-svaret uten riktig koding. Offeret lures (ofte via en phishing-lenke) til å klikke på den utformede URL-en, slik at nettleseren kjører angriperens skript. Reflektert XSS er ikke-persistent – det kjører bare når offeret klikker på den skadelige lenken.

Lagret (persistent) XSS bygger inn et skadelig skript i applikasjonens database – for eksempel i en kommentar eller et foruminnlegg. Skriptet kjøres i nettleseren til hver bruker som ser dette innholdet, noe som gjør lagret XSS langt farligere enn reflektert XSS. DOM-basert XSS oppstår utelukkende i nettleseren når JavaScript på klientsiden leser angriperkontrollerte data fra DOM-en (for eksempel URL-fragmentet) og skriver dem usikkert tilbake til siden.

Det viktigste forsvaret mot XSS er koding av utdata: konverter spesialtegn til tilsvarende HTML-entiteter (<, >, &) før de gjengis i nettleseren. En Content Security Policy (CSP)-header begrenser hvilke skript som kan kjøre, og gir et viktig sekundært forsvar. Validering av inndata (tillatelseslister) bør også brukes på serversiden.

Cross-Site Request Forgery (CSRF) utnytter tilliten et nettsted har til nettleseren til en autentisert bruker. En angriper lurer offerets nettleser til å sende en uønsket autentisert forespørsel til et nettsted der offeret er logget inn. Fordi nettleseren automatisk legger ved øktinformasjonskapsler, tror målserveren at forespørselen er legitim. Vanlige CSRF-angrep overfører penger, endrer e-postadresser eller endrer kontoinnstillinger.

Se for Dem at en bruker er logget inn i nettbanken sin på bank.com. En angriper sender en e-post med en skjult bildetag: <img src='https://bank.com/transfer?to=attacker&amount=1000'>. Når e-posten åpnes, laster nettleseren automatisk inn bilde-URL-en – og sender overføringsforespørselen med offerets øktinformasjonskapsel for banken vedlagt. Banken behandler den som en legitim forespørsel.

Det mest effektive CSRF-forsvaret er et CSRF-token – en unik, uforutsigbar verdi som bygges inn i hvert skjema og verifiseres på serversiden. Siden angriperen ikke kan lese tokenet fra en annen opprinnelse (same-origin-policy), mangler forfalskede forespørsler et gyldig token og blir avvist. Attributtet SameSite for informasjonskapsler (SameSite=Strict eller Lax) hindrer også nettlesere i å sende informasjonskapsler i forespørsler på tvers av nettsteder.

XSS og CSRF forveksles ofte, men retter seg mot ulike mål. XSS injiserer et skadelig skript som kjører i offerets nettleser – og utnytter brukerens tillit til nettstedet. CSRF forfalsker forespørsler fra offerets nettleser til et pålitelig nettsted – og utnytter nettstedets tillit til brukerens nettleser. XSS kan brukes til å stjele CSRF-tokener, slik at de to sårbarhetene effektivt kan lenkes sammen.

Flagg for informasjonskapsler gir viktige tiltak mot XSS. Flagget HttpOnly hindrer JavaScript i å få tilgang til informasjonskapselen via document.cookie, noe som gjør tyveri av øktokener vanskeligere selv om XSS er til stede. Flagget Secure sikrer at informasjonskapsler bare overføres via HTTPS, og hindrer avlytting på ukrypterte kanaler. Begge flaggene bør settes på alle øktinformasjonskapsler som et tiltak for forsvar i dybden.

Sikkerhetstestere identifiserer XSS ved å injisere testdata i alle inndatafelt, URL-parametere, HTTP-headere og JSON-felt. Et enkelt testuttrykk er <script>alert(1)</script> – hvis det vises en dialogboks, er XSS bekreftet. Verktøy som Burp Suite automatiserer XSS-skanning, og OWASP ZAP tilbyr gratis aktiv skanning. DOM-basert XSS krever analyse av JavaScript på klientsiden i stedet for inspeksjon av serversvaret.

XSS-angrep har forårsaket betydelig skade i den virkelige verden. Samy-ormen (2005) spredte seg på MySpace på 20 timer ved å utnytte lagret XSS til å spre seg selv til over én million profiler. XSS-angrep kan stjele øktokener for å kapre kontoer fullstendig, omdirigere brukere til phishing-nettsteder, levere nettleserutnyttelser (drive-by-nedlastinger) og endre sideinnhold slik at utvalgte brukere får se falsk informasjon.

I denne leksjonen har De lært at XSS injiserer skript i sider som vises til andre brukere, at CSRF lurer autentiserte nettlesere til å sende forfalskede forespørsler, og at koding av utdata, CSP, CSRF-tokener og SameSite-attributtet for informasjonskapsler er de viktigste forsvarstiltakene. Neste tema er ødelagt autentisering og usikker deserialisering.