Über mich
• Steffen Tröscher
– Seit 6 Jahren IT-Sicherheitsberater
• Schwerpunkte
– Sicherheitsüberprüfungen, Pen-Testing
– Coding Guidelines, Härtungsanweisungen, …
– Konzeptionelle Analysen
– Trainer der Schulungen HE-Extrem Classic & Web
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
Gliederung
• Warum WAFs?
• Funktionsweise von WAFs
• Marktübersicht
• Live-Demos:
– Vorstellung exemplarischer Schwachstellen
– Konfiguration einer Web Application Firewall
Gliederung
• Warum WAFs?
• Funktionsweise von WAFs
• Marktübersicht
• Live-Demos:
– Vorstellung exemplarischer Schwachstellen
– Konfiguration einer Web Application Firewall
Schwachstellen - OWASP Top 10
A1 Injection
A2 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 CryptographicStorage
A10 Insufficient Transport Layer Protection
Sicherheit auf höheren Ebenen
Bekämpfung der Ursachen
Bekämpfung der Auswirkungen
• Sichere Entwicklung
• Sichere Architektur
• Sicherer Betrieb
• Regelmäßige Prüfungen
• Neue Technologien und Produkte
Neuen Gefahren kann nicht mit alten Technologien begegnet werden
1. Bekämpfung der Ursachen
Bekämpfung der Ursachen
• Sicheres Programmieren
– Codierungsrichtlinien
– Toolgestützt durch Quellcode-Scanner
• Prüfung der Sicherheit
– Penetrationstests
– Toolgestützt durch Applikations-Scanner
• …
Sicheres Programmieren
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
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
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
Prüfung der Sicherheit
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
Marktüberblick Web Scanner
Watchfire
Kavado ScanDo
Sanctum AppScan Verkauf
97 99 00 01 02 03 04 05 06 07 08
ProtegrityVerkauf
IBM
SPI-Dynamics WebInspect Verkauf HP
Verkauf
Cenzic Hailstorm -> Hailstorm Web -> Hailstorm
NT Objectives NTO Spider
Acunetix Acunetix WVS
2. Bekämpfung der Auswirkungen
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“
• …
Fremdcode
MyApp250.000 LoC
BEA WebLogic*>10M LoC
* estimate, based on line counts in JBoss, a competing open-source J2EE application server
Fremdcode
MyApp
250.000 LoC
BEA WebLogic*>10M LoC
Fremdcode
MyApp
250.000 LoC
BEA WebLogic*>10M LoC
Fremdcode
Menschliches Fehlerpotential
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: >>/>>/>>/>>/
Minimierung des „Windows ofExploitation“
„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
Security Principal: „Defense in depth“
„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
Positionierung von Sicherheitslösungen
Produkte für Sicherheit beiE-Business und Web-Services
Internet LAN
Web-
ServerApp. /
DBBrowser
HTTP-
Filter
Proxies für
SQL, XML,
Soap, Corba
Host IPS /
TOS / SOS
Browser-
Sicherheit
Produkte für Sicherheit beiE-Business und Web-Services
Internet LAN
Web-
ServerApp. /
DBBrowser
HTTP-
Filter
Proxies für
SQL, XML,
Soap, Corba
Host IPS /
TOS / SOS
F5 (Magnifire)
Citrix (Teros)
Barracuda (NC)
DenyAll, …
AppSec Inc,
Guardium
…
Symantec (Platform)
McAffee (Entercept)
Cisco CSA (Okena)
Argus, eEye, …
Browser-
Sicherheit
Quaresso
Promon
…
Gliederung
• Warum WAFs?
• Funktionsweise von WAFs
• Marktübersicht
• Live-Demos:
– Vorstellung exemplarischer Schwachstellen
– Konfiguration einer Web Application Firewall
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
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
Funktionsweise einer WAF
• Erzwingt konformes HTTP (RFCs)
• Normalisierung
d5opx;ÐÓGE]Ì€³óâ=• [ZܾçÙ‰Vð„'‰<½
#Ôm]ëæoª5Zòˆ!0^Ý£kê
ØmtÈ‘œìn‘k»A
H•?>'5@Ì¿êÜ°Ýë;u
³7JMµ4[ø´Èò¾ø má¼
SSL entschlüsseln
%2E%2E%2Fpartners%2Fe
%2F%7Efinance%2Frec%2F
%2Fhomepage%2Findex%2
Sonderzeichen wandeln
/partners/
/finance/rec/
/homepage/index/
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
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)
Kontrolle von URLs
fbck.php fbck.php.bak Teller BesteckTassen
Duck.htm Pluto.htm Repl.cfg
Home
/CGI /Produkte/Admin /Services /Old
• Zugriff wird nur auf URLs gestattet, die zur Applikation gehören
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
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
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 Zeichenplus Prüfung gegen Blacklisten
– plus einzelne Ausnahmen
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 Zeichenplus Prüfung gegen Blacklisten
– plus einzelne Ausnahmen
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)
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
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)
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
Dynamische Statusverfolgung
• Verfolgen jeder einzelnen Benutzersession• Analyse der abgefragten HTML-Seiten
• Extraktion aller möglichen Links
Startseite: /start.html
Cookie: Session 1357
Session 1357 Links:
/products/index.html
/services/index.html
/cgi/feedback.pl
GET /services/index.html
Startseite: /start.html
GET / GET /
GET /services/index.html
Seite: /services/index.html
Session 1357 Links:
/products/index.html
/services/index.html
/cgi/feedback.pl
/services/s1.html
/services/s2.html
/services/xy.html
Seite: /services/index.html
Cookie: Session 1357
GET /msadc/msadcs.dll
WAF WebserverAnwender
GET /msadc/msadcs.dll
Seite: /1f2caa0842ef2288
Cookie: Session 1357
Verschlüsseln von URLs
• Verfolgen jeder einzelnen Benutzersession • Analyse der abgefragten HTML-Seiten
• Verschlüsseln der enthaltenen Links
Startseite: /start.html
Cookie: Session 1357
GET /1f2caa0842ef2288
Startseite: /start.html
GET / GET /
GET /services/index.html
Seite: /services/index.html
WAF WebserverAnwender
Session 1357 Links:
/products/index.html
/services/index.html
/cgi/feedback.pl
Session 1357 encrypted
Links: /1f2caa0842ef2288
/32db48fc2c32becd
/44bce4862a4f3280
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
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
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)
Whitelisting: Flows
• Verfolgung des Benutzers auf seinem Weg durch die Applikation
• Einsatz für kritische Bereiche
– Genereller Einsatz zu komplex
Seite A Seite B Seite C
Falscher
Parameter!
Zusätzlicher Ansatz:Blacklisting (Angriffsmuster)
• vom Hersteller gepflegt/aktualisiert
• offengelegt oder proprietär
• editier- und erweiterbar
• Korrelation mehrerer Events („Scoring“)
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
Blacklisting: Fehlerbehandlung
• Log Analyse
– Interner Logviewer hilfreich
– Filterfunktionen
– Eindeutige Error Tracking IDs
– Möglichkeit zu „One Click Refinements“
Whitelist und Blacklist im Vergleich
Konfigurationsaufwand
Schutz
Blacklist
Whitelist
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
Filtern von Status- und Fehlerseiten
• Server-Banner
• Fehlerseiten von Applikations- oder Datenbankservern
Filterung sensitiver Daten
• z.B. Kreditkartendaten
• Hyperlinks zu Administrationsoberflächen oder internen Modulen(falls Applikation keine Konfiguration zulässt)
• Beliebige Content-Umschreibung
Schutz von Cookies
• Cookies werden verschlüsselt
Set-Cookie: CartNr bd53fa224c Set-Cookie: CartNr 24367
WAF
Cookie: CartNr 128
Denial Of Service
• Bandbreitenlimitierung für einzelne URLs
– Beispiel 1:
• http://www.company.com normal erreichbar
• http://www.company.com/download/ 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
• Bandbreitenlimitierung für einzelne URLs
– Beispiel 1:
• http://www.company.com normal erreichbar
• http://www.company.com/download/ 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
Denial Of Service
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
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
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
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
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
Schutzwirkung
0
10
20
30
40
50
60
70
80
90
mod
_sec
urity
Bar
racu
da F5
Impe
rva
Vison
ys
WAF
Blocked XSS-Pattern
• Beispiel: Erkennung von XSS-Angriffen
Quelle der Angriffsmuster: http://ha.ckers.org/xss.html
pe
rce
nta
ge
Und die Performance ?
• Wieviele Backendserver schützen Sie ?
• Alle Hersteller bieten Modelle unterschiedlicher Leistungsklasse
• 10.000 bis über 50.000 transactions/second (!)
• Gigabit Durchsatz
• SSL-Beschleuniger (auch mit HSM)
• Performance ist selten ein Problem!
Integration als Reverse Proxy
• Single Homed
Webserver
LAN
WAF
Internet
Integration als Reverse Proxy
• Dual Homed
Webserver
WAF
LANInternet
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
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)
HTTP/S-Verbindung
Integration als Bridge
• Keine TCP-Terminierung
• Transparente Bridge
• „Applikations-IPS“, „Layer2-WAF“
WAF WebserverBenutzer
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, …)
• 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
SSL-Terminierung
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
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
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
Gliederung
• Warum WAFs?
• Funktionsweise von WAFs
• Marktübersicht
• Live-Demos:
– Vorstellung exemplarischer Schwachstellen
– Konfiguration einer Web Application Firewall
Marktentwicklung
Watchfire
F5Magnifire
NetContinuum
KaVaDo
Sanctum
WebCohort Imperva
Stratum 8 Teros
97 99 00 01 02 03 04 05 06 07 08 09
Protegrity
Citrix
Barracuda
Verkauf
CiscoReactivity
Verkauf
DenyAll
Breach / ModSecurity
Art Of Defence
Verkauf
Verkauf
Verkauf
Verkauf
Verkauf
Seclutions Visonys PhionVerkauf
Hersteller und Produkte (alphabetisch)
• Barracuda Web ApplicationFirewall
• Cisco ACE Web ApplicationFirewall
• Citrix Application Firewall
• DenyAll rWeb
• F5 ASM
• Imperva SecureSphere
• Phion Airlock
• Protegrity Defiance TMS
Gliederung
• Warum WAFs?
• Funktionsweise von WAFs
• Marktübersicht
• Live-Demos:
– Vorstellung exemplarischer Schwachstellen
– Konfiguration einer Web Application Firewall
Live-Demos
Vorstellung exemplarischer Schwachstellen
Gliederung
• Vorstellung exemplarischer Schwachstellen
– Theorie und Live Demonstrationen
– Alte Bekannte
• Cross-Site-Scripting
• File-Inclusion-Schwachstelle
– „Neue“ Schwachstellen
• Blind-SQL-Injection
• Logische Fehler
Gliederung
• Vorstellung exemplarischer Schwachstellen
– Theorie und Live Demonstrationen
– Alte Bekannte
• Cross-Site-Scripting
• File-Inclusion-Schwachstelle
– „Neue“ Schwachstellen
• Blind-SQL-Injection
• Logische Fehler
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
1) HTML-Mail mit Link
2) Aufruf des
präparierten
Links4) Übermittlung
des Schadcodes
AngreiferOpfer
Webanwendung mit
XSS Schwachstelle
5) Ausführung des Schad-
codes im Browser
6) Cookie an Angreifer
• Nicht Persistentes Cross-Site Scripting
Cross-Site Scripting (XSS)
3) Verarbeitung des
präparierten Links
Cross-Site Scripting (XSS)
Demonstration
• „File-Inclusion“ durch die Applikationslogik
• Beispiel:
– „Gedachte“ Funktionalität:
http://www.cirobank.demo/news/news.php
?include=news.html
– Manipulierte Funktionalität:
http://www.cirobank.demo/news/news.php
?include=../../../../../etc/passwd
File-Inclusion-Schwachstelle
• „File-Inclusion“ durch die Applikationslogik
• Beispiel:
– „Gedachte“ Funktionalität:
http://www.cirobank.demo/news/news.php
?include=news.html
– Manipulierte Funktionalität:
http://www.cirobank.demo/news/news.php
?include=../../../../../etc/passwd%00.html
File-Inclusion-Schwachstelle
File-Inclusion-Schwachstelle
Demonstration
Gliederung
• Vorstellung exemplarischer Schwachstellen
– Theorie und Live Demonstrationen
– Alte Bekannte
• Cross-Site-Scripting
• File-Inclusion-Schwachstelle
– „Neue“ Schwachstellen
• Blind-SQL-Injection
• Logische Fehler
DB-ServerFirewall
„Normale“ SQL-Injection
Angreifer
Web-ServerFirewall
/search.asp
?query=' UNION … SQL-Abfrage
Ergebnis
der AbfrageAntwortseite
SELECT author,title,isbn,publisherFROM booksWHERE title LIKE '%Begriff%'SELECT null,null,password,username FROM
cirobank.users--
' UNION
SELECT name,creditcardno,null,null FROM customers--
Internet
„Normale“ SQL-Injection
• Obwohl eine Anwendung für SQL-Injectionanfä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
Blind-SQL-Injection
• „Blindes“ Finden von SQL-Injection-Schwachstellen
• Idee: Einschleusen einer wahren (TRUE) und einer unwahren (FALSE) Aussage
– Die Antworten unterscheiden sich jeweils
Blind-SQL-Injection
Blind-SQL-Injection
Demonstration - manuell
• „Blindes“ Ausnutzen von SQL-Injection-Schwachstellen
• Ziel: Systematisches Erraten des aktuellen Datenbankbenutzers „minizon“
• Idee: Den Namen Buchstabe für Buchstabe erraten
Blind-SQL-Injection
Blind-SQL-Injection
• unwahre Aussagen:
• so lange bis wahre Aussage:
' SUBSTR((SELECT user FROM dual),1,1)='a';--
' SUBSTR((SELECT user FROM dual),1,1)='m';--
' SUBSTR((SELECT user FROM dual),1,1)='b';--
' SUBSTR((SELECT user FROM dual),1,1)='c';--
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';--
Blind-SQL-Injection
Demonstration
Logischer Fehler
• Anwendungsparameter bestimmt Kontext, in dem Anwendung verwendet wird
• Nach Anmeldung an Anwendung:
www.cirobank.de/content/kunden.php?cid=dXNlcl9pZD0y
• cid ist Base64 codiert:
dXNlcl9pZD0y
• Manipulation des Parameters:
user_id=1
Base64_decode() user_id=2
Base64_encode()dXNlcl9pZD0x
Logischer Fehler
Demonstration
Live-Demos
Konfiguration einer Web Application Firewall
Danke für Ihre Aufmerksamkeit!
Top Related