Den cross-site scripting (forkortet XSS ) er en type af sikkerhedsbrist af hjemmesider til at injicere indhold på en side, der forårsager handlinger på web-browsere , der besøger siden. XSS muligheder er meget brede, da angriberen kan bruge alle de sprog, der understøttes af browseren ( JavaScript , Java ...), og nye muligheder opdages regelmæssigt, især med ankomsten af nye teknologier såsom HTML5 . For eksempel er det muligt at omdirigere til et andet sted for phishing eller endda at stjæle sessionen ved at hente cookies .
Cross-site scripting forkortes som XSS for ikke at forveksles med CSS (stilark), X læser " krydse " på engelsk.
Udtrykket cross-site scripting er ikke en meget præcis beskrivelse af denne type sårbarhed. XSS-pioner Mark Slemko sagde:
”Problemet er ikke kun scripting, og der foregår ikke nødvendigvis noget mellem flere sider. Så hvorfor dette navn? Faktisk blev navnet givet, da problemet blev mindre forstået, og det sidder fast. Tro mig, vi havde vigtigere ting at gøre end at tænke på et bedre navn. "
- Mark Slemko, " Cross Site Scripting Info " , om Apache HTTP-serverprojektet ,Februar 2000
Princippet er at indsprøjte vilkårlige data på et websted, for eksempel ved at sende en besked i et forum eller ved hjælp af URL-parametre. Hvis disse data ankommer som på den webside, der sendes til browseren (via URL-parametrene, en meddelelse osv.) Uden at være blevet bekræftet, er der en fejl: den kan bruges til at udføre ondsindet kode ved hjælp af script-sprog ( oftest JavaScript ) af webbrowseren, der ser denne side.
Detektering af tilstedeværelsen af en XSS-fejl kan f.eks. Gøres ved at indtaste et JavaScript-script i et formularfelt eller i en URL:
<script>alert('bonjour')</script>
Hvis der vises en dialogboks, kan det konkluderes, at webapplikationen er modtagelig for XSS-angreb.
Udnyttelsen af en fejl i XSS-typen ville gøre det muligt for en ubuden gæst at udføre følgende operationer:
Der er ingen standardiseret klassificering af script-sårbarheder på tværs af websteder, men man kan let skelne mellem to hovedtyper af XSS: ikke-vedvarende og vedvarende. Det er også muligt at opdele disse to typer i to grupper: traditionel XSS (forårsaget af en sårbarhed på serversiden) og DOM- baseret XSS (på grund af en sårbarhed på klientsiden).
Denne type sikkerhedsbrud, som kan betegnes som "ikke-permanent", er langt den mest almindelige.
Det vises, når data leveret af en webklient bruges ligesom serverskripter til at producere en resultatside . Hvis de ukontrollerede data er inkluderet på resultatsiden uden kodning af HTML-enhederne , kan de bruges til at injicere kode i den dynamiske side, der modtages af klientbrowseren.
Et klassisk eksempel i websteds søgemaskiner: Hvis du søger efter en streng, der indeholder specielle HTML- tegn , vises den søgte streng ofte på resultatsiden for at minde dig om, hvad der blev søgt, eller i et tekstfelt til genudstedelse af denne kanal . Hvis den viste streng ikke er kodet, er der en XSS-sårbarhed.
Ved første øjekast er dette ikke et alvorligt problem, fordi brugeren kun kan indsætte kode på deres egne sider. Imidlertid kan en angriber med lidt social engineering overbevise en bruger om at følge en narret URL, der injicerer kode i resultatsiden, hvilket giver angriberen fuld kontrol over indholdet af denne side. Da social engineering er påkrævet for at udnytte denne type fejl (og den foregående), mente mange programmører, at disse huller ikke var særlig vigtige. Denne fejl er generelt generelt til XSS-sårbarheder generelt.
Denne type sårbarhed, også kaldet en permanent eller anden ordens sårbarhed, tillader kraftige angreb. Det sker, når data leveret af en bruger er gemt på en server (i en database, filer eller hvad som helst) og derefter vises igen uden at de specielle HTML-tegn er blevet kodet .
Et klassisk eksempel er fora, hvor brugere kan sende tekst formateret med HTML-tags. Disse sårbarheder er større end andre typer, fordi en angriber bare kan indsprøjte et script en gang og nå et stort antal ofre uden at ty til social engineering.
Der er forskellige injektionsmetoder, som ikke nødvendigvis kræver, at angriberen bruger selve webapplikationen. Alle de data, der modtages af webapplikationen (via e-mail, logfiler ...), som kan sendes af en angriber, skal være kodet inden deres præsentation på en dynamisk side, ellers eksisterer der en XSS-fejl.
Denne type XSS-fejl har været kendt i lang tid. En artikel skrevet i 2005 definerer klart dens karakteristika. I dette scenarie er problemet i scriptet til en klientsideside. For eksempel, hvis et fragment af JavaScript har adgang til en parameter i en URL- anmodning og bruger disse oplysninger til at skrive HTML på sin egen side, og disse oplysninger ikke er kodet som HTML-enheder , er der sandsynligvis en XSS-sårbarhed. De skriftlige data fortolkes igen af browseren som HTML-kode, der muligvis indeholder et tilføjet ondsindet script.
I praksis vil måden at udnytte en sådan fejl være på den følgende type, undtagen i en meget vigtig situation. På grund af den måde, Internet Explorer behandler scripts på klientsiden i objekter, der er placeret i den "lokale zone" (såsom klientens lokale harddisk), kan en sårbarhed af denne type føre til sårbarheder i forbindelse med fjernudførelse. For eksempel, hvis en hacker er vært for et "ondsindet" websted, der indeholder et link til en sårbar side på klientens lokale system, kan der indsprøjtes et script, der kører med rettighederne til brugerens webbrowser på det system. Dette omgår " sandkassen " fuldstændigt , ikke kun de begrænsninger på tværs af domæner, der normalt omgåes af XSS.
Flere teknikker kan bruges til at undgå XSS:
Der er biblioteker, der tillader effektiv filtrering af tagget brugergenereret indhold (udgivelsessystemer).
Desuden er det også muligt at beskytte mod XSS-sårbarheder ved hjælp af dedikeret netværksudstyr såsom applikations firewalls . Disse filtre tillader, at alle HTTP- strømme filtreres for at opdage mistænkelige anmodninger.
Flere større angreb brugte sårbarheder på tværs af scripting: