\n<script>\n<![CDATA[\nCoughUpYourPreciousData();\n]]>\n<\/script><\/code><\/pre>\n\n Dette kan for eksempel f\u00f8re til at neste person som bes\u00f8ker siden sender en kopi av informasjonskapslene sine til en angriper.\n<\/p>\n
\n Du kan se at i dette eksemplet ser kodestrengen ovenfor ikke ut som noens navn. Serveren din vet ikke dette, men ved \u00e5 bruke noen f\u00e5 parametere kan du l\u00e6re det. Du kan for eksempel fortelle at feltet skal avvise spesialtegn, slik som ,() og ; (de er ikke spesielt n\u00f8dvendige i en kommentarseksjon). Du kan fortelle det feltet at en persons navn sannsynligvis ikke har tall i det. Hvis du er villig til \u00e5 v\u00e6re litt drakonisk, kan du fortelle det feltet \u00e5 avvise inndata som er mer enn femten tegn lange (eller du kan endre verdiene som du vil ha dem). \u00c5 ta disse trinnene vil drastisk begrense mengden skade en angriper kan gj\u00f8re med et bestemt felt.\n<\/p>\n
![\"\"](\"https:\/\/inform.click\/wp-content\/uploads\/2022\/11\/post-327507-638448ef92725.webp\")
<\/a><\/p>\n\n Selv med datavalidering kan det v\u00e6re skjemaer eller felt der du ikke realistisk kan begrense typen tegn som brukes, for eksempel i et kontaktskjema eller kommentarfelt. Det du kan gj\u00f8re er \u00e5 rense data. Denne prosessen gj\u00f8r det umulig for HTML \u00e5 bli utf\u00f8rt i et gitt felt, og konverterer alt som kan gjenkjennes som et stykke kj\u00f8rbar kode til ikke-kodende tegn. Som et eksempel vil en hyperkobling ikke vises der det ellers kan v\u00e6re en.\n<\/p>\n
\n Til slutt er det tilfeller der nettstedet ditt kan ende opp med \u00e5 vise data som er utrygge for brukere. La oss si at noen skriver en ondsinnet kommentar p\u00e5 en av sidene dine, som deretter blir indeksert av nettstedets s\u00f8kefunksjon. N\u00e5r en av brukerne dine utf\u00f8rer et s\u00f8k, kj\u00f8res den skadelige koden n\u00e5r nettleseren deres laster s\u00f8keresultatene. Dette forhindres av escape-data, som sikrer at n\u00e5r nettstedet ditt leverer data til en bruker, er den eneste koden som kj\u00f8rer koden du vil kj\u00f8re.\n<\/p>\n
\n For mer om datavalidering, rensing av data og unnslipping av data, har WordPress Codex en utmerket ressurs.<\/a> Den vil forklare begrepene ovenfor i detalj, samt gi flere eksempler som kan brukes universelt.\n<\/p>\n\n Andre metoder
\n<\/h4>\n
\n Store selskaper har st\u00f8rre nettsider; det er fakta. Kanskje tusenvis av mennesker bruker nettstedet ditt per dag. Kanskje i stedet for standardskjemaer og felt, finnes det ogs\u00e5 animasjoner, ulike portaler, deler skrevet i Java, og s\u00e5 videre. Selv om du holder styr p\u00e5 alt det, er det kanskje en null dag i en av applikasjonene dine, og du har ingen mulighet til \u00e5 forsvare deg selv.\n<\/p>\n
\n I en situasjon som dette, hvis du har innflytelse og budsjett til \u00e5 gj\u00f8re 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\u00e5 varsle deg n\u00e5r applikasjoner begynner \u00e5 eksfiltrere data n\u00e5r de ikke skal eller gj\u00f8r det i et uvanlig volum, og dermed bidra til \u00e5 forsvare seg mot zero-day angrep og andre avanserte trusler. En WAF er ikke en s\u00f8lvkule, men det er et uvurderlig verkt\u00f8y for sikkerhetseksperter og nettstedeiere som h\u00e5per \u00e5 beskytte komplekse applikasjoner.\n<\/p>\n
\n Det finnes ogs\u00e5 en rekke plugins som utgir seg for \u00e5 forsvare seg mot XSS-angrep. Jeg anbefaler faktisk ikke disse. I stedet for \u00e5 redusere risiko, representerer mange av disse pluginene bare enda en angrepsoverflate for en hacker \u00e5 utnytte. Selv en av de mest kjente og mest brukte sikkerhetspluginene, Akismet, ble funnet \u00e5 v\u00e6re s\u00e5rbar for XSS-angrep<\/a> i fjor. N\u00e5r det gjelder \u00e5 avlede XSS-angrep, ikke stol p\u00e5 halve tiltak. Utvikle de n\u00f8dvendige ferdighetene og bruk passende verkt\u00f8y for \u00e5 holde nettstedet ditt trygt.\n<\/p>\n\n Andre praktiske bruksomr\u00e5der
\n<\/h4>\n
\n Denne informasjonen kan v\u00e6re litt kompleks for de uinnvidde, men jeg ville hate at folk skulle bli motl\u00f8se av den potensielle kompleksiteten til denne informasjonen. Skulle et XSS-angrep oppst\u00e5, kan du v\u00e6re sikker p\u00e5 at det \u00e5 rydde opp i etterkant av en slik hendelse vil v\u00e6re langt mer komplisert enn \u00e5 gj\u00f8re endringene p\u00e5 nettstedet ditt. \u00c5 rydde opp i omd\u00f8mmekostnadene til nettstedet ditt (vanlige lesere vil flykte fra nettstedet ditt ganske enkelt) vil v\u00e6re et ekstra problem du ikke trenger \u00e5 bekymre deg for.\n<\/p>\n
\n Selv om du f\u00e5r noen andre til \u00e5 h\u00e5ndtere utviklingen av nettstedet og sikkerheten for deg, gj\u00f8r det du kan for i det minste \u00e5 v\u00e6re i stand til \u00e5 reagere p\u00e5 en n\u00f8dsituasjon og vite hvor dine svake sider er. \u00c5 vite hvordan du sjekker systemet ditt vil v\u00e6re en viktig ferdighet i det lange l\u00f8p og v\u00e6re grunnlaget for andre sikkerhetsemner og nettstedutviklingsprosjekter. Alt er sammenkoblet p\u00e5 nettet, og selv om XSS-angrep kan v\u00e6re en ting fra de siste \u00e5rene (hvor usannsynlig dette enn er), vil det \u00e5 kjenne inn og ut av nettstedet ditt aldri v\u00e6re utdatert.\n<\/p>\n
\n Siste tanker
\n<\/h4>\n
\n Internettsikkerhetslandskapet endrer seg hele tiden. Du kan aldri v\u00e6re helt sikker p\u00e5 hvordan et XSS-angrep kan se ut eller hvordan det kan bli brukt mot deg, men du skylder deg selv og leserne dine \u00e5 s\u00f8rge for at du gj\u00f8r alt i din makt for \u00e5 stoppe dem. Fortsett \u00e5 informere deg selv om denne trusselen og sjekk regelmessig (jeg vil anbefale minst m\u00e5nedlig) for relevant utvikling i cybersikkerhetsverdenen.\n<\/p>\n
\n Dette betyr heller ikke at du kan ignorere andre trusler. Offentlig nettverkstilgang krever fortsatt VPN-bruk for \u00e5 v\u00e6re trygg. Du kan ikke overse sikkerheten til en datamaskin du bruker for \u00e5 f\u00e5 tilgang til nettstedet ditt. P\u00e5loggingsinformasjonen m\u00e5 fortsatt endres ofte og v\u00e6re sikret mot brute force-angrep. XSS-angrep er brutale, men de er ikke den eneste trusselen \u00e5 se opp for.\n<\/p>\n
\n Det kan ogs\u00e5 v\u00e6re n\u00f8dvendig for deg \u00e5 dele denne informasjonen (eller til og med denne artikkelen) med dine kolleger og interesserte parter for \u00e5 spre motstand mot denne typen angrep. Selv om du kanskje ikke er i stand til \u00e5 gj\u00f8re for mye selv, hvis nok folk beskytter seg selv ordentlig, kan vi se en generell nedgang i denne typen angrep ettersom hackere pr\u00f8ver \u00e5 finne ut en annen m\u00e5te \u00e5 tjene p\u00e5 d\u00e5rlige internettbrukere.\n<\/p>\n
\n 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 \u00e5 bekjempe denne trusselen? Er det noen verkt\u00f8y du vil anbefale til dine medlesere? I s\u00e5 fall, legg igjen en kommentar nedenfor og fortsett denne viktige samtalen med dine medlesere.\n<\/p>\n<\/p>\n