Skript på flera sajter - Hur hackare kapar din sida

Tobias Schüring Senast uppdaterad den 15 januari 2020
6 Min.
Cross-site Scripting_XSS

XSS, SQL injektion, XMLrpc - om en WordPress säkerhetsuppdatering innehåller uppdateringsrapporterna huvudsakligen kryptiska förkortningar. Även om det är uppenbart att dessa uppdateringar är nödvändiga och den extra säkerheten är mycket tilltalande, är det viktigt att förstå vad som ligger bakom dessa sårbarheter. För bara om du förstår luckorna som uppdateringarna fyller kan du också fatta ett välgrundat beslut. Det är därför vi idag är dedikerade till skript över flera sajter, eller XSS, den överlägset vanligaste komplexa attacken på WordPress Sidor.

Hackerattacker kan lätt jämföras med inbrottstjuvar. Brute Force Attacker är mer lika metoden för kofotar. Brottslingen motstår verktyget tills dörren eller fönstret öppnas. Attacker på XSS-sårbarheter är å andra sidan sofistikerade: inbrottstjuven vet exakt var man ska börja och får riktad tillgång till ena sidan.

Under skript över flera webbplatser utnyttjas säkerhetsproblem på webbplatser på ett målinriktat sätt. Hackare infiltrerar skadliga skript i en betrodd kontext (dina sidor!). I likhet med en blind passagerare på ett fartyg använder denna skadliga kod din webbplats som ett fordon för att uppnå sina egna mål.

I värsta fall ger detta angripare konfidentiell information eller åtkomst till den skadade användarens dator. Sådana attacker är inte ovanliga: drygt hälften av attackerna Wordfence sårbarheter som konstaterades 2015 och 2016 i Plugins var sårbarheter för skript mellan platser. Ofta utgör en XSS-attack "basen" för ytterligare attacker, till exempel skräppost, phishing eller till och med DDoS-attacker. Det är därför jag visar dig idag hur exakt skript på flera sajter fungerar,vilka typer av attacker det finns och hur farliga attackerna är.

Skript på flera webbplatser fungerar alltid på samma sätt: ett mellanrum leder skadlig kod till din sida

Skript över flera webbplatser är en risk när ett webbprogram vidarebefordrar användardata som anges i webbläsaren utan att söka efter någon skriptkod som kan finnas. Ett bra exempel på en sådan webbapplikation är en supportchatt.

De skadliga skripten kan användas för att komma åt servern via själva webbprogrammet. Därifrån kommer den skadliga koden förr eller senare att landa med de drabbade klienterna. Ett bra exempel på en sådan XSS-sårbarhet är den som upptäcktes i juli 2016Bugg i bilden metainfos i WooCommerce 2.6.2. Ett fel tillät angripare att injicera HTML-kod i metadescriptions av bilder från utsidan. Alla kunder som skulle ha tittat på bilden i fråga (e.B. genom att klicka på bilden) skulle riskera att bli attackerade. En hackare kan till exempel ha infekterat dina kunders datorer med ett virus.

Populärt trick i skript på flera sajter: Manipulerade formulär

XSS kan också tillåta hackare att ersätta ofarliga former med manipulerade former. Dessa formulär samlar sedan in offrens data (dina sidbesökare!). Förrestenkan SSL-kryptering inte heller skyddas. Eftersom HTTPS betyder "bara" att anslutningen mellan servern och klienten är krypterad. Men om själva formuläret manipuleras fungerar inte en krypterad anslutning.

Som med andra typer av attacker är målet för hackare i de flesta fall att tjäna pengar på sina intriger. Konkret innebär detta att angripare antingen stjäl data som de senare säljer eller vill infektera sidor för att integrera dem i ett så kallat botnet, som sedan hyrs ut.

3 typer av XSS: reflekterad, beständig och lokal XSS

Skriptattacker över flera sajter kan delas in i tre typer:

Grovt räknat utförs XSS-attacker enligt följande: Skadlig kod injiceras där användarinmatning förväntas (t.ex. i en intern sökning). Som en del av serverns svar körs den skadliga koden sedan av klienten, dvs. i användarens webbläsare. Och det är precis här respektive skada orsakas, det vill säga användardata stjäls.

Reflekterande skript över flera webbplatser

Vissa indata, till exempel sökningar, återspeglas av servern. Det innebär till exempel att efter att ha skrivit "Test" i sökrutan, matar sidan ut "Du sökte efter test". Så vad användaren anger blir en del av serverns svar.

Detta är exakt vad angriparna smart utnyttjar: Om ett skadligt skript skickas till webbservern istället för en sökterm kan sidan manipuleras på ett sådant sätt att den i slutändan kör den. Den här typen av angrepp kallas också icke-beständiga. Den skadliga koden injiceras därför endast tillfälligt på respektive sida, men lagras inte.

I juli Plugin WP Statistics fann en sådan sårbarhet (och fixade den samma dag!). Ett indatavärde på wps_visitors_page sidan vidarebefordrades omarkerat, vilket resulterade i ett säkerhetsproblem på grund av reflekterad XSS. En sida kan till exempel hackas om en administratör tidigare hade klickat på en motsvarande manipulerad länk

Så här kan en reflekterad skriptattack på flera sajter se ut .B.
Så här kan en reflekterad skriptattack på flera sajter se ut .B.

Så här fungerar det:Angriparen sprider länkar med manipulerade parametrar till sina potentiella offer. Utan att veta om det skickar användaren en "manipulerad" begäran till servern genom att klicka på länken och den skadliga koden körs tillsammans med serverns svar. Eftersom, till skillnad från den beständiga XSS, koden inte lagras någonstans, måste hackaren distribuera den i massor till potentiella offer. Detta kan till exempel ske via e-post eller sociala nätverk.

Beständig skript över flera webbplatser

Med beständiga eller beständiga XSS lagras de skadliga skripten på webbservern och levereras varje gång en klient anropar dem. Förutbestämda för detta är webbapplikationer som lagrar användardata på serversidan och sedan matar ut dem utan verifiering eller kodning (t.ex. forum). Denna typ av skript kan vara särskilt farligt för högfrekventa bloggar och forum, eftersom skadlig programvara 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.
Förfallodatum för en beständig skriptattack på flera plats. Källa: Blog SAP

Tillexempel lagras In ettforum, publicerade inlägg i en databas. Dessa lagras ofta omarkerade och okrypterade. Angripare utnyttjar den här affärsmöjligheten och lägger till ett skadligt skript (t.B. med hjälp av en kommentar) i ett normalt foruminlägg. Användarna får respektive länk till inlägget antingen via e-post eller slumpmässigt anländer till motsvarande post och kör skriptet med inläggets anrop. Fördel för hackaren: Han kan nu "spionera" på drabbade kunder eller lägga till dem i sitt botnet för ytterligare attacker.

DOM-baserad eller lokal skript på flera sajter

Till skillnad från beständiga och reflekterade XSS fungerar DOM-baserade skript (Document Object Model) genom att köra skript på klientsidan. Detta innebär att servern inte känner till en sådan attack och att säkerhetsåtgärder på serversidan inte hjälper.

Ett välkänt exempel på en sådan klyfta är fallet med genericonpaketet. Genericon-paketet är en ikonuppsättning som Plugins , inklusive Jetpack. Via en HTML-fil i den här ikonuppsättningen var det möjligt att injicera motsvarande skadlig kod.

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.
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. Källa: securityaffairs.co

En DOM-baserad XSS-attack kräver dock att användaren klickar på en komprometterad URL. Genom att anropa den här URL:en kan den skadliga koden köras genom ett mellanrum i ett skript på klientsidan. Bland annat gör det faktum att en länk måste klickas först den DOM-baserade XSS till en något svårare och därför mindre sannolik typ av attack.

Bilden visar ett möjligt flöde av en lokal skriptattack på flera plats.
Ett exempel på en lokal skriptattack på flera plats. Källa: heise.de

Exempel: Användaren klickar på den manipulerade WEBBADRESSen och skickar en begäran till webbprogrammet. Detta svarar genom att skicka skriptkoden (som är skadad men inte manipulerad) till webbläsaren för att börja köra skriptet. De manipulerade parametrarna från URL:en tolkas och körs nu i användarens webbläsare som en del av skriptet. Webbsidan som visas i webbläsaren ändras således och användaren ser nu den manipulerade sidan utan att inse det.

Slutsats: Ganska vanligt och inte ofarligt, därför är lämpligt skydd viktigt

XSS-sårbarheter är en av de vanligaste gatewayerna för skadlig kod någonsin. Och ofta utgör en motsvarande attack grunden för ytterligare attacker, till exempel skräppost, phishing eller till och med DDoS-attacker. Angripare kapar din sida och missbrukar den för att uppnå sina egna mål.

Reflekterande och ihållande XSS är särskilt vanliga eftersom lokala skript över flera webbplatser är mer komplexa och svåra att implementera. Sidor som vidarebefordrar angivna användardata till webbläsaren utan att kontrollera om det finns någon skadlig kod är särskilt sårbara. Att hitta sådana luckor är inte så lätt. I princip är detta just säkerhetsleverantörernas uppgift, såsom Sucuri och Co, som ständigt utvecklar sina säkerhetsåtgärder.

Men naturligtvis finns det också för normala WordPress - användare har möjlighet att skydda sig mot dessa attacker.Uppdateringar av alla WordPress komponenter är e..B. en enkel men mycket effektiv åtgärd. Hur du kan förhindra skript på flera webbplatser som webbplatsoperatör, men också som Internetanvändare, förklarar vi i vår nästa artikel om ämnet.

Har du några kommentarer eller frågor? Lämna då bara en kommentar!

Som systemadministratör övervakar Tobias vår infrastruktur och hittar varje justeringsskruv för att optimera prestandan hos våra servrar. På grund av sina outtröttliga ansträngningar är han ofta också Slack som ska hittas.

Liknande artiklar

Kommentarer om den här artikeln

Skriva en kommentar

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