Web Application Firewalls (WAF)

Transkript

1 Web Application Firewalls (WAF) Steffen Tröscher cirosec GmbH

2 Über mich Steffen Tröscher Seit 6 Jahren IT-Sicherheitsberater steffen.troescher@cirosec.de Schwerpunkte Sicherheitsüberprüfungen, Pen-Testing Coding Guidelines, Härtungsanweisungen, Konzeptionelle Analysen Trainer der Schulungen HE-Extrem Classic & Web

3 cirosec GmbH Beratungsunternehmen in Heilbronn derzeit 26 Mitarbeiter Fokus auf innovative IT-Sicherheit: Penetrationstests, Audits Schulungen konzeptionelle Analyse.. Angebot an Studenten: Durchführung Praktikum oder Thesis

4 Gliederung Warum WAFs? Funktionsweise von WAFs Marktübersicht Live-Demos: Vorstellung exemplarischer Schwachstellen Konfiguration einer Web Application Firewall

6 Schwachstellen - OWASP Top 10 A1 A2 Injection Cross Site Scripting A3 Broken Authentication & Session Management A4 Insecure Direct Object Reference A5 Cross Site Request Forgery (CSRF) A6 Security Misconfiguration A7 Failure to Restrict URL Access A8 Unvalidated Redirects and Forwards A9 Insecure Cryptographic Storage A10 Insufficient Transport Layer Protection

7 Sicherheit auf höheren Ebenen Neuen Gefahren kann nicht mit alten Technologien begegnet werden Bekämpfung der Ursachen Sichere Entwicklung Sichere Architektur Sicherer Betrieb Regelmäßige Prüfungen Bekämpfung der Auswirkungen Neue Technologien und Produkte

8 1. Bekämpfung der Ursachen

9 Bekämpfung der Ursachen Sicheres Programmieren Codierungsrichtlinien Toolgestützt durch Quellcode-Scanner Prüfung der Sicherheit Penetrationstests Toolgestützt durch Applikations-Scanner

10 Sicheres Programmieren

11 Codierungsrichtlinien für sichere Entwicklung Meist umfangreiche Werke Sollten mit den Entwicklern gemeinsam erarbeitet werden Sensibilisierung ist hier sehr wichtig z.b. Training + Workshop Unterstützung durch Werkzeuge bei der Entwicklung Quellcode-Scanner mit guter Erklärungskomponente

12 Beispiel-Themen für Richtlinien Grundlagen, Vertrauen, Server vs. Client Prüfung von Eingaben Bereinigung von Ausgaben Session-Management Umgang mit sensiblen Informationen Verhalten bei Fehlern Einsatz von Verschlüsselung Zugriff auf Datenbanken Administrationspfade

13 Sichere Programmierung ist keine vollständige Lösung Begrenzter Einfluss durch Ausführung von Fremdcode Plattformen, Portale und Backendsysteme Einbindung Programm-Bibliotheken Menschliches Fehlerpotential Die Programmierung von Filtern zur Überprüfung von Benutzereingaben ist sehr komplex und erfordert tiefes KnowHow

14 Prüfung der Sicherheit

15 Auditierung von Applikationen Während der Entwicklung Prüfwerkzeuge innerhalb Entwicklungsumgebung Fokus auf Quellcode Unterstützung für den Entwickler statt Audit Je früher umso geringere Kosten Während der QA bzw. Testphase Sicherheit ist ein Teil der Qualität Sicherheits-Tests zusammen mit den funktionalen Tests durchführen Vor Produktivgang oder im Betrieb Durch Sicherheitsexperten

16 Marktüberblick Web Scanner Sanctum AppScan Verkauf Watchfire Verkauf IBM Kavado ScanDo Verkauf Protegrity SPI-Dynamics WebInspect Verkauf HP Cenzic Hailstorm -> Hailstorm Web -> Hailstorm NT Objectives NTO Spider Acunetix Acunetix WVS

17 2. Bekämpfung der Auswirkungen

18 Bekämpfung der Auswirkungen Warum reicht Ursachenbekämpfung alleine nicht aus? Bereits genannt Fremdcode Menschliches Fehlerpotential Zusätzlich Minimierung des Windows of Exploitation Patchen zu kostenintensiv Security Principal: Defense in depth

19 Fremdcode

20 Fremdcode MyApp LoC BEA WebLogic* >10M LoC * estimate, based on line counts in JBoss, a competing open-source J2EE application server

21 Fremdcode MyApp LoC BEA WebLogic* >10M LoC

22 Fremdcode MyApp LoC BEA WebLogic* >10M LoC

23 Menschliches Fehlerpotential

24 Menschliches Fehlerpotential Hohe Komplexität der Umgebungen führen zu Schwachstellen Fehler sind trotz Schulungen, Richtlinien oder motivierten Mitarbeitern normal Beispiel: Input-Validierungs-Filter 1. Filter: Anti-Directory-Traversal: Der String../ wird aus allen Parametern entfernt 2. Filter: Anti-Cross-Site-Scripting: Malicious characters wie > oder < werden durch "." ersetzt Frage? In welcher Reihenfolge greifen die Filter? ;) Angriffsstring: >>/>>/>>/>>/

25 Minimierung des Windows of Exploitation

26 Window of Exploitation Wunschdenken : Bei Pentest wird Schwachstelle entdeckt Diese wird sofort durch Entwickler gepatcht Neue Version wird produktiv genommen Realität: Bei Pentest wird Schwachstelle entdeckt Schwachstellen wird in Bug-Tracking-System erfasst Entwickler brauchen mehrere Tage für eine Lösung Neue Version muss durch den Q&A Prozess Es vergehen mehrere Tage bis Wochen bis die Schwachstelle gepatcht ist

27 Security Principal: Defense in depth

28 Defense in depth Security Principal Defense in depth : Implementiere Sicherheit in allen möglichen Schichten (Netzwerk, Anwendung, Webserver, Datenbank, Betriebssysteme, ). Falls die Sicherheit in einer Schicht versagt, greifen die Mechanismen der anderen Schichten Analogie: Netzwerkbasierte Firewall gehärtetes DMZ System Web Applikation Firewall sichere Web Applikation

29 Positionierung von Sicherheitslösungen

30 Produkte für Sicherheit bei E-Business und Web-Services Browser Browser- Sicherheit HTTP- Filter Web- Server Host IPS / TOS / SOS Proxies für SQL, XML, Soap, Corba App. / DB Internet LAN

31 Produkte für Sicherheit bei E-Business und Web-Services Quaresso Promon F5 (Magnifire) Citrix (Teros) Barracuda (NC) DenyAll, AppSec Inc, Guardium Browser Browser- Sicherheit HTTP- Filter Web- Server Host IPS / TOS / SOS Proxies für SQL, XML, Soap, Corba App. / DB Internet Symantec (Platform) McAffee (Entercept) Cisco CSA (Okena) Argus, eeye, LAN

33 Schutzfunktionen einer WAF Vor bekannten Angriffen über Signaturen PHP-Würmer, Exploits, Vor unbekannten Angriffen über generische Mustererkennung (Zero Day Protection) SQL Injection, XSS, Buffer Overflows, Gezielte Konfiguration zur Absicherung bekannt gewordener Schwachstellen Falls Anpassung des Systems nicht möglich Kein Feedback/Support des Herstellers

34 Grenzen einer WAF Erkennung von Logikfehlern Z.B. falsch implementiertes Berechtigungsmodell Fehlerhafte Implementierung von Sicherheit auf Client Seite Z.B. Berechtigungsmodell wird in JavaScript geprüft Ausnutzung von Browserschwachstellen Z.B. Clickjacking

35 Funktionsweise einer WAF Erzwingt konformes HTTP (RFCs) Normalisierung d5opx;ðóge]ì ³óâ= [ZÜ¾ç Ù Vð ' <½ #Ôm]ëæoª5Zòˆ!0^Ý kê ØmtÈ œìn k»a êü Ýë;u ³7JMµ4[ø Èò¾ø má¼ %2E%2E%2Fpartners%2Fe %2F%7Efinance%2Frec%2F %2Fhomepage%2Findex%2 /partners/ /finance/rec/ /homepage/index/ SSL entschlüsseln Sonderzeichen wandeln

36 Funktionsweise einer WAF Betrachtungsebene WAF arbeitet auf Ebene HTTP/HTML Im Kontext der Applikation Wichtige Abgrenzung zu IDS/IPS! Extrahieren von URLs Extrahieren von Parametern Für GET und POST-Parameter Cookies sind z.b. Sonderform der POST- Parameter Anwendung von White- und Blacklisting Ausgabefilterung

37 Kontrolle von Parametern Whitelisting Beschreibung gültiger Wertebereiche Blacklisting Anwendung von Signaturen und Mustererkennung Schutz von Session Daten und kontextabhängigen Daten Individuell je Parameter konfigurierbar Ggf. Ausnahmen für einzelne Prüfungen bei bestimmten Parametern (bei False Positives)

38 Kontrolle von URLs Zugriff wird nur auf URLs gestattet, die zur Applikation gehören Duck.htm Pluto.htm Repl.cfg fbck.php fbck.php.bak Tassen Teller Besteck /CGI /Admin /Produkte /Services /Old Home

39 Ein Ansatz: Whitelisting Beschreibung gültiger Wertebereiche für alle Eingaben (URLs und Parameter) Höchste Sicherheit Nicht immer bis ins letzte Detail umsetzbar Erstellung der Whitelist manuell oder über Lernmodus

40 Whitelisting: Regelbasierte Policy Typischerweise Definition gültiger Dateiendungen und Datentypen je Bereich Gezielte Vorgabe von erlaubten Zeichen / Längen für spezifische Parameter Nur für wenige, kritische Parameter Bei bekannten Schwachstellen

41 Whitelisting: Regelbasierte Policy Gültige URLs und Parameter werden über Wildcards oder reguläre Ausdrücke beschrieben Einfaches Beispiel: zugelassen sind *.html, *.gif und *.css alle Parameter maximal 256 Zeichen plus Prüfung gegen Blacklisten plus einzelne Ausnahmen

42 Whitelisting: Regelbasierte Policy Gültige URLs und Parameter werden über Wildcards oder reguläre Ausdrücke beschrieben Einfaches Beispiel: zugelassen sind *.html, *.gif und *.css alle Parameter maximal 256 Zeichen plus Prüfung gegen Blacklisten plus einzelne Ausnahmen

43 Whitelisting: Regelbasierte Policy Policy-Grundsätze können vorgegeben werden (z.b. durch IT-Security) Flexibel bei Änderungen der Applikation Kompakt und nachvollziehbar (wichtig bei Reviews)

44 Whitelisting: Statisches Lernen WAF erstellt einmalig Policy aus gültigen URLs und Parametern Lernen mittels Live Traffic Trusted IP Crawler Ausnahmen für Blacklists werden gelernt Nach Beendigung des Lernens wird Policy scharf geschaltet

45 Whitelisting: Statisches Lernen Ergibt sehr genaue Beschreibung der Applikationsstruktur Gutes Ergebnis für Applikationen mit statischem Inhalt und definierten Release- Zyklen (z.b. Online Banking, SAP) Einzige Möglichkeit, um z.b. auch SAP WAS URL-Prefix Services zu begrenzen Lernphase erfordert vollständiges Testen Kaum einsetzbar bei Applikationen mit häufigen Änderungen (z.b. per CMS generierte Website)

46 Dynamische Statusverfolgung ( dynamisches Lernen ) Zur Laufzeit Analyse des HTML-Quelltextes und Extrahieren von gültigen Hyperlinks ( A HREF ) gültige Formularauswahlen (Check Boxen, Radio Buttons Session Informationen (Hidden Fields, Cookies) Findet je Benutzer statt! Speicherung der gelernten Informationen im RAM der WAF oder in verschlüsseltem Cookie

47 Dynamische Statusverfolgung Verfolgen jeder einzelnen Benutzersession Analyse der abgefragten HTML-Seiten Extraktion aller möglichen Links Session 1357 Links: /products/index.html /services/index.html /cgi/feedback.pl Session /services/s1.html 1357 Links: /products/index.html /services/s2.html /services/index.html /services/xy.html /cgi/feedback.pl GET / GET / Startseite: Seite: /services/index.html /start.html Startseite: /start.html Cookie: Session Seite: /services/index.html GET /services/index.html /msadc/msadcs.dll GET /services/index.html Anwender WAF Webserver

48 Verschlüsseln von URLs Verfolgen jeder einzelnen Benutzersession Analyse der abgefragten HTML-Seiten Verschlüsseln der enthaltenen Links Session 1357 Links: /products/index.html /services/index.html Session 1357 encrypted /cgi/feedback.pl Links: /1f2caa0842ef2288 /32db48fc2c32becd /44bce4862a4f3280 GET / GET / Startseite: Seite: /1f2caa0842ef2288 /start.html Startseite: /start.html Cookie: Cookie: Session Session Seite: /services/index.html GET /msadc/msadcs.dll /1f2caa0842ef2288 GET /services/index.html Anwender WAF Webserver

49 Randbedingungen zu dynamischer Statusvervolgung bzw. URL-Verschlüsselung Bookmarks und Suchmaschinenergebnisse sind nicht mehr gültig empfehlenswert für geschlossene Bereiche mit Login-Seite (z.b. Online Banking) Navigation sollte nicht auf Client-Seite realisiert sein (z.b. JavaScript, Ajax) In der Praxis daher oft kombiniert mit statischer Konfiguration

50 Whitelisting mit dynamischer Statusverfolgung Wo ist der sinnvollste Anwendungsfall? Bei einfachen Applikationen (selten) In kleinen Teilbereichen bei komplexen Applikationen Einsatz gegen bekannte Schwachstellen Schutz vor CSRF bei besonders kritischen oder verwundbaren Teilen, z.b. ungefilterter Download aus Auswahlliste Genereller Einsatz in der Praxis kaum durchführbar

51 Adpative Policyanpassung Anstelle eines einmaligen Lernprozesses steht kontinuierliches Lernen Policy wird ständig automatisch aktualisiert z.b. auch bei Änderungen in der Webanwendung Minimaler Betriebsaufwand Allerdings erschwerte Umsetzung in klassischen Staging-Umgebung Adaptiver Prozess funktioniert nur im produktiven Datenverkehr sinnvoll In der Testumgebung können keine Anpassungen gelernt werden (Daten nicht aussagekräftig)

52 Whitelisting: Flows Verfolgung des Benutzers auf seinem Weg durch die Applikation Einsatz für kritische Bereiche Genereller Einsatz zu komplex Falscher Parameter! Seite A Seite B Seite C

53 Zusätzlicher Ansatz: Blacklisting (Angriffsmuster) vom Hersteller gepflegt/aktualisiert offengelegt oder proprietär editier- und erweiterbar Korrelation mehrerer Events ( Scoring )

54 Blacklisting (Angriffsmuster) Sind oft generisch, d.h. viele neue Angriffe werden ohne Aktualisierung erkannt Beispiel: Aktualisierung der SQL-Injection Blacklist nur bei Änderung des SQL-Standards Aktualisierung bei neuen Angriffsklassen Von zentraler Management Instanz automatisch manuell mit Staging/Approval Prozess

55 Blacklisting: Fehlerbehandlung Log Analyse Interner Logviewer hilfreich Filterfunktionen Eindeutige Error Tracking IDs Möglichkeit zu One Click Refinements

56 Whitelist und Blacklist im Vergleich Schutz Whitelist Blacklist Konfigurationsaufwand

57 Whitelist und Blacklist im Vergleich Fazit: Whitelisting bietet höchstmöglichen Schutz, ist aber sehr aufwändig zu konfigurieren In der Praxis solider Basisschutz aus: Blacklisting Generisches Whitelisting Ggf. Ergänzung durch spezifisches Whitelisting über dynamische Statusverfolgung oder Flows in kritischen Bereichen

58 Filtern von Status- und Fehlerseiten Server-Banner Fehlerseiten von Applikations- oder Datenbankservern

59 Filterung sensitiver Daten z.b. Kreditkartendaten Hyperlinks zu Administrationsoberflächen oder internen Modulen (falls Applikation keine Konfiguration zulässt) Beliebige Content-Umschreibung

60 Schutz von Cookies Cookies werden verschlüsselt Set-Cookie: CartNr bd53fa224c Set-Cookie: CartNr Cookie: CartNr 128 WAF

61 Denial Of Service Bandbreitenlimitierung für einzelne URLs Beispiel 1: normal erreichbar limitierte Request-Anzahl pro Sekunde limitierte Bandbreite Beispiel 2: Ein einzelner User kann nur eine begrenzte Anzahl an Requests/Sekunde anfordern Performance für die Allgemeinheit ist aber unbeeinflusst

62 Denial Of Service Bandbreitenlimitierung für einzelne URLs Beispiel 1: normal erreichbar limitierte Request-Anzahl pro Sekunde limitierte Bandbreite Beispiel 2: Ein einzelner User kann nur eine begrenzte Anzahl an Requests/Sekunde anfordern Performance für die Allgemeinheit ist aber unbeeinflusst

63 Aktivierung der Security Policy Passiver Modus Anwendung der Security Policy Logging von Sicherheitsvorfällen Aber kein aktives Blockieren Ideal für die ersten Stunden/Tage der Inbetriebnahme Eventuelle False Positives sind kein Problem Besonders wichtig, wenn produktive Anwendung nachträglich mit WAF-Schutz versehen wird

64 Praktische Aspekte beim WAF-Einsatz Bisheriger Deployment-Prozess muß angepasst werden Tests mit vorgeschaltener WAF Kommunikation zwischen Anwendungsentwicklung und WAF-Betrieb erforderlich Deployment zunächst in Testumgebung Dort Policy-Erstellung / -Anpassung Kopieren der fertigen Policy auf das Produktivsystem Testsystem einplanen

65 Trends in der WAF-Technologie Die WAF-Produkte nähern sich an Funktionalitäten werden abgeschaut Kombination mit Funktionalitäten der Application Delivery Loadbalancing Authentication/Authorization Caching Compression TCP Optimization SSL Offloading SSL VPN

66 Trends in der WAF-Technologie Meist Hardware Appliance Seltener Software Lösung oder Soft Appliance Integration als Reverse Proxy Sehr selten im Bridge Mode Ablösung heterogener Reverse Proxy Strukturen

67 Schutzwirkung Alle nachfolgend erwähnten Produkte bieten hohen Schutz gegen die genannten Angriffe Keine schlechten oder guten WAFs im Sinne der Schutzwirkung Aber unterschiedliche Philosophien und Ansätze, die indirekt Einfluss auf die Sicherheit haben

68 percentage Schutzwirkung Beispiel: Erkennung von XSS-Angriffen Blocked XSS-Pattern mod_security Barracuda F5 Imperva Visonys WAF Quelle der Angriffsmuster:

69 Und die Performance? Wieviele Backendserver schützen Sie? Alle Hersteller bieten Modelle unterschiedlicher Leistungsklasse bis über transactions/second (!) Gigabit Durchsatz SSL-Beschleuniger (auch mit HSM) Performance ist selten ein Problem!

70 Integration als Reverse Proxy Single Homed Webserver WAF Internet LAN

71 Integration als Reverse Proxy Dual Homed Webserver WAF Internet LAN

72 Integration als Reverse Proxy Dual Homed typisch in neu aufgebauter Umgebung ansonsten Netzwerk-Reorganisation erforderlich sehr hohe Sicherheit Single Homed typisch in vorhandener Umgebung Integration durch DNS-Änderung oder Einsatz von NAT Nicht-HTTP Datenverkehr fließt am System vorbei

73 Integration als Reverse Proxy Randbedingungen IP des Benutzers auf dem Webserver nicht mehr sichtbar Weiterleitung als Header Access Logs direkt auf der WAF generieren Transparent Proxy (WAF muss Default-Gateway sein) Absolute Links dürfen nicht auf Backend- Systeme zeigen Umschreibung von Links über die WAF (URL-Rewriting)

74 Integration als Bridge Keine TCP-Terminierung Transparente Bridge Applikations-IPS, Layer2-WAF HTTP/S-Verbindung Benutzer WAF Webserver

75 Integration als Bridge Keinerlei IP-, Netzwerk oder DNS-Änderungen erforderlich Daten werden nicht verändert (keine TCP- Terminierung) Nicht inspizierter Traffic passiert ungehindert Einfaches Deployment und Rollback Je nach Topologie mehrere WAF-Module erforderlich Keine Zusatzfunktionen, die den Content beeinflussen (Rewriting, Loadbalancing, Compression, )

76 SSL-Terminierung Filterung nur unverschlüsselt möglich SSL-Terminierung bei Reverse Proxy Transparente SSL-Analyse bei Bridge SSL-Schlüssel und Zertifikate müssen unverschlüsselt vorliegen (Base64 codiert) Bei Einsatz eines Hardware Security Modules (HSM) muss dieses von der WAF unterstützt werden

77 Hardware Security Module (HSM) Entkopplung der SSL-Behandlung von Webserver, Reverse Proxy oder WAF Besonders gesicherte Appliances Zugang nur mit starker Authentisierung oder sogar Vier-Augen-Prinzip Sichere Speicherung von SSL-Keys Key verlässt nie das HSM Sichere und effiziente Ausführung von kryptographischen Operationen SSL-Beschleunigung

78 Weitere Protokolle SOAP / XML im B2B-Umfeld Viele Angriffe gegen Webapplikationen existieren auch bei Webservices Für die WAF SOAP/XML zunächst nur normaler HTTP-Request Spezielle Module, die XML oder SOAP analysieren Alternativ native XML-Firewalls Wichtige Unterscheidung: Fokus bei WAF auf Applikationssicherheit, nicht Sicherheit durch XML-Authentisierung, SAML oder Authorisierung

79 Abgrenzung WAF gg. XML-Firewall XML-Firewalls bieten klassische Sicherheit: Verschlüsselung Authentisierung/Authorisierung WS-Security 1.0/1.1 SAML AAA XSLT-Transformationen Oft aber nur rudimentärer Schutz gegenüber Angriffen auf XML-Ebene

81 Marktentwicklung Sanctum Magnifire Verkauf Verkauf Watchfire F5 NetContinuum Seclutions Visonys Verkauf Barracuda Verkauf Phion Stratum 8 Teros KaVaDo Verkauf Verkauf Citrix Protegrity WebCohort Imperva DenyAll Reactivity Verkauf Breach / ModSecurity Cisco Art Of Defence Verkauf

82 Hersteller und Produkte (alphabetisch) Barracuda Web Application Firewall Cisco ACE Web Application Firewall Citrix Application Firewall DenyAll rweb F5 ASM Imperva SecureSphere Phion Airlock Protegrity Defiance TMS

84 Live-Demos Vorstellung exemplarischer Schwachstellen

85 Gliederung Vorstellung exemplarischer Schwachstellen Theorie und Live Demonstrationen Alte Bekannte Cross-Site-Scripting File-Inclusion-Schwachstelle Neue Schwachstellen Blind-SQL-Injection Logische Fehler

87 Cross-Site Scripting (XSS) Ausführung von bösartigem Code innerhalb des Browser des Opfers Opfer ist immer der Client(-Browser) Die eigentliche Schwachstelle liegt jedoch innerhalb der Webanwendung

88 Cross-Site Scripting (XSS) Nicht Persistentes Cross-Site Scripting 5) Ausführung des Schadcodes im Browser 6) Cookie an Angreifer 1) HTML-Mail mit Link Opfer 4) Übermittlung des Schadcodes 2) Aufruf des präparierten Links Angreifer 3) Verarbeitung des präparierten Links Webanwendung mit XSS Schwachstelle

89 Cross-Site Scripting (XSS) Demonstration

90 File-Inclusion-Schwachstelle File-Inclusion durch die Applikationslogik Beispiel: Gedachte Funktionalität: Manipulierte Funktionalität:

91 File-Inclusion-Schwachstelle File-Inclusion durch die Applikationslogik Beispiel: Gedachte Funktionalität: Manipulierte Funktionalität:

92 File-Inclusion- Schwachstelle Demonstration

94 Normale SQL-Injection SELECT author,title,isbn,publisher FROM books WHERE title LIKE '%Begriff%' ' UNION SELECT SELECT null,null,password,username name,creditcardno,null,null FROM cirobank.users-- customers-- /search.asp?query=' UNION SQL-Abfrage Internet Firewall Web-Server Firewall DB-Server Angreifer Antwortseite Ergebnis der Abfrage

95 Normale SQL-Injection

96 Blind-SQL-Injection Obwohl eine Anwendung für SQL-Injection anfällig ist, wird oftmals das Ergebnis nicht direkt in der Antwortseite angezeigt werden Fehlermeldungen häufig unterdrückt Somit können Daten nicht über die Anwendungslogik oder Fehlermeldungen gewonnen werden Die Schwachstelle kann aber blind ausgenutzt werden

97 Blind-SQL-Injection Blindes Finden von SQL-Injection- Schwachstellen Idee: Einschleusen einer wahren (TRUE) und einer unwahren (FALSE) Aussage Die Antworten unterscheiden sich jeweils

98 Blind-SQL- Injection Demonstration - manuell

99 Blind-SQL-Injection Blindes Ausnutzen von SQL-Injection- Schwachstellen Ziel: Systematisches Erraten des aktuellen Datenbankbenutzers minizon Idee: Den Namen Buchstabe für Buchstabe erraten

100 Blind-SQL-Injection unwahre Aussagen: ' SUBSTR((SELECT user FROM dual),1,1)='a';-- ' SUBSTR((SELECT user FROM dual),1,1)='b';-- ' SUBSTR((SELECT user FROM dual),1,1)='c';-- so lange bis wahre Aussage: ' SUBSTR((SELECT user FROM dual),1,1)='m';--

101 Blind-SQL-Injection Iteration über alle Stellen ' and SUBSTR((SELECT user FROM dual),1,1)='m';-- ' and SUBSTR((SELECT user FROM dual),2,1)='i';-- ' and SUBSTR((SELECT user FROM dual),3,1)='n';-- ' and SUBSTR((SELECT user FROM dual),4,1)='i';-- ' and SUBSTR((SELECT user FROM dual),5,1)='z';-- ' and SUBSTR((SELECT user FROM dual),6,1)='o';-- ' and SUBSTR((SELECT user FROM dual),7,1)='n';--

102 Blind-SQL- Injection Demonstration

103 Logischer Fehler Anwendungsparameter bestimmt Kontext, in dem Anwendung verwendet wird Nach Anmeldung an Anwendung: cid ist Base64 codiert: dxnlcl9pzd0y Base64_decode() user_id=2 Manipulation des Parameters: user_id=1 Base64_encode() dxnlcl9pzd0x

104 Logischer Fehler Demonstration

105 Live-Demos Konfiguration einer Web Application Firewall

106 Danke für Ihre Aufmerksamkeit!