Secure Programming vs. Secure Development

Transkript

1 Secure Programming vs. Secure Development Niklaus Schild Senior Consultant Zürich, 10.Juni 2010 Basel Baden Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien

2 Agenda Entwicklung der Sicherheitsprobleme Trust-Modeling Input-Validierung Daten sind immer im Spiel. Output-Encoding Schutz vor CSRF Secure Development Secure Programming 2

3 *) OWASP Top 10 Entwicklung der Sicherheitsprobleme 2004* 2007* 2010* Unvalidated Input Cross Site Scripting Injection Broken Access Control Injection Flaws Cross Site Scripting Broken Authentication and Session Management Malicious File Execution Broken Authentication and Session Management Cross Site Scripting Insecure Direct Object Reference Insecure Direct Object Reference Buffer Overflow Cross Site Request Forgery Cross Site Request Forgery Injection Flaws Information Leakage and Security Missconfiguration Improper Error Handling Improper Error Handling Broken Authentikation and Session Management Insecure Cryptographinc Storage Insecure Storage Insecure Cryptographinc Failure to Restrict URL Access Storage Application Denial of Service Insecure Communications Insufficient Transport Layer Protection Insecure Configuration Management Failure to Restrict URL Access Unvalidated Redirects and Forwards Secure Programming 3

4 *) OWASP Top 10 Entwicklung der OWASP Top * 2007* 2010* Unvalidated Input Cross Site Scripting Injection Broken Access Control Injection Flaws Cross Site Scripting Broken Authentication and Session Management Cross Site Scripting Malicious File Execution Insecure Direct Object Reference Buffer Overflow CSRF CSRF Injection Flaws Broken Authentication and Session Management Insecure Direct Object Reference Information Leakage and Security Missconfiguration Improper Error Handling Improper Error Handling Broken Authentikation and Session Management Insecure Cryptographinc Storage Insecure Storage Insecure Cryptographinc Failure to Restrict URL Access Storage Application Denial of Service Insecure Communications Insufficient Transport Layer Protection Insecure Configuration Management Failure to Restrict URL Access Unvalidated Redirects and Forwards Secure Programming 4

5 Entwicklung der Sicherheitsprobleme Ein erheblicher Teil der Sicherheitsprobleme lassen sich auf Validierungs-Probleme im Input/Output-Kontext zurückführen Warum? komplizierte Lösungsansätze Fokus auf konkrete Fällen anstatt auf übergeordneter Problematik Ganzheitliche Lösungsansätze werden zu wenig praktiziert Das übergeordnete und fundamentale Konzept des Trust- Modeling hilft diese Probleme zu lösen: 1. Kann ich den Daten vertrauen? 2. Erstellen des notwendigen Vertrauens Secure Programming 5

6 Trust-Modeling Im Trust-Modeling werden Vertrauensverhältnisse von Datenflüssen analysiert F: kann der Browser den Web-App Daten vertrauen? A: wenn der Browser dem Web-App Betreiber vertraut F: kann die Web-App den DB-Daten vertrauen? A: wenn: - DB-Betreiber vertraut wird - Integrität gesichert ist Browser Web-App DB F: kann die Web-App den Browser-Daten vertrauen? A: wenn: - Benutzer vertraut wird - Integrität gesichert ist - Anfragen zu Antworten passen - nur wenn Daten validiert sind F: kann die DB den Web-App Daten vertrauen? A: wenn: - Web-App Betreiber vertraut wird - Integrität gesichert ist Secure Programming 6

7 Trust-Modeling Web-App Browser GET Request 1 login.jsp Response HTML/CSS 2 POST Request: j_username, j_password 3 anonym 1 X.509 Zertifikat (HTTPS) erlaubt Authentisierung der Web-App gegenüber Browser einseitige Vertrauensstellung 2 Kann Web-App die Response ohne weiteres zum Browser schicken? 3 Web-App kann dem Browser (Benutzer) nicht vertrauen Request kann nicht vertraut werden Validierung erforderlich! Secure Programming 7

8 Trust-Modeling Web-App Browser ueberweisung.jsp Response HTML/CSS POST Request: Konto=X, Betrag=Y Response HTML/CSS authentisiert 1 Kann Web-App die Response einfach an den Browser schicken? Ist sie statisch generiert: ja Daten aus Datenbank bezogen: nein (ausser DB ist 100% vertrauenswürdig!) Daten müssen korrekt Codiert werden 2 Kann Web-App dem Request vertrauen? Benutzer ist Authentisiert Secure Programming 8

9 Trust-Modeling Trust-Modeling zeigt, wo kritische Datenströme entstehen Wir haben Schnittstellen identifiziert, bei welchen ein Vertrauensverhältnis erstellt, Daten validiert und korrekt kodiert werden müssen. Was muss an diesen Schnittstellen beachtet werden? Sicherstellen, dass die Vertrauensverhältnisse sichergestellt und gewahrt werden Input Validierung Output Encoding und weitere vertrauensbildende Massnahmen Secure Programming 9

10 Input/Output Validierung Input-Validierung bekämpft folgende Sicherheitsprobleme: SQL-Injection LDAP-Injection X-Path-Injection XSLT-Injection Command Injection Parameter Injection Buffer Overflows Output-Validierung (oder Encoding) bekämpft folgende Sicherheitsprobleme: Cross Site Scripting Secure Programming 10

11 Input Validierung Massnahmen für Input Validierung An sämtlichen Schnittstellen müssen die Eingaben validiert werden Generell: Syntax- und Semantikvalidierung Whitelisting der erwarteten Zeichen Blacklisting der gefährlichen Zeichen Steuerzeichen z.b.:,=-:;%$ Zeichen mit besonderer Bedeutung z.b.: \0 SQL-Injection: Prepared Statements (z.b. OR-Mapper) Stored Procedures Bean Validation ESAPI (Enterprise Security API) Secure Programming 11

12 Output Encoding Überall wo nicht vertrauenswürdige Daten in einen potentiell ausführbaren Kontext kopiert werden muss das richtige Encoding sichergestellt werden: HTML HTML escaping & &amp < &lt > &gt " &quot Das gilt auch für:javascript, CSS, URL, etc. Um XSS effizient bekämpfen zu können ist ein (Encoding)Framework erforderlich: z.b. ESAPI Secure Programming 12

13 Beispiel Cross Site Request Forgery POST-Request in GET-Request umgefwandelt...bank-2/pages/ueberweisung.jsf... &form%3aselectonemenukonto=sparkonto &form%3akontonummer= &form%3averwendungszweck=test &form%3abetrag=233 &form%3aueberweisen=%c3%9cberweisung... In Link verpackt <a href=... > Wetterbericht</a>...dem Opfer untergejubelt... Secure Programming 13

14 Schutz vor CSRF Wenn Webanwendungen kritische Transaktionen durchführen, muss CSRF verhindert werden: Administrative Aktivitäten Firewall-Konfiguration, Hinzufügen, Verändern und Entfernen von Benutzer E-Banking oder e-commerce Transaktion Transparete Massnahme: Synchronizer Token in jeden Request einbinden CSRF Guard Kein XSS! Massnahme mit Benutzerinteraktion Re-Authentisierung Einmal-Passwort CAPTCHA Secure Programming 14

15 Secure Development Was haben wir eben gemacht? Über Trust-Modeling kritische Schnittstellen in Anwendung identifiziert Sicherheitsmassnahmen diskutiert Nachhaltige Sicherheit funktioniert nur im ganzheitlichen Kontext Secure Development Secure Development (Security Development Lifecycle) erfordert: Ausbildung Governance Risikoanalyse Secure Programming Test und Verifikation Secure Programming 15

16 Vielen Dank!? Basel Baden Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien