DFN-Cert - 60. Betriebstagung

Matthias Rohr11. März 2014

Absicherung von Webanwendungen

2

Matthias Rohr CISSP, CSSLP, CISM, CSSLP Autor sowie Berater und Geschäftsführer

bei der Secodis GmbH in Hamburg Unsere Schwerpunkte:

1. Tool-basierte Software-Sicherheitsanalysen

2. Secure Development Lifecycle (SDL)

Wer bin ich?

3

Cyber-Angriffe

“The cyber threat is one oft he most serious economic and national security challenges

we face as a nation“Obama, 29. Mai 2009

In einer Studie gaben 93% der größeren und 76%

der kleinere Unternehmen in UK an, in 2011 von einem Cyber-Angriff betroffen gewesen zu seinInformation security breaches survey –

Technical report, April 2012, PwC

4

Cyber-Angriffe = Angriffe auf Webanwendungen!

Q u e l l e : U K S e c u r i t y B r e a c h I n v e s t i g a t i o n s R e p o r t 2 0 1 0

Webanwendungen(86%)

Infrastruktur(14%)

5

Netzwerk vs. Application Layer

Firewall

Hardened OSWeb ServerApp Server

Firewall

Dat

abas

esLe

gacy

Sys

tem

sW

eb S

ervi

ces

Dire

ctor

ies

Hum

an R

esrc

sB

illin

gCustom Developed Application Code

APPLICATIONATTACK

Net

wor

k La

yer

Appl

icat

ion

Laye

r

Angriffe erfolgen heute über den Application Layer (Ports 80/443)

Quelle: OWASP

6

Schäden durch Angriffe auf Webanwendungen

Auch das Vertrauen in das Internet nimmt dadurch laufend ab: Fühlten sich 2010 noch 75 Prozent aller Internetbenutzer bedroht, waren es in 2011 schon 85 Prozent (Quelle: BITCOM)

Quelle: Forrester Consulting, 2012

7

Bugs vs. Sicherheitsprobleme

Bugs Sicherheits-Probleme

AnforderungenImplementierung

(„handwerkliche Fehler“)

8

Schwachstellen in Webanwendungen mit dem größten Risiko für

Unternehmen

Quelle: Forrester Consulting, 2012

9

Problem: Offenlegung Serverseitiger Objekte

10

Man-in-the-Middle-Proxys

(e in ige) Handlungsgebie te…

12

Handlungsgebiete - Übersicht

Secure Architecture / Secure Design Principles Sichere Implementierung

– Eingabevalidierung– Ausgabevalidierung (Enkodierung)– Authentisierung– Absicherung des Session Managements– Access Controls– Anti-Automatisierung– Clientseitige Sicherheit– Kryptographie und Datenbehandlung– Logging und Fehlerbehandlung

Security Testing (manuell und automatisch) Sicherer Betrieb

– Härtung des Web- und TLS-Servers– Einsatz von Web Application Firewalls– Laufende Scans / Change Management

13

Secure Design Principles (Auszug)

Kenne deinen Gegner („Know your Enemy“) Berücksichtige Sicherheit im Entwurf („Secure by Design“) Verwende einen offenen Entwurf Verwende ein positives Sicherheitsmodell Behebe die Ursachen (Ursachenprinzip) Minimiere die Angriffsfläche Verwende Indirektionen Verwende Least Privilege Implementiere Sicherheit mehrschichtig („Defense in Depth“) Gestalte Sicherheit konsistent Gestalte Sicherheit anpassbar Verwende ausgereifte Komponenten und Verfahren Prüfe jeden sensiblen Zugriff („Complete Mediation“) …

Literatur:• Basic Principles of Information

Protection, Saltzer und Schröder • NIST Special Publication 800-27

14

Vertrauensgrenzen (Trust Boundaries)

Bei jeder Vertrauensgrenze: Validierung Bei externe Vertrauensgrenze: Authentisierung und Autorisierung Beim schreiben in externe Datensenke: Verschlüsselung

15

Betriebliche Maßnahmen

Einsatz von Web Application Firewalls (2nd Layer of Defense, Hot Fixing, IDS, …) Härtung des Webservers (=> Minimierung / Abschalten nicht benötigter Funktionen) Härtung des TLS/SSL-Servers (Ciphers, Protokolle, Zertifikate) Verwenden von Security Headern (CSP, HSTS, httpOnly-Flag, X-Frame-Options)

Literatur:• Technische Sicherheitsanforderungen der

Deutschen Telekom• BSI: Sicheres Bereitstellen von Web-

Angeboten (ISi-Web-Server)

16

Separierung

Vorsicht vor gemeinsam genutzten Datenbanken, etc. Trennung auf Basis von Schutzbedarfsklassen, Mandanten, etc.

17

Verschlüsselung

Sichere Protokolle und Schlüsselstärken einsetzen:– Sym. Verfahren: AES >= 256, …– Asym. Verfahren: RSA, min: 2048 Bit– Übertragung. TLS >=1.0, 1.2 mit Forward Secrecy

unterstützten (kein RC4!) Sichere Block-Chiffre-Modes einsetzen (kein ECB!) Sichere und getestete Implementierungen einsetzen Verschlüsselung ist nicht nur der Einsatz sicherer Verfahren!

Literatur:• Mindeststandard des BSI

nach § 8 Abs. 1 Satz 1 BSIG für den Einsatz des SSL/TLS-Protokolls in der Bundesverwaltung

18

Authentifizierung - Dialoge

Popups vermeiden (Vertrauenskontext) Zugriff nur über HTTPS und HTTP POST ermöglichen! Passwörter niemals und an keiner Stelle anzeigen! Schutz vor Brute Forcing

– Neutrale Fehlerursachen anzeigen

– Z.B. Throttling

– Aber: Vorsicht vor Aussperren von Benutzern

19

Passwörter

Passwort-Stärke / -Policy– Passwörter sollten immer ablaufen

– Min. 8 Zeichen (inkl. Gross- und Kleinschreibung + Sonderzeichen)

– Verwenden von Passwort-Stärke-Funktionen, insb. für Benutzer-PWs.:

Passwort-Speicherung– Nicht im Klartext!!– Besser: Salted Hash mit Key Stretching– Algorithmen: PBKDF2 (Password-Based Key

Derivation Function 2), scrypt oder bcrypt

20

Datenvalidierung = Ein- & Ausgabevalidierung

Eingabevalidierung dient primär dazu sicherzustellen, dass Eingaben der Spezifikation entsprechen und keine unnötigen Zeichen und Werte enthalten (Korrektheit von Syntax und Semantik).

Ausgabevalidierung dient in erster Linie dazu, den Daten- vom Steuerkanal zu separieren und damit das Auftreten von Injection-Schwachstellen (XSS, SQL-, XML-Injection, etc.) zu vermeiden.

21

Datenvalidierung = Ein- & Ausgabevalidierung

Eingabevalidierung dient primär dazu sicherzustellen, dass Eingaben der Spezifikation entsprechen und keine unnötigen Zeichen und Werte enthalten (Korrektheit von Syntax und Semantik).

Ausgabevalidierung dient in erster Linie dazu, den Daten- vom Steuerkanal zu separieren und damit das Auftreten von Injection-Schwachstellen (XSS, SQL-, XML-Injection, etc.) zu vermeiden.

22

Mehrschichtige Eingabevalidierung

23

Ausgabevalidierung – Beispiel: HTML

Sonderfall HTML-Markup: Behandlung mittels sicherer APIs: z.B. JSoup, HTML Purifier, AntiSammy, etc.

Weitere Ausgabekontexte: Datenbank (SQL Injection), LDAP (LDAP Injection), OS (OS Command Injection), ….

Werden Benutzerparameter nicht korrekt in den Benutzerkontext (HTML, JS, etc.) geschrieben, kann ein Angreifer dies Ausnutzen und dort beliebigen Skriptcode zur Ausführung bringen (Cross-Site-Scripting)

Zeichen HTML Entity Encoding

“ &quot;& &amp;< &lt; > &gt;

24

Mehrschichtige Access Controls

25

Indirektionen

26

Schwachstellen in der laufenden Anwendung („URLs“)Manuell: Pentest

Autom: Dynamic App. Security Testing (DAST)

Schwachstellen auf Codeebene („Dateien“) Manuell: Code Review

Autom: Static App. Security Testing (SAST)

Session Mgmt / CSRF,Unsichere Einbindung, Logikfehler,Anti-Automatisierung,…

Race ConditionsBuffer OverflowsBackdoors,Unsichere APIs,Anbindung Backend,…

XSS,SQL Injection,Datenval. allg.Authentifizierung,Zugriffsschutz,Kryptographie,Information Leakage,Fehlerbehandlung,Konfiguration,…

Manuelle und automatisierte Tests

27

Manuelle und automatisierte Tests

Architekturelle und konzeptionelle Analysen (z.B. Threat Modelling) Pentests und Codereviews Laufende Scans der Webanwendung (Webscanner, DAST) Laufende Scans des Codes (Security Code Analysen, SAST)

Kostenfreie Tools: OWASP ZAP w3af skipfish Nikto, Wikto Minon (Burp) SSL Labs, SSLScan und ssl_test Security-Plugins für Wordpress & Co.

28

Weitere Leseempfehlungen

OWASP Top Tenhttps://www.owasp.org/index.php/OWASP_Top_TEN

OWASP Guidelineshttps://www.owasp.org/index.php/OWASP_Guide_Project

OWASP Cheat Sheetshttps://www.owasp.org/index.php/Cheat_Sheets

BSI Studienhttps://www.bsi.de

NIST Special Pubshttp://csrc.nist.gov/publications/PubsSPs.html

„Technische Sicherheitsanforderungen“ der Deutschen Telekomhttp://www.telekom.com/static/-/155996/7/technische-sicherheitsanforderungen-si

29

Fragen???