Applikationsbrandväggar (WAF): En illusion av fullständig säkerhet?

Bakgrund

Applikationsbrandväggar (WAF) är en skyddsmekanism som blockerar skadlig trafik innan den når applikationen. Oftast, så implementeras detta som en proxy, där inkommande förfrågningar analyseras för att bestämma om de anses vara skadliga eller ej.

Även om det är ett effektivt sätt att stoppa skadlig effekt, kan de bidra med en falsk känsla av säkerhet ifall man förlitar sig för mycket på dem. I följande artikel så kommer vi undersöka WAF’s från perspektivet av en penetrationstestare, som allmänna problem och kringgående taktiker.

WAF-Implementationers påverkan under ett penetrationstest

WAF-implementationer brukar anses vara en penetrationstestares värsta fiende, eftersom de blockerar vanligt förekommande förfrågningar och trafik under en säkerhetutvärdering. Detta kan uppfattas som ett mindre besvär, men från perspektivet av en penetrationstestare är det här något som aktivt stoppar oss från att göra ett utförligt jobb.

Under en säkerhetsutvärdering är det viktigt att så mycket som möjligt täcks av utredningen. Med en WAF-implementation som är aktiv under utvärderingen blir vissa sårbarheter svåra att testa, vilket kan förhindra en säkerhetsexpert från att identifiera befintliga sårbarheter.

Även om en WAF kan blockera ett försök på en cross-site scripting (XSS) attack i ett användarkontrollerat fält, finns det en chans att applikationen inte rensar inmatningen korrekt. Det betyder, att ifall man lyckas kringgå brandväggens skydd, så är fortfarande en XSS attack möjlig att utför, något som förmodligen skulle identifieras om utvärderingen gjorde utan skyddet av en WAF.

Kringgå WAF-implementationer

Alla produkter, även de som stärker ens applikationssäkerhet, så kommer alltid angripare och forskare hitta problem och sätt att kringgå dem. En WAF är inget undantag till detta, speciellt eftersom de är så pass vanliga bland moderna webapplikationer.

Det är vanligt att göra undantag för interna nätverk i en WAF-implementation, för att säkerställa att interna användare eller tjänster inte stoppas felaktigt. Dock så kan problem uppstå om en angripare kan förfalska sin IP-adress, ofta på grund av misskonfigurationer eller felaktig hantering av HTTP ”headers”. Det kan utföras på olika sätt, men oftast genom att lägga till en header med en IP adress, som senast när den analyserar, kommer betraktas som en intern resurs.

Utöver så har många WAF-implementationer en begränsning i hur stora HTTP förfrågningar de kan analysera. Det är rekommenderat att behandla förfrågningar som överskrider denna satta gräns som skadliga, men det är inte alltid fallet. En angripare kan då, genom att skicka en förfrågan som överskrider gränsen helt kringgå WAF:en.

Vanliga kringgående metoder som dessa kan åtgärdas genom att ha en säker och robust konfiguration. Mera avancerade kringgåenden är dock svårare att åtgärda, och därför behöver applikationens säkerhet vara stark utan hjälp av en WAF.

Skyddar inte mot alla sårbarheter

En WAF är konfigurerad för att stoppa förfrågningar och trafik som anses vara skadliga, men den tar ej hänsyn sårbarheter som utnyttjar normala förfrågningar.

Attacker som utnyttjar applikationens grundläggande logik involverar oftast inga förfrågningar som anses vara skadliga; de manipulerar istället applikationens underliggande system för att utföra oönskade handlingar. Detta kan vara saker som att skicka förfrågningar i fel ordning, upprepa förfrågningar eller lösa in presentkort, allt något som kommer ses som ej skadliga av en WAF. Dessa kommer därför ej stoppas.

Sårbarheter relaterade till auktorisering är ett till område som en WAF inte kan skydde en emot. Auktoriseringsproblem utnyttjar underliggande felkonfigurationer, specifikt brister i åtkomstkontroll, något som en WAF inte kommer ta hänsyn till. Den kommer enbart se förfrågningarna som en giltig användare som har åtkomst till en resurs som de ska ha tillgång till och släppa igenom förfrågan.

Om du är fortsatt nyfiken på sårbarheter som påverkar din applikationslogik, så har vi en artikel som täcker det ämnet: Business logic attacks: The silent future of cyberattacks.

Problemet med egna WAF-implementationer

Många av de vanliga WAF produkterna tillhandahålls av stora externa leverantörer, men ibland kan mindre tjänster eller applikationer ha en egen WAF-implementering. För att WAF-implementationen ska fungera effektivt och utan problem så är det viktigt med en korrekt konfiguration, vilket är extremt viktigt för egna implantationer. I de flesta fall fungerar tidigare nämnda kringgåendemetoder, samtidigt som det går att manipulera implementationen att utföra oönskade handlingar.

Majoriteten av dessa problem uppstår när den egna WAF-implementationen används i samband med en annan HTTP proxyserver. Proxyservern i fråga kan vara allt från lastningsbalanserare till cachingtjänster.

Under en säkerhetsutvärdering upptäcktes det att den egna WAF-implementationen betedde sig konstigt när den kommunicerade med applikationens lastbalanserare. IP-adresserna som blev blockerade stämde ej överens med vår testare, och sakta slutade fler funktioner av sida fungera. En undersökning visade att WAF-implementationen blockerade samt spärrade lastbalanserarna istället för förfrågningarnas egentliga avsändare.

Avslut

En väl implementerad WAF-lösning fyller en viktig roll inom webapplikations säkerhetens ekosystem, men bör ej ses som den magiska lösningen till alla säkerhetsproblem. Applikations underliggande säkerhet behöver vara robust tillsammans med WAF-implementationen och andra externa skyddsmekanismer för att vara effektiv.

För att säkerställa detta, regelbundna säkerhetsutvärderingar av applikationen, utan WAF-implementationens skydd bör utföras. I slutändan kommer detta säkerställa att även om WAF-implementationen kringgås, kommer applikationen hantera skadliga förfrågningar korrekt.

Outpost24’s PtaaS är ett exempel på hur PTaaS kan se ut i praktiken: kombinationen av djupgående manuell pen-testning och kontinuerlig scanning ger både bredd och precision.

Säkerhet är inte längre en punktinsats en gång om året – den är en pågående process. Och med PTaaS blir det möjligt att göra den både effektiv och anpassad till hur modern utveckling och Teknik faktiskt fungerar.

Vi hjälper dig gärna!