Follow

Liebe -security Bubble,

hat jemand Argumente für oder gegen sog. Web Application Firewalls vor einer selbst entwickelten Web App?

Ich habe eine Anfrage für den Einsatz einer solchen und bin mir nicht sicher, ob das Bullshit oder vielleicht doch eine gute Idee ist?

Ich tendiere dazu das viele Geld lieber einem Auditor/Pentester zu geben und die Software ggf. zu fixen, statt eine zweite Software mit den Fehlern der ersten zu füttern.

@Qwertziop Naja, Pentester und Beseitigen von Lücken ist der nachhaltigere Weg. WAF fängt halt im Zweifelsfall ein paar "Standard-Angriffe" ab, die u.U. ja nicht zwingend gegen Deinen Code, sondern möglicherweise auch gegen third-party-Komponenten gerichtet sind, die Du einbindest (Application-/Web-Server, ...). Aus dieser Perspektive kann sowas das Leben etwas vereinfachen.

@Qwertziop @z428 ist das nicht auch eine betriebswirtschaftliche Frage? Auditor testet Version 1.0 und als Ergebnis gibt es dann Version 1.1. Und dann? Keine Weiterentwicklung mehr ist auch keine Lösung. Also bei Version 1.2 wieder Auditor und Ergebnis 1.3 ggf. kann da eine vorgeschaltete Lösung günstiger werden

@betamax65 @z428 Ach die Betriebswirtschaft ist mir erstmal egal… 😊
Aber im Ernst: Zum Audit ist jeweils ein zweiter Durchgang geplant. Das scheint Hand und Fuß zu haben, vorausgesetzt der Dienstleister weiß was er tut.

Ich soll mich nur zur WAF äußern und werde da in den nächsten Wochen etwas Text erzeugen.

Danke für Euren Input!

@Qwertziop So wie immer ein "kommt darauf an". Ein Pentester kann nicht alles finden, genausowenig kann eine WAF alles abhalten.Die Frage ist wie gut Du Deinen Entwicklern und den Secure Coding Guidelines und deren Einhaltung traust ;) Sowas wie SQL Injection sollte eine WAF abhalten können - wenn sie gut konfiguriert wird und das jemand macht der davon Ahnung hat. Einen Spearphishing-Angriff, auf Euch zugeschneidert, wird sie nicht abhalten können; die findet aber ggfs. auch der Pentester nicht

@Qwertziop Es reicht ja auch nicht die WAF zu haben, Du musst jemanden haben der sich darum kümmert _und_ das Wissen dafür hat. Also im Gegensatz zum Pentester keine einmalige Investition, dafür für alle Webserver die Du hast quasi immer nutzbar.

@rince Danke für die Antwort!
Der Entwickler bin im Wesentlichen ich, d.h. ich traue ihm jede Schweinerei zu. 😁

@Qwertziop Und wer soll die WAF betreiben, auch du? Keine gute Idee; Du bist biased

@rince Klar, das macht eine andere Abteilung.
Ich soll nur eine Bewertung abgeben und in Zukunft dabei helfen Regeln zu definieren. Doch ich werde, wenn überhaupt nur die Dokumentation liefern und keine Regel definieren, sonst sind wir wieder beim bias.

Es gibt übrigens sowieso eine Anforderung mind. alle 2-3 (?) Jahre zu Auditieren, das ist also nicht einmalig.

@Qwertziop @rince Sei froh, dass Du die WAF-Regeln nicht schreiben/konfigurieren musst. Das ist nämlich eine ganz furchtbare Arbeit.

@dentaku @rince Danke für den Hinweis, ich werde höllisch aufpassen, dass diese Aufgabe nicht bei mir landet.
PAL, war das Stichwort 😉

@Qwertziop @dentaku Okay, das hatte ich in dem SoD-Thema (biased) quasi mit eingebaut ;) aber ja, das ist nicht zu unterschätzen. Vorteil: Gilt für alle Webseiten hinter der WAF. Ncahteil: muss ständig angepasst und erweitert und geprüft werden.

@Qwertziop aus meiner Sicht ist das kein entweder oder. Eine gut konfigurierte und betreute WAF schützt halt auch teilweise vor Fehlern in der Entwicklung oder Standardangriffen. Ist extra Aufwand aber IMHO sinnvoll. Regelmässige audits und fixen von bugs ersetzt es aber nicht.

@Qwertziop Für Legacy-Anwendungen sicher ne gute Idee. Für z.B. eine Django- oder Rails-App meiner Meinung nach Schlangenöl. SQL-Injections passieren dank ORM quasi unmöglich, XSS ist durch eine strenge Content Security Policy viel besser unschädlich gemacht und die richtig fiesen Bugs (Logikfehler, Auth-Flaws, kapitte Permissionchecks) fängt es eh nicht.

@Qwertziop

Ich denke nicht, dass das Bullshit ist. Aber zum Anfang:

Was sind die Risiken, denen es zu begegnen gilt:
- Welche Angriffe werden erwartet?
- Wer sind die potentiellen Angreifer?
- Was sind die möglichen Schäden?

Wenn definiert ist, mit welchen Bedrohungen und Schäden gerechnet wird, dann kann eine Strategie dagegen entworfen werden, deren Teil auch eine Web Application Firewall sein könnte.

Software-Fehler gehören unabhängig davon behoben.

#1/2

@Qwertziop

Die weiteren Sicherheitsmaßnahmen sollten die Ausnutzung von Fehlern verzögern und sichtbar machen, die bei aller Sorgfalt nicht vorhergesehen wurden.

#2/2

@chrichri Danke für die Antwort!
Du beschreibst eine klassische Risikoanalyse, die wir schon gemacht haben. Aber welches Ergebnis der Risikoanalyse führt zum Einsatz einer WAF, d.h. welches konkrete Bedrohungsszenario kann durch eine WAF behandelt werden?
(Ein Argument, dass ich gefunden habe: die Web App ist nicht patchbar, trifft in meinem Fall aber nicht zu.)

@Qwertziop

Ich würde andersherum schauen: Bei jeder Bedrohung überlegen, ob einem Teil des Risikos durch die Funktionen einer WAF begegnet werden kann.

- Einschränkung der nutzbaren URLs (z.B. ausblenden von Admin-Seiten, die nur intern erreichbar sein sollen, Schutz gegen irgendwelche Strings, die nur dem Abklopfen auf mögliche Fehler der Applikation dienen können).
- Einschränkung der Parameter in der URL
- zusätzliches Protokoll
- Schutz vor zukünftigen Fehlern nach Update der Applikation

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!