Vad är Cross-Site Scripting

18 april 2020 By Christine Margret Inga kommentarer 5 minuter

Cross-Site Scripting, även kallad XXS, är en skadlig attack som medvetet injicerar skadliga skript i en användares webbläsare. Angriparen kör skadlig kod i en webbapplikation eller webbsida, och så snart användaren besöker webbapplikationen eller webbsidan; det skadliga skriptet överförs automatiskt till användarnas webbläsare.

Cross Site Scripting

På så sätt tar angriparen kontroll över användarens webbläsare eller hans konto på en specifik webbplats. Det betyder att denna attack inte skadar själva webbapplikationen, utan påverkar användarna av den applikationen.

Dessutom överförs de skadliga skripten vanligtvis som JavaScript-kod. De skadliga koderna kan dock även utnyttja användarnas webbläsare på andra språk, inklusive HTML, Ajax, Flash och Java.

Skaffa sig FastestVPN

Sammanfattning av förklaringen

Här är en kort sammanfattning av Cross-Site Scripting-förklaring:

XXS är en webbaserad attack mot sårbara webbsidor eller webbapplikationer
Det skadar användare av webbapplikationen, inte själva applikationen
XXS överför skadliga program till användare via JavaScript.

Hur fungerar Cross-Site Scripting (XXS) Attack?

Cross-site scripting attacker äger rum på ett sätt att det först manipulerar en sårbar webbapplikation med skadligt skript, och sedan levererar webbapplikationen det skadliga JavaScriptet till användarens webbläsare.

Så snart det skadliga skriptet kommer in i användarens webbläsare kan angriparen enkelt ta kontroll över användarens webbläsare.

Syftet med cross-site scripting

En angripare utför XXS-attacker på grund av följande skäl:

För att hacka ett konto
Att överföra skadlig programvara och virus på system som använder internet
För att komma åt en användares urklippsinnehåll och webbläsarhistorik
För att fjärrstyra användarens webbläsare
För att utnyttja och komma åt intranätapplikationer

Exempel på cross-site scripting

Några av de mest sårbara källorna för att injicera XXS är egna anslagstavlaforum och webbplatser som tillåter användarinlägg.

Nu delar vi ett enkelt exempel på Cross-Site Script nedan:

Det är en JSP-kod, där du kan se att en HTTP-begäran görs, och koden läser ett anställd-ID, eid, som visar det för användaren.

Koden i det här exemplet fungerar bara bra om koden (eid) innehåller standard alfanumerisk text.

Men om samma kod (eid) använder något metakaraktär eller källkodsvärde, betyder det att koden kommer att tvingas av webbläsaren att visas för användaren som HTTP-svar.

Till en början verkar det inte vara en större sårbarhet eftersom ingen någonsin skulle ange en skadlig URL. Men störningen börjar när en angripare skapar en skadlig länk och lurar användare att besöka länken som är gömd i URL:en.

Vanligtvis lurar angriparen användare genom social ingenjörskonst och e-post och lockar användare att besöka en skadlig länk.

Så fort användaren klickar på den skadliga länken skickar han oavsiktligt tillbaka webbapplikationens skadliga innehåll till sitt eget system.

Processen att återspegla det skadliga innehållet kallas reflekterad XXS. XXS-attackerna orsakar allvarliga störningar som ofta ledde till manipulering och grov datastöld.

Typer av cross-site scripting

Lagrad/beständig XSS

Lagrad/persistent XSS-attack är den mest störande formen av en XSS-attack där en angripare sänder ett permanent skript på webbapplikationen. Användare faller offer för skadliga skript när någon begäran görs på servern.

Reflekterad XXS

Denna typ av Cross-Site Scripting involverar inte att attackera servern direkt. Den använder e-post för att lura användare att köra skadliga skript i webbläsaren. Webbläsaren tror att det är ett pålitligt skript och därför reflekteras allt skadligt innehåll tillbaka i användarens webbläsare.

DOM-baserade attacker

DOM-baserade attacker är mindre vanliga och skiljer sig på ett sätt så att de aldrig stör serversidans kod, den förlitar sig bara på skripten på klientsidan.

DOM hänvisar till dokumentobjektmodellen som är ett applikationsprogrammeringsgränssnitt (API) för HTML- och XML-dokument. DOM-baserade attacker äger rum endast när en webbapplikation visar användardata i en dokumentobjektmodell.

Webbapplikationen läser användarens data och överför den till webbläsaren. Om användardata inte är säker kan en angripare enkelt lagra skadliga skript i DOM.

Hur man avgör din webbplatss sårbarhet

Du kan enkelt hålla koll på din webbplats sårbarhet genom webbsårbarhetsskannrar som Nessus, Nikto, Vega, Grab, WebScarab och mycket mer tillgängligt.

Det är viktigt att noggrant genomföra en säkerhetsgranskning av koden och ta reda på alla möjliga säkerhetshål som kan tillåta indata från en HTTP-förfrågan att få tillgång till HTML-utdata.

Tänk på att en mängd olika HTML-taggar kan användas för att köra en skadlig JavaScript. Därför är det viktigt att skanna en webbplats via webbsäkerhetsskannrar.

Om någon del av webbplatsen är sårbar, finns det chanser att hela webbplatsen kan drabbas av skada.

Hur man förhindrar cross-site scripting-attacker

Undgå användarinmatning

Att undkomma användarinmatning är en metod för att förhindra XXS-attacker. I den här metoden måste du se till att data som din webbapplikation är på väg att skicka tillbaka till användarnas webbläsare är säker.

WordPress och PHP innehåller funktioner som automatiskt sanerar den data du matar ut.

Ingångsvalidering

Indatavalidering är den process där all data som tillhandahålls av en webbapplikation kontrolleras och verifieras noggrant innan den skickas tillbaka till användarnas webbläsare.

Webbapplikationer måste kontrollera och validera data innan de går in i andra system. Det hjälper till att upptäcka alla skadliga länkar eller program som är avsedda att attackera användarnas system.

Slutsats

XXS-attacker är vanliga och kan störa användarnas integritet, men det är enkelt att testa och förhindra dina webbapplikationer från skadliga skript.

Webbapplikationer måste ständigt rensa sina input innan de skickas direkt till användarnas webbläsare. Dessutom kommer regelbundna webbskanningar att hjälpa webbapplikationer att hitta om det finns någon sårbarhet.