Et loginforsøg fra en ukendt IP-adresse er ikke nødvendigvis et problem. Ti tusind forsøg mod samme loginformular på få minutter er noget andet. Hvordan beskytter WAF mod angreb i den situation? Den placerer et kontrollerende sikkerhedslag foran websitet eller webshoppen, vurderer hver forespørgsel og stopper de mønstre, der ligner misbrug, før de når WordPress, WooCommerce eller den bagvedliggende infrastruktur.
For virksomheder med digitale selvbetjeningsløsninger, kundedata og kritiske integrationer er en Web Application Firewall, forkortet WAF, ikke blot en teknisk tilføjelse. Den kan være forskellen mellem et afværget forsøg og en hændelse, der påvirker drift, omsætning, persondata og tillid. Men værdien afhænger af opsætningen, overvågningen og af, at WAF’en indgår i en større sikkerhedsindsats.
Hvordan beskytter WAF mod angreb i praksis?
En WAF analyserer HTTP- og HTTPS-trafikken mellem brugeren og webapplikationen. Hvor en traditionel netværksfirewall typisk kontrollerer porte, IP-adresser og netværksforbindelser, forholder en WAF sig til selve webtrafikken: URL’er, parametre, cookies, headers, formularfelter og anmodningernes hastighed.
Når en besøgende indtaster en adresse, lægger varer i kurven eller sender en formular, passerer anmodningen gennem WAF’en. Her kan den sammenligne indholdet med kendte angrebssignaturer, tekniske regler og adfærdsmønstre. En anmodning med mistænkelig kode i et søgefelt kan eksempelvis afvises, mens legitim trafik fortsætter til applikationen.
Det sker typisk gennem en kombination af faste regler og mere kontekstbaserede kontroller. Faste regler genkender kendte angrebsteknikker. Kontekstbaserede kontroller ser blandt andet på, om samme IP-adresse foretager usædvanligt mange kald, om en klient prøver at tilgå administrative stier, eller om en formular modtager data i et format, der ikke giver mening for funktionen.
En WAF kan sættes op i forskellige tilstande. I en observerende tilstand logger den mistænkelige trafik uden at blokere den. Det er ofte fornuftigt ved opstart, fordi reglerne kan justeres på baggrund af faktisk trafik. I en aktiv tilstand afviser den anmodninger med det samme. Valget er et spørgsmål om risiko: En webshop i højsæson har sjældent råd til unødige blokeringer, men har heller ikke råd til at lade automatiseret misbrug fortsætte.
Angrebstyper en WAF typisk kan begrænse
WAF’en er især relevant, fordi mange angreb rammer kendte svagheder i webapplikationer og deres grænseflader. Det gælder også løsninger, hvor kerneplatformen er opdateret, men hvor et tema, et plugin, en integration eller en specialudviklet funktion tilfører en ny angrebsflade.
Injection og manipulation af input
SQL injection opstår, når en angriber forsøger at få en applikation til at behandle indtastet data som databasekommandoer. En WAF kan genkende mange typiske mønstre i parametre og formularfelter og blokere dem, før de når databasen. Det samme gælder dele af forsøg på command injection, hvor angriberen prøver at få serveren til at udføre uønskede kommandoer.
Det er dog ikke en erstatning for sikker kode. Parameteriserede databasekald, streng validering af input og korrekt adgangsstyring er fortsat nødvendige. WAF’en reducerer risikoen, særligt når en ukendt sårbarhed opdages, men den kan ikke gøre usikker kode sikker af sig selv.
Cross-site scripting og misbrug af formularer
Ved cross-site scripting, også kaldet XSS, forsøger en angriber at indsætte scripts i eksempelvis kommentarfelter, søgninger eller brugerprofiler. Målet kan være at stjæle sessionsdata, manipulere indhold eller narre brugere til at udføre handlinger. En WAF kan filtrere kendte XSS-mønstre og stoppe mistænkelig input.
Formularer bliver også misbrugt til spam, scraping og automatiserede forespørgsler. Her kan regler for hastighed, geografisk oprindelse, user-agent og kendte automatiseringsmønstre begrænse belastningen. Det bør gøres med omtanke. En offentlig organisation eller international webshop kan have reelle brugere fra mange lande og med mange forskellige enheder.
Brute force mod login og API’er
WordPress-login, kundekonti og API-endpoints er hyppige mål for automatiserede loginforsøg. En WAF kan indføre rate limiting, så en enkelt kilde kun må foretage et bestemt antal forsøg inden for et tidsrum. Den kan også udfordre mistænkelig trafik eller blokere kendte ondsindede IP-adresser.
Dette mindsker risikoen for, at svage eller genbrugte adgangskoder bliver gættet. Den egentlige beskyttelse skal dog ligge flere steder: stærke adgangskoder, multifaktorautentificering, mindst mulige rettigheder og en proces for at lukke gamle brugeradgange er lige så væsentlige.
Forsøg på at udnytte kendte sårbarheder
Når en sårbarhed i et populært plugin, et CMS eller et bibliotek bliver offentlig kendt, går der ofte kort tid, før automatiserede bots begynder at lede efter ubeskyttede installationer. En WAF kan i mange tilfælde lægge et midlertidigt værn foran løsningen med en regel, der stopper det specifikke angrebsmønster.
Det giver tid til at teste og installere en sikkerhedsopdatering, men må aldrig blive en undskyldning for at udskyde den. Patch management er fortsat den varige løsning. Særligt ved integrationer skal man samtidig vurdere, om en opdatering ændrer API-adfærd eller påvirker forretningskritiske arbejdsgange.
WAF er ikke det samme som DDoS-beskyttelse
Det er almindeligt at omtale WAF som DDoS-beskyttelse, men de to ting er ikke identiske. En WAF kan reducere applikationsbaserede angreb, hvor mange tilsyneladende normale forespørgsler forsøger at overbelaste eksempelvis søgning, login eller en tung API-funktion. Rate limiting og caching kan gøre en mærkbar forskel her.
Et stort volumetrisk DDoS-angreb, der fylder internetforbindelsen med massiv netværkstrafik, kræver derimod kapacitet og filtrering tidligere i infrastrukturen. Det håndteres ofte af hostingmiljøet eller en særskilt netværksbeskyttelse. Den rigtige løsning afhænger af trafikmængde, eksponering, forretningskritikalitet og hvilke dele af platformen der skal være tilgængelige under et angreb.
Falske positiver er en reel driftsopgave
Den mest restriktive WAF er ikke nødvendigvis den bedste. En regel kan fejlagtigt blokere en legitim kunde, en medarbejder, en betalingsudbyder eller et integrationskald. Det kaldes en falsk positiv, og det kan være direkte forretningsskadeligt, hvis checkout, sagsbehandling eller login rammes.
Derfor skal WAF-regler baseres på den konkrete løsning. API’er, admin-funktioner, uploadfelter og integrationer kræver ofte særskilte undtagelser eller mere præcise regler. En regel, der fungerer perfekt på et simpelt præsentationssite, kan være for grov på en webshop med ERP-integration, produktfeeds og kundespecifikke priser.
Logning er afgørende i den proces. Den skal vise, hvad der blev blokeret, hvilken regel der udløste blokeringen, og om trafikken faktisk var skadelig. Samtidig skal logdata behandles ansvarligt. IP-adresser og andre tekniske identifikatorer kan være personoplysninger, og opbevaring, adgang og databehandlerkæde skal derfor være afklaret i et GDPR-perspektiv.
WAF skal indgå i et samlet sikkerhedslag
En velfungerende WAF beskytter det lag, hvor brugere og systemer møder webapplikationen. Den kan ikke alene håndtere kompromitterede administratoradgange, fejlkonfigurerede servere, usikre integrationer eller manglende backup. Sikkerheden skal hænge sammen fra kode og adgangsstyring til drift, overvågning og beredskab.
For en WordPress- eller WooCommerce-løsning betyder det blandt andet løbende opdateringer, kontrolleret udvikling, sikker håndtering af udvidelser, backup med reelle gendannelsestests og overvågning af afvigelser. For integrationsbaserede platforme bør API-nøgler, adgangsrettigheder, fejlbeskeder og dataminimering indgå i samme vurdering.
Placeringen af WAF’en har også betydning for digital suverænitet. Hvis trafik, sikkerhedslogs eller brugerdata behandles uden for den ønskede EU-databehandlerkæde, kan det skabe nye compliance-spørgsmål. Derfor bør teknologivalget vurderes på mere end funktioner og pris. Det skal også passe til organisationens krav til dataansvar, dokumentation og flytbarhed.
Den praktiske start er at kortlægge de vigtigste angrebsflader: login, checkout, kontaktformularer, søgning, filuploads, API’er og administrative områder. Derefter bør WAF’en sættes op, testes mod den reelle trafik og følges i driften. Når sikkerhed bliver behandlet som en løbende disciplin frem for en engangsindstilling, bliver det lettere at beskytte både platformen og den forretning, den skal understøtte.
