Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03443.jsonl.gz/652

Password Leak Analyse
Marc Ruef
Der Einsatz von WAF (Web Application Firewall) hat sich in den letzten Jahren vervielfacht. Die vorgeschalteten Komponenten sind als Reverse-Proxies umfangreich darum bemüht, den Datenverkehr auf der Anwendungsschicht (Layer 7) zu untersuchen. Klassische Angriffstechniken auf Webapplikationen, zum Beispiel Cross Site Scripting und SQL-Injection, sollen damit erkannt werden.
Das Problem ist, dass ein Proxy nur mit erheblichem Aufwand die gewollte Sicherheit für eine geschützte Anwendung erreichen können. Da sie zudem nicht oder nur wenig über die interne Applikationslogik wissen, können sie gewisse Angriffstechniken gar nicht erkennen.
Um diese Einschränkung aufzuheben, wurde im Rahmen des OWASP AppSensor Project ein neuer Punkt namens RP2: External User Behavior hinzugefügt:
This information can be used by the application to contribute to its knowleage about a potential attacker. In some cases, the information could be detected by the application itself (e.g. XSS pattern black listing), but may be more effectively identified by the external device, or is not known to the application normally (e.g. requests for missing resources that the web server sees, but does not pass onto the application).
Hierbei kommt das sogenannte Request Header Tagging zum Tragen. Bei diesem wird den untersuchten HTTP-Requests zusätzliche Header-Zeilen hinzugefügt. In nachfolgendem Beispiel ist zu sehen, wie die Header
X-WAF-Events und
X-WAF-Score eingesetzt werden (Beispiel aus dem ModSecurity Blog):
GET /path/to/foo.php?test=1%27%20or%20%272%27=%272%27;-- HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:<ip-pii>) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 X-WAF-Events: TX: / 999935-Detects common comment types-WEB_ATTACK/INJECTION-ARGS:test, TX:999923-Detects JavaScript location/document property access and window access obfuscation-WEB_ATTACK/INJECTION-REQUEST_URI_RAW, TX:950001- WEB_ATTACK/SQL_INJECTION-ARGS:test X-WAF-Score: Total=48; sqli=2; xss= Connection: Keep-Alive
Die Webapplikation selbst kann nun diese Header auswerten und im Rahmen des eigenen Anwendungsstatus definieren, wie sie mit dem Zugriff umgehen will. Vielleicht sind gewisse Angriffsmuster nicht mehr eine Gefahr und damit als False-Positive zu werten. Die WAF fungiert somit nur noch als passiver Sensor, der bei der Datensammlung aus Auswertung behilflich ist. Die Logik im Umgang mit den potentiellen Angriffsversuchen wird durch die geschützte Applikation selber realisiert.
Durch diese neu eingeführte Modularität wird natürlich die Flexibilität erhöht. Ebenso kann die Performance und Skalierbarkeit besser ausfallen, da sich die Last der Analyse/Verarbeitung auf unterschiedliche Komponenten verteilen lassen.
Gleichzeitig besteht aber auch die Gefahr, dass der Datenaustausch zwischen WAF und Webapplikation nicht oder nur begrenzt funktioniert. Wichtige Daten und Alerts könnten aufgrund der erhöhten Komplexität unterwegs verloren gehen. Oder eventuell gelingt es einem Angreifer, den Transfer zwischen den beiden Komponenten zu stören. Derlei Probleme sind aber in individueller Weise von der genutzten Implementierung und dem Einsatzgebiet abhängig und werden sich erst in zukünftigen Penetration Tests zeigen.
Unsere Spezialisten kontaktieren Sie gern!
Marc Ruef
Marc Ruef
Marc Ruef
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv