Web ApplicationFirewalls (WAF)

Steffen Tröschersteffen.troescher@cirosec.de

cirosec GmbH

Ü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

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!