xss

Cross Site Scripting

Cross Site Scripting (XSS) er en av de mest vanlige angrepene vi opplever mot nettsider. Men hva er det og hvordan beskytter du deg mot det?

XSS er så vanlig at OWASP – The Open Web Application Security Project har rangert dette som nr. 3 på listen over de 10 største sikkerhetsutfordringene i 2013. I denne posten har jeg valgt å fokusere på nettsideaspektet, utfordringen som kanskje berører flest. Kort fortalt handler XSS om å injisere klientsideskript for å styre nettsidens funksjonalitet og å få tilgang til informasjon man normalt ikke har tilgang til. Som oftest er det snakk om Javascript-injeksjon, men det finnes også andre skripttyper. Selv om jeg her har valgt å fokusere på nettsider, finnes problemet strengt tatt alle steder hvor HTML håndteres.

XSS-angrep deles normalt inn i to grupper: temporære og vedvarende. Begge disse to gruppene deler samme grunntanke. Forskjellen ligger i om de blir lagret eller ikke. Temporære bærer preg av å utnytte muligheter der og da – for eksempel ved at man baker inn Javascript i URL-en og narrer en bruker til å klikke på noe annet en det de hadde til hensikt å klikke på. Vedvarende er igjen litt annerledes siden de lagres og sånn sett kan gjøre større ugagn mot en bredere masse. Her er to ulike historier som illustrerer hvordan det fungerer:

Temporært XSS angrep

Anne forsøker å få tilgang til Bjarne sin konto på et nettsted. Hun oppretter en nettside som speiler, tar imot og lagrer skjemadata. I tillegg manipulerer hun innloggingslenka til nettsiden og legger inn en Javascriptkode som endrer adressen det opprinnelige skjemaet sender data til. Anne forkorter lenka ved hjelp av en nettjeneste og sender lenka til Bjarne i håp om at Bjarne kommer til å klikke på lenka. Noe han gjør. Bjarne handler i god tro og logger seg inn. Brukernavn og passord blir oversendt nettsiden til Anne. Anne har nå kontroll over kontoen til Bjarne. Bjarne derimot, ser på en side som ser ekte ut, men skjønner ikke hvorfor han ikke får logget seg inn.

Vedvarende XSS

Forsiden på en communitynettside viste teksten «you’ve been hacked». All funksjonalitet på nettsiden var i tillegg borte. I senere tid viste det seg at artiklene medlemmene kunne opprette inneholdt et sikkerhethull. Javascript ble ikke fjernet fra artiklene på skikkelig måte. En nyopprettet bruker hadde lagt inn en Javascriptkode for å endre utseendet til nettsiden og deretter legge igjen en beskjed. I og med at nettsiden hadde en liste over nylig opprettede artikler på forsiden ble denne Javascriptkoden eksekvert, alt innhold ble gjemt og erstattet med «you’ve been hacked».

Stadig nye angrepsmetoder

Dette var to eksempler, men det finnes nærmest ingen grenser for hvordan angripere kan utnytte XSS hull på.

Med kløkt, kreativitet og klokskap finner de alltid nye angrepsmåter. Som utviklere er det vår oppgave å påse at all informasjon inn i våre systemer renses for utsatt kode. Hvis informasjonen også skal vises til brukeren må vi også påse at visningen skjer på en trygg måte. Jeg fokuserte her på nettsideaspektet – altså hva brukerne ser. Men hva med AJAX, REST og andre måter å legge inn innhold på? Problemstillingen XSS gjelder også her. Informasjon lagt inn via tjenester som AJAX og REST vises kanskje ikke der og da – men det kan tenkes at de vil vises et eller annet sted på et eller annet tidspunkt. Vi er med andre ord avhengige av å alltid tenke gjennom hvordan ting vises og eksekveres – helt fra fronted til backend og tilbake.


Men hvordan beskytter man seg? Jeg anbefaler å begynne med å sette seg inn i ressursene OWASP har publisert på sine nettsider

Illustrasjon: Acunetix

Publisert