Web Application Security und der Einsatz von Web Application Firewalls

Transkript

1 Web Application Security und der Einsatz von Web Application Firewalls Philipp Etschel, BSc opennetworks.at fhstp.ac.at

2 2 Agenda: Warum überhaupt eine WAF einsetzen? Funktionsweise einer WAF Welche Web- Technologien kommen in Frage Ändern der Source vs. Einsatz einer WAF OWASP Top Ten Gegen welche schützt mich eine WAF wirklich. Absichern einer Applikation mittels Phions Airlock

3 3 Warum überhaupt eine WAF einsetzen?

4 4 Fakt: Moderne Webapplikationen sind auf mehrere Schichten verteilt

5 5 Resultat(1): Jede Komponente ist verwundbar / kann Bugs aufweisen OWASP CWE listet 800 Vulnerabilities Vulnerability Scanning testet nur gegen einen Snapshot Bug muss immer noch behoben werden Was passiert wenn sich die Applikation ändert? FW/IDS/IPS können keinen User State erkennen

6 6 Resultat(2): Die geläufigsten Vulnerabilities beruhen auf fehlerhafter Input Validierung SQL Injection Cross Side Scripting (XSS) LDAP Injection XML Injection Xpath Injection Command Injection Und eine ganze Menge mehr

7 7 Lösung: Vorgelagerte Security Schnelles Patchen nach bekanntwerden von Schwächen in der Applikation ist möglich Absicherung von Applikationen mit denen sich niemand mehr auskennt Für Provider deren Kunden immer noch darauf bestehen Register_Globals zu verwenden Zentraler Einstiegspunkt ins Backend Vorgeschrieben z.b. durch den Payment Industry Standart

8 8 Nutzen einer WAF Nutzen einer WAF Gering Mittel Hoch Voller Zugriff auf Source und Entwickler Viel selbst entwickelt, wenig eingekauft Viel eingekauft, kein Produkt Sourcecode Applikation als Blackbox Voll Teilweise Wenig Gar nicht Zugriff auf Applikation

9 9 Wie funktioniert eine WAF?

10 10 WAF - Funktionsweise Implementiert als vorgelagerte BOX Reverse Proxy Eigentliche Applikation bleibt unberührt Filterung des Traffics auf Anwendungsebene Filterung erfolgt mittels eines Regelwerkes Regular Expressions Je nach Hersteller unterschiedliche Zusatzfeatures Virenscanner Authentifizierung SSL VPN etc. Konfiguration erfolgt über ein Webinterface

11 11 WAF als Reverse Proxy

12 12 Airlock Multi Stage Filter 1 Network Level Filter Self-controlled 2 SSL Termination Self-controlled 3 Protocol Validation and Rebuilding Self-controlled 4 Character Encoding und Unicode Validation Self-controlled 5 Cookie Protection Self-controlled 6 Request Validation Customizable 7 Attack Blocking Customizable 8 URL Encryption Self-controlled 9 Smart Form Protection Self-controlled 10 Response Content Filter and Rewriting Customizable

13 13 Request Validation & Attack Blocking Request Validation Attack Blocking HTTP Request White List Rules Matches one or more Black List Rules Does not violate any Alert Block Alert Block

14 14 1. White List Filter HTTP Filter Rule Accept Only Source IP Address Requests From /24 URL Path Content Type HTTP Method Parameter Name Restriction Parameter Value Restriction Character Sets General Length Restrictions Access To Path -> / login.asp multipart/form-data, application/x-wwwform-urlencoded POST/GET Parameters -> UserID, Password... Values with 4-8 Characters and other Restrictions Charsets ISO , UTF-8 Max Path Length, Max Parameters etc.

15 15 2. Black List Filter Deny SQL Injection Cross Side Scripting Non- Printable Characters HTTP Response Splitting Path/Directory Traversal Illegal Unicode Sequences Selbst Definierte Regeln

16 16 Welche Webtechnologien können geschützt werden?

17 17 Absicherung diverser Technologien (1) Optimal: statisches HTML über HTTP Jede Abweichung davon bedeutet Einbußen in der Security, oder einen Mehraufwand bei der Konfiguration Filterung erfolgt Hauptsächlich auf HTTP Ebene Somit ist der Einsatz von nicht HTML konformen Technologien denkbar Jedoch in der Praxis unrealistisch, da die Inhalte z.b. mit SOAP/XML, AMF, JSON etc. übermittelt und somit nicht gefiltert werden können.

18 18 Abicherung diverser Technologien (2) Beispiel Rest Query: eviceid&$expand=admin,place URL Parameter können abgesichert werden Problem 1: Inhalte werden jedoch per XML oder JSON übermittelt, diese werden somit nicht gefiltert -> XSS wäre z.b. wieder möglich

19 19 Absicherung diverser Technologien (3) (Generelles) Problem 2: Da Requests Asynchron im Hintergrund übermittelt werden, kriegt der User ggf. von einem Fehler nichts mit -> es passiert einfach nichts!

20 20 Absicherung diverser Technologien (4) Zusammenfassung: Nur HTTP möglich Unabhängigkeit vom Web Application Server Am Besten HTML Einsetzen Problematisch bei HTML: Absolute Links Dynamisches Anlegen von Cookies Dynamisch generierte URL s Dynamisch generierte Forms + Form Inhalte

21 21 Code vs. WAF Womit ist Sicherheit besser umzusetzen?

22 22 Vergleich Coden vs. WAF Beispiel: Programmatische Absicherung einer Java Webapplikation gegen Cross Site Scripting Anmerkung: Die Programmiersprache ist an sich irrelevant, da die Schritte immer die selben sind

23 23 Filtern 1: White List Filterung final String inputstr = request.getparameter("input"); final String numericpattern = "^\\d+$"; if (!inputstr.matches(numericpattern)) { // invalid input, do something with error } Z.B. nur Numerische Werte zulassen Vorteil: sehr sicher Nachteil: Muss für jeden Parameter festgelegt werden -> Arbeitsintensiv

24 24 Filtern 2: Ersetzen / * regular expression that * tests for the existence of malicious characters * and replaces them with a space. */ final String filterpattern="[<>{}\\[\\];\\&]"; String inputstr = s.replaceall(filterpattern," "); Was ist jedoch wenn die Sonderzeichen dargestellt werden sollen, etwa in einem Forum?

25 25 Encoding (1) public static String encode(string data) { final StringBuffer buf = new StringBuffer(); final char[] chars = data.tochararray(); for (int i = 0; i < chars.length; i++) { buf.append("&#" + (int) chars[i]); } } return buf.tostring(); Vorteil: Sonderzeichen können dargestellt werden Nachteil: Kann leicht umgangen werden

26 26 Encoding (2) Filter können durch Encodierten Input umgangen werden z.b: >alert("hello XSS!");</script> 3%63%72%69%70%74%3e%61%6c%65%72%74%28%2 2%48%65%6c%6c%6f%20%58%53%53%21%22%29;%3 c/%73%63%72%69%70%74%3e

27 27 Encoding (3) Decodieren (Normalisieren) des Inputs bevor dieser Encodiert (Escaped) und wieder ausgegeben wird Durchgängiges Einhalten des Zeichensatzes in der Applikation (UTF-8, ISO , etc.) <HEAD> <META http-equiv="content-type" content="text/html; charset=iso "> </HEAD>

28 28 Vergleich: Coden vs. WAF Wie schaut das ganze nun mit einer WAF aus?

29 29 Encoding WAF (1) 1 Network Level Filter Self-controlled 2 SSL Termination Self-controlled 3 Protocol Validation and Rebuilding Self-controlled 4 Character Encoding und Unicode Validation Self-controlled 5 Cookie Protection Self-controlled 6 Request Validation Customizable 7 Attack Blocking Customizable 8 URL Encryption Self-controlled 9 Smart Form Protection Self-controlled 10 Response Content Filter and Rewriting Customizable

30 30 Encoding WAF (2) Normalisierung des Inputs erfolgt Transparent Character Sets können erzwungen werden Performance Faktor da sich die Applikation nicht mehr darum kümmern muss

31 31 Filtern WAF Erkennen von XSS Attacken erfolgt mittels des Blacklist Filters und Regular Expressions Per Default sind drei Regeln aktiv: XSS Rule for Values XSS Rule for Parameter Names XSS Rule for Paths Diese bieten per Default einen sehr guten Schutz Anmerkung: Andere Regeln müssen jedoch durchaus angepasst werden

32 32 Fazit Sicherer Source Code ist wichtig Ist jedoch immer nur so gut wie der Programmierer Niemand kann an alles denken Ist aufwändig umzusetzen Kostenfaktor Eine WAF kann die Applikation ergänzen Input ist schon Normalisiert bevor er die Applikation erreicht -> Das muss nicht mehr von dieser übernommen werden Schnelles Patchen von Bugs Die WAF schon bei der Programmierung einer Web Applikation mit einbeziehen Was kann mir diese abnehmen?

33 33 OWASP Top Ten Vulnerabilities Gegen welche schützt mich eine WAF wirklich?

34 34 OWASP Top Ten Cross Site Scripting Wie aus dem eben gezeigten Bsp. ersichtlich Input wird Normalisiert Default Regeln erreichen eine sehr gute Abdeckung Fazit: Guter Schutz per Default Regeln schlagen nur bei Attacken an

35 35 OWASP Top Ten Injection Flaws Ähnlich wie XSS jedoch gilt es folgendes zu beachten: Die WAF kann keine Rechte an der DB überwachen -> Hier muss Explizit nach Anfälligkeiten gesucht werden Wildcard Injection ist möglich Resultat DB kann durch sinnlose Anfragen überlastet werden Pararameter Pollution ist möglich Fazit: Defaultschutz vorhanden, dieser muss jedoch um eigene Regeln ergänzt werden

36 36 OWASP Top Ten - Malicious File Execution WAF kann Dateierweiterungen und Content Type überprüfen Das was das File wirklich enthält kann diese jedoch nicht erkennen File Upload ist generell problematisch Fazit: Virenscanner per ICAP einbinden Frameworks/Tools in der Applikation einsetzen

37 37 OWASP Top Ten - Insecure Direct Object Reference Guter Schutz gegen Path Traversal, aber Alle Ressourcen innerhalb einer Applikation bleiben auch mit einer WAF zugänglich Um dies zu Ändern gibt es zwei Möglichkeiten: URL Encryption verwenden Nachteil: Nicht immer User freundlich Pfade per Deny Rules einschränken Nachteil: Aufwändig Fazit: Wer sicher gehen will kommt um einen dieser beiden Schritte nicht herum

38 38 OWASP Top Ten -Cross Site Request Forgery Eine der gefährlichsten Attacken Hiergegen kann die WAF durch Session Based URL Encryption schützen somit kann der Angreifer die für die Session valide URL nicht schon im Vorfeld erraten. Eine untergeschobene URL wird somit ungültig. Fazit: Guter Schutz möglich, aber nicht per Default.

39 39 OWASP Top Ten - Information Leakage and Improper Error Handling Fehlermeldungen einer Applikation können von einer WAF sehr gut durch einen Response Body Rewrite abgefangen werden Z.B. mittels einer Regex ^.*Server Error.*$ -> <h1>meldung</h1> Fazit: Sehr gut anpassbar, aber da jede Applikation anders ist gibt es keinen Default

40 40 OWASP Top Ten - Encryption Broken Authentication and Session Management Insecure Cryptographic Storage Insecure Communications Sehr guter Schutz durch Cookie Store und zu schaltbare Verschlüsselung per SSL

41 41 OWASP Top Ten - Failure to Restrict URL Access Wie bei der Direct Object Reference gibt es die zwei Möglichkeiten, URL Encryption und Pfade per Regeln einschränken, mit allen Vor- und Nachteilen Fazit: Guter Schutz möglich, muss aber wieder händisch an die Applikation angepasst werden

42 42 Fazit Eine WAF bietet bis auf wenige Ausnahmen sehr guten Schutz gegen die genannten Attacken, aber jede Applikation ist anders und... somit gibt es keinen Schutz per Default, da jedes Regelwerk an diese angepasst werden muss.

43 43 Praxisbeispiel