Angrepsscenario

1. Angriperen finner XSS-sårbarheten på et nettsted som brukes av offeret, f.eks. en banks nettsted.
2. Offeret er for øyeblikket logget inn på denne siden
3. Angriperen sender offeret en forfalsket URL
4. Offeret klikker på nettadressen
5. På offerets bank nettsted, JavaScript kode begynner å kjøre for å fange opp brukerens data eller utføre en overføring på hans vegne til angriperens konto

Det er verdt å merke seg at operasjoner som utføres på vegne av offeret kan være usynlige for offeret, ettersom de kan foregå i bakgrunnen ved hjelp av bankens API, eller angriperen kan utføre dem senere med data som trengs for autentisering, tokens, informasjonskapsler osv.

XSS-typer

1. Reflektert XSS

Dette er en kode der HTML/JavaScript-koden i en hvilken som helst parameter (f.eks. GET, POST eller cookie) vises som svar.

En side med en tekstinngang for å søke etter noe som setter parameteren ?search=foo i URL-enden når du spør API-et. Hvis en frase ikke blir funnet etter at du har skrevet den inn, vises en returmelding i HTML ex.

<div>Ingen resultater funnet for <b>foo</b></div>

Vi kan prøve å legge inn URL-en ?search=..

2.DOM XSS

Dette er når utførelsen er aktivert ved bruk av farlige funksjoner i JavaScript, for eksempel `eval` eller `innerHtml`. "Live-eksemplet" nedenfor viser et DOM XSS-angrep basert på `innerHtml` funksjon.

3. Lagret XSS

Dette er en situasjon der den ondsinnede koden blir skrevet på serversiden. Vi kan for eksempel sende en kommentar med ondsinnet kode til et blogginnlegg som lastes opp til serveren. Oppgaven er for eksempel å vente på administratorens moderering og deretter stjele øktdataene hans osv.

Injeksjonsmetoder

1. I taggens innhold

`onerror=alert('XSS')`inn i

<img src onerror="alert('XSS')" />

2. I innholdet i attributtet

`" onmouseover=alert('XSS')` inn i

<div class="" onmouseover="alert('XSS')""></div>

3. I innholdet i attributtet uten anførselstegn

x onclick=alert('XSS')inn i

<div class="x" onclick="alert('XSS')"></div>

4. I hrefef-attributt

javascript:alert('XSS') inn i

<a href="javascript:alert('XSS')"></a>

5. I strengen inne i JavaScript-koden

";alert('XSS')// inn i

<script>let username="";alert('XSS')//";</script>

6. I attributtet med hendelsen JavaScript

');alert('XSS')//. hvor ' er et enkelt anførselstegn, til

<div onclick="change('&#39;);alert('XSS')//')">John</div>

7. I href attributt i JavaScript-protokollen

);alert(1)// hvor %27 er et enkelt anførselstegn, til

<a href="javascript:change('%27);alert(1)//')">klikk</a>

Direkte eksempel

Forsvarsmetoder

1. Datakoding ved hjelp av innebygde funksjoner som finnes i mange programmeringsspråk.
2. Bruk av malsystemer med automatisk koding. De fleste populære rammeverkene som bruker slike systemer, beskytter oss fra XSS-injeksjon (Django...maler, Vue, React etc.).
3. Ikke bruk funksjoner som evaluering eller Funksjon med upålitelige brukerdata.
4. Ikke bruk funksjoner og egenskaper som tilordner HTML-kode direkte til DOM-treelementene, f.eks, innerHTML, outerHTML, insertAdjacentHTML, ocument.write. I stedet kan du bruke funksjoner som tilordner tekst direkte til disse elementene, for eksempel tekstInnhold eller innerText.
5. Vær forsiktig når du omdirigerer brukeren til en URL som er under brukerens kontroll. Risiko for injeksjon location = 'javascript('XSS')'.
6. Filtrer HTML ved hjelp av biblioteker som f.eks. DOMPurify.
7. Vær forsiktig med å laste opp .html eller .svg filer. Du kan opprette et eget domene som de opplastede filene skal betjenes fra.
8. Bruk Retningslinjer for innholdssikkerhet mekanisme.
9. Ta en titt på anti-XSS-filtrene som er innebygd i de mest populære nettleserne.

   Hvis du synes denne artikkelen er interessant, kan du følge Lukasz på Github: https://github.com/twistezo

Les mer om dette:

Strategier for datahenting i NextJS

Rails API og CORS. Et snev av bevissthet

Hvorfor bør du (sannsynligvis) bruke Typescript?