Oft werden bei der Analyse der Web-Anwendung kritische Schwachstellen wie zum Beispiel SQL Injection (SQLi) oder Cross-Site-Scripting (XSS) gefunden. Im Anschluss stellt sich natürlich die Frage, wie kann man diese Schwachstellen beheben?
Die korrekte Antwort lautet selbstverständlich die Fehler im Quellcode der Anwendung beheben ergo die Anwendung patchen. Und das sollte schnellstmöglich passieren, um die Wahrscheinlichkeit eines erfolgreichen Angriffs zu minimieren. Doch leider ist es in der Realität so, dass zwischen der Entdeckung der Schwachstelle und dem Beheben schon mehrere Wochen vergehen können. Und gerade bei größeren Anwendungen ist man auf den Hersteller und seine Entwickler angewiesen.
Um die Zeit zu überbrücken, bis der Hersteller ein Patch raus gebracht hat, empfehlen wir den Einsatz einer Web Application Firewall (WAF). Es ist jedoch empfehlenswert die WAF auch nach der Installation des Patches weiter zu betrieben. Denn erstens hat man dann die Einrichtung hinter sich und zweitens können damit ganze Schwachstellenklassen, die auf einer fehlerhaften Eingabevalidierung beruhen, wirkungsvoll verhindert werden.
Wie funktioniert Naxsi?
Naxsi ist ein Open Source nginx-Modul, das regelbasiert die HTTP-Anfragen prüft und die böswilligen Anfragen blockiert. Naxsi wird dabei als ein Reverse-Proxy eingerichtet, dass die Client-Anfragen annimmt, prüft und dann die Anfrage entweder blockiert oder an den echten Webserver weiterleitet. Die Prüfregeln teilen sich in Blacklist und Whitelist auf, die jeweils global(MainRule) oder lokal(BasicRule) sein können. Eine Blacklist definiert einzelne Symbole oder Zeichenketten, die in der HTTP-Anfrage verboten sind. Eine Whitelist definiert wiederum die Ausnahme von der Sperrregel.
Dabei werden einzelnen Teile einer HTTP-Anfrage wie die HTTP-Methode, Header, URL oder Body auf verschiedene "böswillige" Zeichen geprüft. So lautet eine der Sperrregeln in naxsi_core.rules:
MainRule "str:;" "msg:semicolon" "mz:BODY|URL|ARGS" "s:$SQL:4,$XSS:8" id:1008;Mit dieser Regel(id:1008) wird die URL, die Argumente und das Body einer Anfrage auf das Vorhandensein vom Semikolon geprüft. Falls dieses Zeichen in der Anfrage gefunden wird, werden der Anfrage der inneren Bewertung für SQLi 4 Punkte addiert und 8 Punkte für XSS ("s:$SQL:4,$XSS:8").
Die Schwellwerte für die Blockieren von Anfragen werden in der Konfigurationsdatei naxsi.rules festgelegt:
## check rules
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;Damit wird eine Anfrage mit einem Semikolon in der URL automatisch geblockt, da der XSS-Schwellwert von 8 Punkten erreicht wurde. Der Angreifer wird dann auf entsprechend konfigurierte Location (DeniedUrl "/blocked";) umgeleitet, wo man eine Umleitung oder einen HTTP-Status (z.B. 404) setzen kann.
Wo ist der Haken?
An der Stelle soll jedoch nicht verschwiegen werden, dass eine Web Application Firewall ein Paar Nachteile mit sich bringt. Ein Nachteil ist, dass mit dem Update der Web-Anwendung ggf. auch die Regeln der WAF gepflegt werden müssen. Denn wenn sich mit dem Update die Parameter der Web-Anwendung ändern, dann müssen in WAF ggf. alle betroffenen Regeln entsprechend angepasst werden. Ein weiterer Nachteil einer WAF ist, dass eine WAF prinzipbedingt nicht alle Angriffe erkennen kann. So kann eine WAF zum Beispiel keine Manipulation der Sessionparameter erkennen, solange bei der Manipulation keine verbotenen Zeichen benutzt werden.
Zusammenfassung
So eine Web Application Firewall ist keine "silver bullet", mit der man die löchrige Web-Anwendung sorgenlos betreiben kann. Jedoch bietet eine Web Application Firewall aus unserer Sicht ein spürbares Plus an Sicherheit, die man vergleichsweise schnell erreichen kann. Ein Quick Win also.