Cross Site Scripting

Cross Site Scripting - hur din webbplats kapas

XSS, SQL-injektion, XMLrpc - när en säkerhetsuppdatering för WordPress släpps innehåller uppdateringsrapporterna oftast kryptiska akronymer. Även om det är uppenbart att dessa uppdateringar är nödvändiga och att det är mycket glädjande med ett säkerhetsplus, är det viktigt att förstå vad som ligger bakom dessa säkerhetssårbarheter. För endast om du förstår vilka luckor som uppdateringarna täpper till kan du också fatta ett välgrundat beslut. Därför ska vi idag titta på Cross Site Scripting, eller XSS, som är den överlägset vanligaste komplexa attacken på WordPress-webbplatser.

Hackerattacker kan jämföras med ett inbrott. Brute force-attacker liknar snarare kofotmetoden. Kriminella gör motstånd mot verktyget tills dörren eller fönstret öppnas. Attacker på XSS-sårbarheter är däremot sofistikerade: Brottslingarna vet exakt var de ska börja och får tillgång till en webbplats på ett mycket målinriktat sätt.

Vid cross-site scripting utnyttjas säkerhetsluckor på webbplatser avsiktligt. Skadliga skript injiceras i ett pålitligt sammanhang (din webbplats!). I likhet med en fripassagerare på ett fartyg använder denna skadliga kod din webbplats som ett medel för att uppnå sina egna mål.

I värsta fall erhålls konfidentiell information eller till och med tillgång till den utsatta användarens dator. Sådana attacker är inte direkt ovanliga: Drygt hälften av de sårbarheter i insticksprogram som säkerhetsleverantören Wordfence hittade 2015 och 2016 var sårbarheter för cross-site scripting. En XSS-attack utgör ofta "grunden" för ytterligare attacker, t.ex. spam, phishing eller DDoS-attacker. Därför ska jag i dag visa dig hur exakt Cross Site Scripting fungerar, vilka typer av attacker det finns och hur farliga attackerna är.

Cross Site Scripting har en grundläggande princip

Cross-site scripting bygger på grundprincipen att utnyttja ett kryphål och föra in skadlig kod på din webbplats. Det är alltid en fara när en webbapplikation vidarebefordrar inmatade data till webbläsaren utan att kontrollera om det finns eventuell skriptkod. Ett bra exempel på en sådan webbapplikation är en supportchatt.

De skadliga skripten kan nå servern via själva webbapplikationen. Därifrån hamnar den skadliga koden förr eller senare på de drabbade klienterna. Ett bra exempel på en sådan XSS-sårbarhet är den bugg som upptäcktes i juli 2016 i meta-infos om bilder i WooCommerce 2 .6.2. På grund av ett fel var det möjligt att smuggla in HTML-kod i meta-beskrivningarna av bilder utifrån. Alla enheter på vilka den berörda bilden nu betraktades närmare (t.ex. genom att klicka på bilden) riskerade att bli attackerade. Bland annat kunde de datorer som bilden visades på ha blivit infekterade med ett virus.

"*" visar obligatoriska fält

Jag vill prenumerera på nyhetsbrevet för att få information om nya bloggartiklar, e-böcker, funktioner och nyheter om WordPress. Jag kan återkalla mitt samtycke när som helst. Observera vår integritetspolicy.
Det här fältet är avsett för validering och bör inte ändras.

Populärt trick för cross-site scripting: manipulerade formulär

XSS kan också göra det möjligt att ersätta ofarliga formulär med manipulerade formulär. Dessa formulär samlar sedan in offrens uppgifter (på din webbplats!). Förresten kan inte ens SSL-kryptering skydda mot detta. HTTPS innebär "bara" att anslutningen mellan server och klient är krypterad. Men om själva formuläret har manipulerats är även en krypterad anslutning värdelös.

Precis som med andra typer av attacker är målet i de flesta fall att tjäna pengar. I konkreta termer innebär detta att antingen data stjäls och senare säljs, eller att infekterade webbplatser integreras i ett så kallat botnät som sedan hyrs ut.

3 typer av XSS

Cross-site scripting-attacker kan grovt delas in i tre typer:

  • Reflekterad Cross Site Scripting
  • ihållande cross site scripting
  • DOM-baserad eller lokal cross site scripting

XSS-attacker fungerar i stort sett på följande sätt: Skadlig kod injiceras på en plats där det förväntas inmatning från klienten (t.ex. under en sidintern sökning). Som en del av serverns svar utförs den skadliga koden sedan på klienten, dvs. i webbläsaren. Och det är just där som skadan sker, till exempel att data stjäls.

Reflekterande Cross Site Scripting

Vissa inmatningar, t.ex. sökfrågor, reflekteras av servern. Detta innebär att webbplatsen till exempel efter att ha skrivit in "test" i sökfältet, visar webbplatsen "Du sökte efter test". Den inmatade texten blir alltså en del av serverns svar.

Det är just detta som utnyttjas på ett skickligt sätt: Om ett skadligt skript skickas till webbservern i stället för en sökterm kan webbplatsen manipuleras så att den i slutändan utför skriptet. Den här typen av angrepp kallas också för icke-persistent. Det innebär att den skadliga koden endast tillfälligt injiceras i respektive webbplats, men inte lagras.

I juli 2017 upptäcktes en sådan sårbarhet i insticksprogrammet WP Statistics (och den rättades redan samma dag!). Ett inmatningsvärde på sidan "wps_visitors_page" vidarebefordrades okontrollerat, vilket ledde till en sårbarhet genom reflekterad XSS. Om en administratör tidigare hade klickat på en motsvarande manipulerad länk kunde alltså en webbplats hackas.

Cross Site Scripting reflekterad XSS
Så här kan en reflekterad cross-site scripting-attack se ut.

Det fungerar så här: Länkar med manipulerade parametrar sprids till potentiella offer. Utan att veta om det skickar offret en "manipulerad" begäran till servern genom att klicka på länken, och den skadliga koden körs tillsammans med serverns svar. Eftersom koden - till skillnad från persistent XSS - inte lagras någonstans måste den spridas i stor skala till potentiella offer. Detta kan till exempel ske via e-post eller sociala nätverk.

Persistent Cross Site Scripting

Med persistent XSS lagras de skadliga skripten på webbservern och levereras varje gång de anropas av en klient. Detta gäller särskilt webbapplikationer som lagrar användardata på servern och sedan skickar ut dem utan kontroll eller kodning (inklusive forum). Den här typen av scripting kan vara särskilt farlig för mycket välbesökta bloggar och forum, eftersom skadlig kod kan spridas snabbt här på grund av det stora antalet användare.

Den här bilden visar ett möjligt flöde av en beständig skriptattack på flera plats.
Sekvens av en ihållande cross site scripting-attack. Källa: Blogg SAP

Exempel: I ett forum lagras de inlägg som skrivs i en databas. Det är inte ovanligt att dessa lagras okontrollerat och okrypterat. Denna möjlighet utnyttjas lätt och gör det möjligt att lägga till ett skadligt skript i ett helt normalt foruminlägg (på ett enkelt sätt med hjälp av en kommentar). Användarna får antingen länken till inlägget via e-post eller så kommer de av en slump fram till det motsvarande inlägget och utför skriptet när de öppnar inlägget. Nu kan till exempel drabbade klienter "spioneras" eller läggas till i ett botnät för ytterligare attacker.

DOM-baserad eller lokal cross-site scripting

Till skillnad från persistent och reflekterad XSS fungerar DOM-baserad cross site scripting genom att exekvera skript på klientsidan. Detta innebär att servern inte är medveten om en sådan attack och att säkerhetsåtgärder på serversidan inte heller hjälper.

Ett välkänt exempel på ett sådant kryphål var fallet med generikapaketet. Genericon-paketet är en ikonuppsättning som används av många insticksprogram. Det var möjligt att injicera skadlig kod via en HTML-fil i denna ikonuppsättning.

När du har anget den här URL:en visades en javascript-avisering. Detta är ett bevis på att inmatad javascript-kod kan användas för att manipulera respektive sida.
Efter att ha skrivit in denna webbadress visades en JavaScript-varning. Detta är ett bevis på att den JavaScript-kod som matas in kan användas för att manipulera webbplatsen i fråga. Källa: securityaffairs.co

En förutsättning för en DOM-baserad XSS-attack är dock att användaren klickar på en manipulerad URL. Genom att ringa upp denna URL kan den skadliga koden exekveras genom en lucka i ett skript på klientsidan. Bland annat det faktum att en länk först måste klickas på gör DOM-baserat XSS till en något svårare och därför mindre sannolik typ av angrepp.

Cross Site Scripting lokal XSS
Exempel på en lokal cross-site scripting-attack.

Exempel: Den manipulerade webbadressen klickas och skickar en begäran till webbprogrammet. Webbapplikationen svarar genom att skicka skriptkoden (som är felaktig men inte manipulerad) till webbläsaren för att starta utförandet av skriptet. De manipulerade parametrarna från webbadressen tolkas nu i klientens webbläsare som en del av skriptet och utförs. Den webbplats som visas i webbläsaren ändras således och användarna ser nu den manipulerade webbplatsen utan att märka det.

Åtgärder mot Cross Site Scripting

De bästa åtgärderna mot cross-site scripting-attacker är enkla att genomföra. Det är bäst att förlita sig på regelbundna uppdateringar, brandväggar och vitlistor. För det andra kan även serverns utdata säkras.

Regelbundna uppdateringar

Sårbarheterna genom vilka den skadliga koden infiltreras finns antingen i WordPress kärnan, i plugins eller i teman. Det är just därför som regelbundna uppdateringar av alla dessa komponenter är så viktiga. Eftersom de sårbarheter som hittills har hittats åtgärdas i dessa uppdateringar.

Det är också klokt att regelbundet läsa detaljerna i uppdateringarna för att få en känsla för vilka säkerhetsbrister som regelbundet täpps till genom uppdateringarna. När det gäller underhålls- och säkerhetsuppdateringar av WordPress-kärnan, till exempel, finns denna information dokumenterad i WordPress-bloggen.

Brandväggar och vitlistor mot enkla XSS-attacker

En annan enkel skyddsåtgärd mot XSS-attacker är så kallade brandväggar för webbapplikationer(WAF). Dessa brandväggar är hjärtat i stora säkerhetsplugins och får information om de senaste sårbarheterna från tillverkarens forskningsteam. En WAF är i allmänhet ett förfarande som skyddar webbapplikationer från attacker via Hypertext Transfer Protocol (HTTP).

Men även dessa skyddsmekanismer har sina begränsningar. För vissa XSS-attacker sker attacken via databasen. Därför är kontroll av användarens inmatning av skadlig kod en av de centrala säkerhetsmekanismerna i kampen mot XSS-attacker. Innehållet i kommentarer skannas till exempel efter misstänkta teckensträngar och sorteras vid behov bort.

Datautmatning bör också säkras

Regelmäßige Updates schließen vorhandene XSS Sicherheitslücken und Firewalls sowie Whitelists versuchen Schadcode auszufiltern, bevor dieser den Webserver erreicht und die Website infizieren kann. Doch sollte auch die Datenausgabe entsprechend gesichert werden. Die meisten Programmier- und Skriptsprachen, wie PHP, Perl oder JavaScript, besitzen hierfür bereits vordefinierte Funktionen zur Zeichenersetzung bzw. -maskierung. Diese sorgen dafür, dass „problematische“ HTML Metazeichen wie <> und & durch harmlose Zeichenreferenzen ersetzt werden. So wird verhindert, dass der Schadcode aktiv werden kann. Auch sollte der Code mithilfe von sogenannten sanitization libraries bereinigt werden. Hierfür wird ein Plugin auf dem Server installiert und zusätzlicher Code in den Quellcode deiner Website eingebunden. Der folgende Codeschnipsel sorgt dann zum Beispiel dafür, dass <class> zu den erlaubten Attributen hinzugefügt wird:

var sanitizer = new HtmlSanitizer();
sanitizer.AllowedAttributes.Add("class");
var sanitized = sanitizer.Sanitize(html);

Det krävs kunskaper i programmering för att genomföra detta. Detta skydd för datautmatning är lätt att genomföra för någon med denna kunskap.

En hälsosam nivå av skepsis: hur användare skyddar sig själva

Men det är inte bara webbplatsen i sig som påverkas av XSS-attacker, utan även klienterna (dvs. din webbläsare). Många XSS-attacker kan förhindras genom en kritisk och noggrann hantering av "utländska" länkar. Det finns bland annat möjlighet att använda NoScript-tillägg. Dessa förhindrar utförandet av skript, dvs. de skadliga kodraderna som bland annat stjäl data.

De som vill vara på den säkra sidan kan också undvika cross-site scripting på klientsidan genom att stänga av JavaScript-stödet i webbläsaren. Om denna så kallade aktiva skriptning inaktiveras har vissa typer av XSS-attacker inte längre någon chans, eftersom de skadliga programmen inte ens startas. De flesta moderna webbplatser "fungerar" då dock inte längre som de ska - eller i värsta fall fungerar de inte längre alls. Det är därför nödvändigt att väga samman aspekterna säkerhet och användbarhet. Om du är intresserad av detta alternativ kan du hitta det i inställningarna för din webbläsare.

Slutsats

XSS-sårbarheter är en av de vanligaste inkörsportarna för skadlig kod. En motsvarande attack utgör ofta grunden för ytterligare attacker, t.ex. skräppost, nätfiske eller DDoS-attacker. Din webbplats kapas och missbrukas för andra ändamål. XSS är därför inte utan fara, och därför är ett lämpligt skydd viktigt.

Reflekterad och persistent XSS är särskilt vanliga, eftersom lokal cross-site scripting är mer komplicerat och svårt att genomföra. Webbplatser som vidarebefordrar inmatade användardata till webbläsaren utan att kontrollera om det finns någon skadlig kod är särskilt utsatta. Det är dock inte så lätt att hitta sådana luckor. I princip är detta just en uppgift för säkerhetsleverantörer som sucuri och andra, som ständigt utvecklar sina säkerhetsåtgärder.

Men det finns naturligtvis också ett sätt för vanliga WordPress att skydda sig mot dessa attacker. Uppdateringar av alla WordPress-komponenter är bland annat en enkel men mycket effektiv åtgärd. Om du håller dina plugins och teman uppdaterade och använder en WAF har du redan tagit ett stort steg i rätt riktning. Om du dessutom använder whitelists för inkommande och utgående kod har du redan säkrat din webbplats på ett utmärkt sätt. Särskilt de två sista åtgärderna är dock inte lätta att genomföra utan programmeringskunskaper.

Jämfört med de ganska primitiva brute force-attackerna är de mer komplexa XSS-attackerna tyvärr fortfarande relativt ofta framgångsrika. Det finns dock betydligt färre av dessa så kallade komplexa attacker än det finns brute force-attacker på WordPress-webbplatser. Trots detta bör du göra det så svårt som möjligt för dessa attacker. Ett lyckat hack kostar inte bara tid och pengar för att ta bort skripten, utan kan också äventyra din position i sökmotorerna.

Tyckte du om artikeln?

Med din recension hjälper du oss att förbättra vårt innehåll ytterligare.

Skriva en kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *.