Hur man kontrollerar om ditt WordPress-system är säkrat mot XSS-attacker
Över hela världen är nästan 48 procent av alla webbplatser sårbara för cross-site scripting (XSS). Över hela världen använder nästan exakt 25 procent av alla webbplatser WordPress-plattformen.
Det följer att i Venn-diagrammet över webbplatser som är sårbara för XSS och webbplatser som kör WordPress-plattformen måste överlappningen vara ganska stor.
Det här är inte en knackning på själva plattformen. WordPress-teamet har gjort säkerhet till en integrerad del av sin mission statement och korrigerar aggressivt sårbarheter när de blir kända. Ändå hindrar detta inte människor från att koda osäkra teman eller installera osäkra plugins. Dessa problem är de två primära ingångarna för XSS-attacker på WordPress-webbplatser, och den här artikeln kommer att diskutera hur man stoppar dem.
Introduktion till cross-site scripting
Låt oss först diskutera hur XSS-attacker utförs. Det finns mer än en typ av XSS-attack, så jag börjar med en förenklad definition. Generellt sett börjar XSS-attacker med osanifierade indata—kommentarformulär, kommentarsrutor, sökfält, et cetera. Dessa attacker varierar mycket i sofistikerad form. Egentligen ses den enklaste formen av XSS-attack av WordPress-användare varje dag: spamkommentaren. Du vet vad jag pratar om: ”Tack för den utmärkta artikeln. Förresten, här är min sida där jag tjänar 5 000 dollar i veckan på att arbeta hemifrån: www.only-an-idiot-would-click-this-link.co.uk.”
På något sätt är skräppostkommentarer det perfekta exemplet på en XSS-attack. En skadlig enhet undergräver infrastrukturen på din webbplats (kommentarrutan) för att placera deras innehåll (den skadliga länken) på din webbplats. Även om detta är ett bra illustrativt exempel, kommer en mer realistisk XSS-attack att vara mycket mer subtil. En skräppostkommentar tar ungefär fem sekunder för någon att skapa. En XSS-attack är något en riktig hackare kommer att lägga lite mer tid på.
En äkta svart hatt kommer att försöka dra nytta av alla aspekter av din webbplats som skickar data till servern, i huvudsak använda dem som en miniatyr textredigerare. Om dina indata är oförsvarade betyder det att de bokstavligen kan ta sin kod och tvinga din applikation att köra den och rendera i en användares webbläsare (och det kan inkludera din webbläsare). Till skillnad från skräppostkommentarer kan endast en detaljerad undersökning av din webbplatss modifierade kod eller genom att kamma webbplatsinteraktioner avslöja ett intrång. Som man kan föreställa sig finns det inget slut på antalet otäcka saker som kan bli resultatet av ett sådant brott.
Enkel vandalism är ett relativt vanligt resultat av XSS-attacker, vilket resulterar i att dina användare visas groteska bilder eller politisk propaganda i stället för ditt innehåll. Marknadsförare med få långsiktiga planer eller etiska problem kommer att använda dem för att annonsera för människor mot deras vilja. En mer nyanserad och subtil attack kan stjäla dina användares inloggningsuppgifter. Om en av dem har administratörsbehörighet kan all personlig information som du lagrar på din webbplats vara aktuell. Alternativt kan de använda den första XSS-attacken som en hävstång för att bända upp din webbplats och installera ännu mer avancerad skadlig programvara.
Att stoppa attacker
Om du är en någorlunda kodkunnig person, och du är ensam ägare till en relativt liten WordPress-webbplats, kommer säker kodning förmodligen att vara det bästa sättet att låsa din webbplats mot skriptattacker över flera webbplatser. Jag inkluderar denna varning eftersom om du är en del av en större organisation som kör en mer komplex applikation, kanske det inte är mänskligt möjligt för dig att hitta alla områden där en skadlig angripare kan injicera kod. Moderna webbplatser kan vara enorma i omfattning, och det kan vara lämpligt att anlita en erfaren proffs och lägga din tid på andra sysselsättningar för att göra din webbplats ännu bättre för dina läsare.
En annan varning är att om du inte är särskilt kodkunnig och låter någon annan bygga din webbplats åt dig, anta inte att de har använt säker kodningsmetoder. Även de mest erfarna utvecklarna har varit kända för att lämna säkerheten vid sidan av eller göra mindre fel utan att någon annan kontrollerar deras arbete. Andra utvecklare kanske helt enkelt inte vet vad de gör när det gäller säkerhet, och andra slarvar fortfarande över säkerheten för att spara tid för sig själva (trots bristen på professionalism när det kommer till det). Sammanfattningsvis, se till att du anlitar en hyllad proffs som inte skär hörn när det gäller att utveckla och skydda din webbplats.
Denna oro som uttrycks, en av de första och enklaste sakerna du kan göra för att förhindra cross-site scripting är att validera användardata.
Låt oss säga att du har ett registreringsformulär på din webbplats, och det formuläret ber användaren att skriva in sitt namn. En illvillig användare kan istället skriva något i stil med:
Detta kan till exempel göra att nästa person som besöker den sidan skickar en kopia av sina cookies till en angripare.
Du kan se att i det här exemplet ser kodsträngen ovan inte ut som någons namn. Din server vet inte detta, men genom att använda några få parametrar kan du lära ut det. Du kan till exempel tala om för det fältet att avvisa specialtecken, såsom ,() och ; (de behövs inte särskilt i ett kommentarsfält). Du kan tala om för det fältet att en persons namn förmodligen inte har siffror i det. Om du är villig att vara lite drakonisk kan du säga till det fältet att avvisa indata som är mer än femton tecken långa (eller så kan du ändra värdena som du vill ha dem). Att vidta dessa steg kommer att drastiskt begränsa mängden skada en angripare kan göra med ett visst fält.
Även med datavalidering kan det finnas formulär eller fält där du inte realistiskt kan begränsa typen av tecken som används, till exempel i ett kontaktformulär eller kommentarsfält. Det du kan göra är att rensa data. Denna process gör det omöjligt för HTML att exekveras i ett givet fält, och konverterar allt som kan kännas igen som en del av körbar kod till icke-kodande tecken. Som ett exempel kommer en hyperlänk inte att visas där det annars kan finnas en.
Slutligen finns det fall där din webbplats kan sluta visa data som är osäker för användarna. Låt oss säga att någon skriver en skadlig kommentar på en av dina sidor, som sedan indexeras av din webbplatss sökfunktion. Närhelst en av dina användare gör en sökning, exekveras den skadliga koden när deras webbläsare laddar sökresultaten. Detta förhindras av escape-data, vilket säkerställer att när din webbplats levererar data till en användare, är den enda koden som körs koden du vill köra.
För mer om datavalidering, sanering av data och flykting av data har WordPress Codex en utmärkt resurs. Den kommer att förklara ovanstående begrepp i detalj samt ge fler exempel som kan tillämpas universellt.
Andra metoder
Stora företag har större webbsidor; det är fakta. Kanske tusentals människor använder din webbplats per dag. Kanske finns det istället för standardformulär och fält även animationer, olika portaler, delar skrivna i Java och så vidare. Även om du håller reda på allt det där, kanske det finns en nolldag i en av dina applikationer, och du har inget sätt att försvara dig.
I en situation som denna, om du har inflytande och budget för att göra det, skulle jag rekommendera att du investerar i en webbapplikationsbrandvägg (WAF). En bra WAF kommer att ha korrelationsregler som automatiskt identifierar och blockerar de HTML-strängar som oftast förknippas med kodinjektionsattacker. De kan också meddela dig när applikationer börjar exfiltrera data när de inte är tänkta eller gör det i en ovanlig volym, vilket hjälper till att försvara sig mot nolldagsattacker och andra avancerade hot. En WAF är inte en silverkula, men det är ett ovärderligt verktyg för säkerhetspersonal och webbplatsägare som hoppas kunna skydda komplexa applikationer.
Det finns också ett antal plugins som utger sig för att försvara sig mot XSS-attacker. Jag rekommenderar faktiskt inte dessa. Istället för att minska risken representerar många av dessa plugins bara ytterligare en attackyta för en hackare att utnyttja. Till och med ett av de mest kända och mest använda säkerhetsplugin-programmen, Akismet, visade sig vara sårbart för XSS-attacker förra året. När det gäller att avleda XSS-attacker, lita inte på halva åtgärder. Utveckla nödvändiga färdigheter och använd lämplig uppsättning verktyg för att hålla din webbplats säker.
Andra praktiska tillämpningar
Denna information kan vara lite komplex för den oinvigde, men jag skulle hata att folk skulle bli avskräckta av den potentiella komplexiteten i denna information. Skulle en XSS-attack inträffa kan du vara säker på att det kommer att bli mycket mer komplext att städa upp efter en sådan händelse än att göra ändringar på din webbplats. Att städa upp kostnaderna för din webbplats (vanliga läsare kommer att fly din webbplats ganska lätt) kommer att vara ett ytterligare problem som du inte vill behöva oroa dig för.
Även om du får någon annan att sköta din webbplatsutveckling och säkerhet åt dig, gör vad du kan för att åtminstone kunna reagera på en nödsituation och veta var dina svaga punkter finns. Att veta hur man kontrollerar ditt system kommer att vara en viktig färdighet i det långa loppet och vara grunden för andra säkerhetsämnen och webbplatsutvecklingsprojekt. Allt är sammankopplat online och även om XSS-attacker kan höra till de senaste åren (hur osannolikt det än är), kommer att känna till detaljerna på din webbplats aldrig att vara föråldrade.
Slutgiltiga tankar
Internetsäkerhetslandskapet förändras ständigt. Du kan aldrig vara helt säker på hur en XSS-attack kan se ut eller hur den kan användas mot dig, men du är skyldig dig själv och dina läsare att se till att du gör allt som står i din makt för att stoppa dem. Fortsätt att informera dig själv om detta hot och kontrollera regelbundet (jag skulle rekommendera minst en gång i månaden) för relevant utveckling inom cybersäkerhetsvärlden.
Detta betyder inte heller att du kan ignorera andra hot. Åtkomst till offentliga nätverk kräver fortfarande VPN-användning för att vara säker. Du kan inte försumma säkerheten för någon dator du använder för att komma åt din webbplats. Inloggningsinformation måste fortfarande ändras ofta och vara säker från brute force-attacker. XSS-attacker är brutala, men de är inte det enda hotet att se upp för.
Det kan också vara lämpligt att dela denna information (eller till och med den här artikeln) med dina kamrater och intresserade parter för att sprida motstånd mot dessa typer av attacker. Även om du kanske inte kan göra för mycket själv, om tillräckligt många människor skyddar sig ordentligt, kan vi se en generell minskning av dessa typer av attacker när hackare försöker komma på ett annat sätt att tjäna på fattiga internetanvändare.
Har du själv några tankar om hur du ska leta efter XSS-attacker samt försvara dig mot dem i framtiden? Finns det några andra upptäckts- och borttagningsstrategier du själv använder för att bekämpa detta hot? Finns det några verktyg du skulle rekommendera till dina medläsare? Om så är fallet, vänligen lämna en kommentar nedan och fortsätt denna viktiga konversation med dina medläsare.