Hvordan sjekke om WordPress-systemet ditt er sikret mot XSS-angrep

På verdensbasis er nesten 48 prosent av alle nettsteder sårbare for cross-site scripting (XSS). På verdensbasis bruker nesten nøyaktig 25 prosent av alle nettsteder WordPress-plattformen.

Det følger at i Venn-diagrammet over nettsteder som er sårbare for XSS og nettsteder som kjører WordPress-plattformen, må overlappingen være ganske stor.

Dette er ikke en bank på selve plattformen. WordPress-teamet har gjort sikkerhet til en integrert del av oppdragserklæringen og retter aggressivt opp sårbarheter når de blir kjent. Likevel hindrer dette ikke folk i å kode usikre temaer eller installere usikre plugins. Disse problemene er de to primære inngangene for XSS-angrep på WordPress-nettsteder, og denne artikkelen vil diskutere hvordan de kan stoppes.

Introduksjon til cross-site scripting

La oss først diskutere hvordan XSS-angrep utføres. Det er mer enn én type XSS-angrep, så jeg skal starte med en forenklet definisjon. Vanligvis starter XSS-angrep med usanerte innganger – kommentarskjemaer, kommentarfelt, søkefelt osv. Disse angrepene varierer mye i raffinement. Faktisk blir den enkleste formen for XSS-angrep sett av WordPress-brukere hver dag: spamkommentaren. Du vet hva jeg snakker om: «Takk for den utmerkede artikkelen. Forresten, her er siden min hvor jeg tjener 5000 dollar i uken på å jobbe hjemmefra: www.only-an-idiot-would-click-this-link.co.uk.»

På en eller annen måte er spam-kommentarer det perfekte eksempelet på et XSS-angrep. En ondsinnet enhet undergraver infrastrukturen til nettstedet ditt (kommentarfeltet) for å plassere innholdet deres (den ondsinnede koblingen) på nettstedet ditt. Selv om dette er et godt illustrerende eksempel, vil et mer realistisk XSS-angrep være mye mer subtilt. En spam-kommentar bruker omtrent fem sekunder på å lage. Et XSS-angrep er noe en skikkelig hacker vil bruke litt mer tid på.

En ekte svart hatt vil prøve å dra nytte av alle aspekter av nettstedet ditt som sender data til serveren, i hovedsak bruke dem som en miniatyr tekstredigerer. Hvis inndataene dine ikke er forsvarte, betyr det at de bokstavelig talt kan ta koden deres og tvinge applikasjonen din til å kjøre den og gjengi den i en brukers nettleser (og det kan inkludere nettleseren din). I motsetning til spamkommentarer, kan bare en detaljert undersøkelse av nettstedets modifiserte kode eller kjemming av interaksjoner på nettstedet avsløre et brudd. Som man kanskje kan forestille seg, er det ingen ende på antallet ubehagelige ting som kan følge av et slikt brudd.

Enkel hærverk er et relativt vanlig resultat av XSS-angrep, som resulterer i at brukerne dine blir vist groteske bilder eller politisk propaganda i stedet for innholdet ditt. Markedsførere med få langsiktige planer eller etiske bekymringer vil bruke dem til å annonsere for folk mot deres vilje. Et mer nyansert og subtilt angrep kan stjele brukernes påloggingsinformasjon. Hvis en av dem har administratorrettigheter, kan all personlig informasjon du lagrer på nettstedet ditt være tilgjengelig. Alternativt kan de bruke det første XSS-angrepet som en spak for å åpne nettstedet ditt og installere enda mer avansert skadelig programvare.

Stoppe angrep

Hvis du er en person med rimelig kodekunnskap, og du er eneeier av et relativt lite WordPress-nettsted, vil sikker kodingspraksis sannsynligvis være den beste måten å låse nettstedet ditt mot skriptangrep på tvers av nettsteder. Jeg inkluderer denne advarselen fordi hvis du er en del av en større organisasjon som kjører en mer kompleks applikasjon, er det kanskje ikke menneskelig mulig for deg å finne alle områder der en ondsinnet angriper kan injisere kode. Moderne nettsteder kan være enorme i omfang, og det kan være på sin plass å ansette en erfaren profesjonell og bruke tiden din på andre sysler for å gjøre nettstedet ditt enda bedre for leserne dine.

En annen advarsel er at hvis du ikke er spesielt kodekyndig og får noen andre til å bygge nettstedet ditt for deg, så ikke anta at de har brukt sikker kodingspraksis. Selv de mest erfarne utviklerne har vært kjent for å la sikkerhet stå utenfor eller gjøre mindre feil uten å få noen andre til å sjekke arbeidet deres. Andre utviklere vet kanskje rett og slett ikke hva de gjør når det gjelder sikkerhet, og andre skjuler fortsatt sikkerheten for å spare tid for seg selv (til tross for mangel på profesjonalitet når det gjelder det). Oppsummert, sørg for at du ansetter en anerkjent profesjonell som ikke skjærer hjørner når det gjelder å utvikle og beskytte nettstedet ditt.

Denne bekymringen blir uttrykt, en av de første og enkleste tingene du kan gjøre for å forhindre skripting på tvers av nettsteder, er å validere brukerdata.

La oss si at du har et registreringsskjema på nettstedet ditt, og det skjemaet ber brukeren om å skrive inn navnet sitt. En ondsinnet bruker kan i stedet skrive noe som:

Dette kan for eksempel føre til at neste person som besøker siden sender en kopi av informasjonskapslene sine til en angriper.

Du kan se at i dette eksemplet ser kodestrengen ovenfor ikke ut som noens navn. Serveren din vet ikke dette, men ved å bruke noen få parametere kan du lære det. Du kan for eksempel fortelle at feltet skal avvise spesialtegn, slik som ,() og ; (de er ikke spesielt nødvendige i en kommentarseksjon). Du kan fortelle det feltet at en persons navn sannsynligvis ikke har tall i det. Hvis du er villig til å være litt drakonisk, kan du fortelle det feltet å avvise inndata som er mer enn femten tegn lange (eller du kan endre verdiene som du vil ha dem). Å ta disse trinnene vil drastisk begrense mengden skade en angriper kan gjøre med et bestemt felt.

Selv med datavalidering kan det være skjemaer eller felt der du ikke realistisk kan begrense typen tegn som brukes, for eksempel i et kontaktskjema eller kommentarfelt. Det du kan gjøre er å rense data. Denne prosessen gjør det umulig for HTML å bli utført i et gitt felt, og konverterer alt som kan gjenkjennes som et stykke kjørbar kode til ikke-kodende tegn. Som et eksempel vil en hyperkobling ikke vises der det ellers kan være en.

Til slutt er det tilfeller der nettstedet ditt kan ende opp med å vise data som er utrygge for brukere. La oss si at noen skriver en ondsinnet kommentar på en av sidene dine, som deretter blir indeksert av nettstedets søkefunksjon. Når en av brukerne dine utfører et søk, kjøres den skadelige koden når nettleseren deres laster søkeresultatene. Dette forhindres av escape-data, som sikrer at når nettstedet ditt leverer data til en bruker, er den eneste koden som kjører koden du vil kjøre.

For mer om datavalidering, rensing av data og unnslipping av data, har WordPress Codex en utmerket ressurs. Den vil forklare begrepene ovenfor i detalj, samt gi flere eksempler som kan brukes universelt.

Andre metoder

Store selskaper har større nettsider; det er fakta. Kanskje tusenvis av mennesker bruker nettstedet ditt per dag. Kanskje i stedet for standardskjemaer og felt, finnes det også animasjoner, ulike portaler, deler skrevet i Java, og så videre. Selv om du holder styr på alt det, er det kanskje en null dag i en av applikasjonene dine, og du har ingen mulighet til å forsvare deg selv.

I en situasjon som dette, hvis du har innflytelse og budsjett til å gjøre det, vil jeg anbefale at du investerer i en Web Application Firewall (WAF). En god WAF vil ha korrelasjonsregler som automatisk identifiserer og blokkerer HTML-strengene som oftest er forbundet med kodeinjeksjonsangrep. De kan også varsle deg når applikasjoner begynner å eksfiltrere data når de ikke skal eller gjør det i et uvanlig volum, og dermed bidra til å forsvare seg mot zero-day angrep og andre avanserte trusler. En WAF er ikke en sølvkule, men det er et uvurderlig verktøy for sikkerhetseksperter og nettstedeiere som håper å beskytte komplekse applikasjoner.

Det finnes også en rekke plugins som utgir seg for å forsvare seg mot XSS-angrep. Jeg anbefaler faktisk ikke disse. I stedet for å redusere risiko, representerer mange av disse pluginene bare enda en angrepsoverflate for en hacker å utnytte. Selv en av de mest kjente og mest brukte sikkerhetspluginene, Akismet, ble funnet å være sårbar for XSS-angrep i fjor. Når det gjelder å avlede XSS-angrep, ikke stol på halve tiltak. Utvikle de nødvendige ferdighetene og bruk passende verktøy for å holde nettstedet ditt trygt.

Andre praktiske bruksområder

Denne informasjonen kan være litt kompleks for de uinnvidde, men jeg ville hate at folk skulle bli motløse av den potensielle kompleksiteten til denne informasjonen. Skulle et XSS-angrep oppstå, kan du være sikker på at det å rydde opp i etterkant av en slik hendelse vil være langt mer komplisert enn å gjøre endringene på nettstedet ditt. Å rydde opp i omdømmekostnadene til nettstedet ditt (vanlige lesere vil flykte fra nettstedet ditt ganske enkelt) vil være et ekstra problem du ikke trenger å bekymre deg for.

Selv om du får noen andre til å håndtere utviklingen av nettstedet og sikkerheten for deg, gjør det du kan for i det minste å være i stand til å reagere på en nødsituasjon og vite hvor dine svake sider er. Å vite hvordan du sjekker systemet ditt vil være en viktig ferdighet i det lange løp og være grunnlaget for andre sikkerhetsemner og nettstedutviklingsprosjekter. Alt er sammenkoblet på nettet, og selv om XSS-angrep kan være en ting fra de siste årene (hvor usannsynlig dette enn er), vil det å kjenne inn og ut av nettstedet ditt aldri være utdatert.

Siste tanker

Internettsikkerhetslandskapet endrer seg hele tiden. Du kan aldri være helt sikker på hvordan et XSS-angrep kan se ut eller hvordan det kan bli brukt mot deg, men du skylder deg selv og leserne dine å sørge for at du gjør alt i din makt for å stoppe dem. Fortsett å informere deg selv om denne trusselen og sjekk regelmessig (jeg vil anbefale minst månedlig) for relevant utvikling i cybersikkerhetsverdenen.

Dette betyr heller ikke at du kan ignorere andre trusler. Offentlig nettverkstilgang krever fortsatt VPN-bruk for å være trygg. Du kan ikke overse sikkerheten til en datamaskin du bruker for å få tilgang til nettstedet ditt. Påloggingsinformasjonen må fortsatt endres ofte og være sikret mot brute force-angrep. XSS-angrep er brutale, men de er ikke den eneste trusselen å se opp for.

Det kan også være nødvendig for deg å dele denne informasjonen (eller til og med denne artikkelen) med dine kolleger og interesserte parter for å spre motstand mot denne typen angrep. Selv om du kanskje ikke er i stand til å gjøre for mye selv, hvis nok folk beskytter seg selv ordentlig, kan vi se en generell nedgang i denne typen angrep ettersom hackere prøver å finne ut en annen måte å tjene på dårlige internettbrukere.

Har du selv noen tanker om hvordan du kan se etter XSS-angrep og forsvare deg mot dem i fremtiden? Er det noen andre deteksjons- og fjerningsstrategier du selv bruker for å bekjempe denne trusselen? Er det noen verktøy du vil anbefale til dine medlesere? I så fall, legg igjen en kommentar nedenfor og fortsett denne viktige samtalen med dine medlesere.