Click here to load reader

Absicherung von Webanwendungen - Secodis GmbH...JAX 2014 - Security Day - 15. Mai 2014 Matthias Rohr [email protected] Absicherung von Webanwendungen

  • View
    1

  • Download
    0

Embed Size (px)

Text of Absicherung von Webanwendungen - Secodis GmbH...JAX 2014 - Security Day - 15. Mai 2014 Matthias Rohr...

  • JAX 2014 - Security Day - 15. Mai 2014

    Matthias [email protected]

    Absicherung von Webanwendungen

  • 2

    Dipl-Medieninf. (FH), CISSP, CSSLP, CISM, CCSK > 10 Jahre Applikationssicherheit & Webentwicklung Autor sowie Geschäftsführer der Secodis GmbH,

    einem Beratungshaus für Anwendungssicherheit aus Hamburg

    Schwerpunkte: 1. Security Test Automatisierung2. Secure Development Lifecycle (SDL)

    Prozesse-Design, Vorgaben/Guidelines, Integrationen, Schulungen/Coaching, …

    Matthias Rohr

    Ab Sommer 2014 im Handel

  • 86 %

    93 %

    U K S e c u r i t y B re a c h I nve s t ig a t i o n s R e p o r t 2 0 1 0

    Prozentsatz aller (Cyber-)Angriffe die über den Anwendungslayer erfolgen.

    Prozentsatz größerer Unternehmen in UK, die in einer Studie angaben in 2011

    von einem Cyber-Angriff betroffen gewesen zu sein.

    Information security breaches survey –Technical report, Apri l 2012, PwC

  • Cyber-Angriffe =

    Angriffe auf Webanwendungen!

  • 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

    App

    licat

    ion

    Laye

    r

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

    Quelle: OWASP

  • 6

    Drei Sichten

    I. Angriffszentrisch1. SQL Injection2. Cross-Site Scripting (XSS)3. Brute Forcing4. Denial of Service (DoS)

    II. Schwachstellenzentrisch1. Fehlerhafte Datenvalidierung2. Fehler in Zugriffskontrollen3. Ungenügende Anti-Automatisierung4. Fehlerhafte Konfiguration5. Fehlerhafte Authentifizierung6. Unsichere Passwörter

    III. Auswirkungszentrisch1. Downtime2. Information Leakage3. Defacement4. Monetäre Schäden5. Malware6. Phishing

    Quelle: Web‐Hacking‐Incident‐Database

  • 7

    Drei Sichten

    I. Angriffszentrisch1. SQL Injection2. Cross-Site Scripting (XSS)3. Brute Forcing4. Denial of Service (DoS)

    II. Schwachstellenzentrisch1. Fehlerhafte Datenvalidierung2. Fehler in Zugriffskontrollen3. Ungenügende Anti-Automatisierung4. Fehlerhafte Konfiguration5. Fehlerhafte Authentifizierung6. Unsichere Passwörter

    III. Auswirkungszentrisch1. Downtime2. Information Leakage3. Defacement4. Monetäre Schäden5. Malware6. Phishing

    Quelle: Web‐Hacking‐Incident‐Database

  • 8

    Drei Sichten

    I. Angriffszentrisch1. SQL Injection2. Cross-Site Scripting (XSS)3. Brute Forcing4. Denial of Service (DoS)

    II. Schwachstellenzentrisch1. Fehlerhafte Datenvalidierung2. Fehler in Zugriffskontrollen3. Ungenügende Anti-Automatisierung4. Fehlerhafte Konfiguration5. Fehlerhafte Authentifizierung6. Unsichere Passwörter

    III. Auswirkungszentrisch1. Downtime2. Information Leakage3. Defacement4. Monetäre Schäden5. Malware6. Phishing

    Quelle: Web‐Hacking‐Incident‐Database

  • 9

    Handlungsgebiete

    Sicherheitsarchitektur / Secure Design Principles Sichere Implementierung

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

    Security Testing (manuel l und automatisch) Sicherer Betrieb

    – Härtung des Web- und TLS/SSL-Servers

    – Einsatz von Web Application Firewalls

    – Laufende Scans / Change Management

  • 10

    Handlungsgebiete

    Sicherheitsarchitektur / Secure Design Principles Sichere Implementierung

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

    Security Testing (manuel l und automatisch) Sicherer Betrieb

    – Härtung des Web- und TLS-Servers

    – Einsatz von Web Application Firewalls

    – Laufende Scans / Change Management

  • 9 Best Practices zur Absicherung von Webanwendungen

  • 1. Validiere restriktiv, mehrschichtig und korrekt

  • 13

    Eingabevalidierung Architektonisch

  • 14

    Datenvalidierung = Ein- & Ausgabevalidierung

    Eingabeval id ierung 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.

  • 15

    Verwende ein positives Sicherheitsmodell

    Nicht daran denken „Was muss ich verbieten?“ (negativesSicherheitsmodell) sondern „Was muss ich erlauben?“ (positivesSicherheitsmodell)!

    Positives Sicherheitsmodell („Whitelisting“, „Known Good“): nur das „explizit Erlaubte“ wird zugelassen.

    Beispiel: „Nichts ist erlaubt bis auf Wert X“.

    Negatives Sicherheitsmodell („Blacklisting“, „Known Bad“): Bekannte Zustände oder Werte werden explizit ausgeschlossen.

    Beispiel: „Alles ist erlaubt bis auf Wert Y“.

  • 16

    (Default-)Strings, die „Mutter aller Angriffe“:– SQL-Injection: ‘ or 1=1 --

    – Cross-Site Scripting (XSS): “>…

    – Path Traversal: ../../../etc/passwd%00

    – Cross-Site Request Forgery (CSRF): “>

    – …

    Die meisten dieser Angriffe sind nicht möglich, bei:– RegExp: „A-Za-z0-9“– int, char, DateTime, ..

    Am Anfang steht der Datentyp…

  • 17

    (Benutzer-)Parameter über Data/Request Binding implizit validieren.

    Auch Anwendungsparameter (z.B. Hidden Fields) validieren!! – Whitelisting

    – Integritätsprüfungen

    – Indirektionen (später)

    – oder ganz weglassen

    Mapping von Eingaben auf (restriktive) Datentypen

  • 18

    Mehrschichtige Eingabevalidierung

    Eingabevalidierung sollte immer mehrschichtig (Defense-in-Depth-Prinzip) durchgeführt und auf alle Parameter und Schnittstellen (Single Access Points) angewendet werden!

    public class RegisterBean { @Pattern(regexp = "[a-zA-Z0-9]+”…private String userName;

    JSR-303 Bean Validation

  • 19

    URLs – Whitelists oder Indirektionen (später)– Fester Präfix (z.B. „http://example.com“+ URL)

    Dateiuploads– Immer im angemeldeten Bereich– Validierung von Dateityp (Inhalt), Dateigröße, AV-Prüfung– SANS „8 Basis Rules to Implement Secure File Uploads“*

    XML – Restriktive (!) XML Schemas (einschränken von String-Datentypen, etc.)

    HTML– Rich Content APIs (später)

    Eingabevalidierung - Sonderfälle

    * Johannes Ullrich, 8 Basic Rules to Implement Secure File Uploads, SANS Institut, 28. Dezember 2009, http://software-security.sans.org/blog/2009/12/28/8-basic-rules-to-implement-secure-file-uploads

  • 20

    Ausgabevalidierung am Backend

    String sql = "SELECT * FROM tbl WHERE user = ?";PreparedStatement prepStmt = con.prepareStatement(sql);prepStmt.setString(1, userId);

    Alle Parameter, die die Anwendung ausgibt, müssen enkodiert werden

    Immer Parametrisierungs-API (oder ORM) einer Enkodierungs-API bevorzugen!

    Alle Parameter parametrisieren!

  • 21

    Ausgabevalidierung – Vermeiden von XSS

    Werden benutzerkontrollierte Parameter 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

    “ "& &< < > >

  • 22

    Enkodierung am Frontend - Beispiel

    " />

    click me

    var msg = "";alert(msg);

    Besser jedoch implizit über Webframework, welches noch dazu den korrektenAusgabekontext berücksichtigt (z.B. GWT)!

    Programmatischer Ansatz mittels OWASP Java Encoder Project:

  • 23

    Vermeiden von XSS – Wo Parameter nicht hingeschrieben werden dürfen (Auszug)

    An verschiedene Stellen dürfen (benutzerkontrollierte) Parameter niemals ausgegeben werden, da sich diese dort nicht sicher behandeln lassen:

    => Mehr im OWASP XSS Prevention Cheat Sheet

  • 24

    Kombination aus verschiedenen Verfahren:– Restriktive Eingabevalidierung (Länge, Datentyp, Whitelisting, etc.)– Implizite Enkodierung durch Template-Technologien / Webframeworks;

    Alternativ: HTML-Enkodierung von Eingaben und Behandlung von Sonderfällen (später)

    – Do‘s und Dont‘s beachten, insbesondere wenn Parameter im JavaScript-Kontext ausgegeben werden:

    XSS – Maßnahmen

  • 25

    HTML-Markup-Eingaben immer mit sicheren APIs parsen – JSoup– OWASP AntiSammy– OWASP HTML Sanitizing Project

    Einschränken der Ausnutzbarkeit:– httpOnly-Flag für Session Cookies verwenden– Content Security Policy (CSP) für neue Entwicklungen

    XSS – Weitere Maßnahmen

  • 26

    Content Security Policy (CSP)

    Ermöglicht die Unterbindung von Inline-Skriptcode (und damit von den meisten XSS-Varianten)

    Beispiel HTTP Response Header

    Aber: Erfordert entsprechende Gestaltung der Webseite (bzw. Unterstützung vom Webframework):

    Content-Security-Policy: default-src 'self'; script-src 'self' s.site.com

    IE >=10FF >= 23Chrome >= 25Safari >=7

  • 2. Minimiere die Angriffsfläche(oder: „Weniger ist manchmal mehr!“)

  • 28

    Jede Anwendung besitzt eine Angriffsfläche. Je größer diese ist, desto mehr Möglichkeiten besitzen Angreifer!

    Angriffsfläche

  • 29

    Angriffsfläche

    Beispiel: Anwendungsparameter

    Beispiel: Schnittstellen

    https://[site]/bookin?cid=18002&STEPS=4&WDS_WR_CHANNEL=COM&command=latelogin&exController=AddElements.action&ibecoc=DE&productID=23434&pageTicket=232&debug=0&ticketID=ClWPRpdhf5Wv6SD&channel=23&mode=select&ibemode=ll&allowAccess=false

  • 30

    Minimiere die Angriffsfläche!

    Nur die Funktionen / Parameter / Daten über das Internet verfügbar machen, die unbedingt erforderlich sind

    Minimierung von Anwendungsparametern und privilegiertem Code

    Zentral genutzte Access Controls

    Alle Zugriffe über einen (wenige) Single Access Points abwickeln und dort validieren

    Nicht benötigte Funktionen sollten immer deaktiviert werden.

    Least Privilege: Berechtigungen von Code / Benutzern minimieren / Einsatz von Sandboxes

  • 31

    Minimiere Angriffsfläche: Separiere

    Externe Systeme von internen auch netzwerkseitig separieren!

    Wenn möglich: Priviligierten (z.B. administrativen) Code von Nicht-Priviligierten separieren

  • 32

    Infrastruktureller Schutz einer Webapp

    Häufig in einem System kombinier t(z.B. Apache + ModSecurity + mod_ssl)

    Här tung des TLS-StacksNur minimale Services,

    Funktionen, Berechtigungen

  • 3. Behandle Daten sicher

  • 34

    Verschlüsselung

    Sichere Protokolle und Schlüsselstärken einsetzen:

    – Sym. Verfahren: AES >= 128 Bit

    – Asym. Verfahren: RSA, min: 2048 Bit

    – Übertragung. TLS >=1.0, 1.2 mit Forward Secrecyunterstützten (kein RC4!)

    Sichere Block Chiffre Modes einsetzen (kein ECB!)

    Passwörter (später)

    Sichere und getestete Implementierungen einsetzen

    Aber: Verschlüsselung ist nicht nur der Einsatz sicherer Verfahren!

    Weitere Empfehlungen:• BSI TR-02102

    Kryptographische Verfahren (Teil 1+2)

    • www.bettercrypto.org

  • 35

    Datenbehandlungsvorgaben

    Übertrage sensible Daten nur per HTTPS und HTTP POST (nicht in der URL)!Maskiere personenbezogene Daten wenn nur für persönlichen und Hashes wennnur für technischen Abgleich erforderlich.

  • 4. Sichere die Benutzeranmeldung ab

  • 37

    Benutzerpasswörter

    Restr ikt ive Pol icy (Passwor tstärke != Passwor t länge)

    – Benutzerpasswörter sollten immer ablaufen!

    – Min. 8 Zeichen, aber inkl. Groß- und Kleinschreibung + Sonderzeichen

    – Passwort-Stärke-Funktionen verwenden: Testen der Policy, und „Common Passwords“

    Sichere Verarbeitung

    – Passwörter niemals anzeigen oder ausgeben!

    – Immer über HTTPS übertragen und eingeben!

    – Passwortspeicherung: PBKDF2, scrypt oder bcrypt (Key Stretching + Salting)

    Für hohen Schutzbedarf ist Mehrfaktorauthent i f iz ierung (z.B. +++RSA Token, +SMS, +SSLZertifikate) besser geeignet! Auch als zusätzlicher Schutz (z.B. „Geräteauthentifizierung“)

  • 38

    Anti-Automatisierungsschutz ist abhängig vom Schutzbedarf und von der Stärke existierender Schutzmechanismen (z.B. Passwortstärke)

    Vorsicht vor dem Aussperren von Benutzern! Besser: Verzögerungen (Thresholds), Client-Logik, etc.

    Anti-Automatisierungs-Schutz(Brute-Forcing-Schutz)

  • 39

    Wenn möglich: nicht über das Internet verfügbar machen! Nur HTTPS zulassen! IP-Whitelisting

    Zusätzliche Basic Auth (mit anderem Benutzer)

    SSL-Client-Zerts / MFA, etc.

    Abschottung von Admin-Zugängen

    AuthUserFile /secure/htpasswdAuthName "secured"AuthType BasicRequire user mrohr

    Order Deny, AllowDeny from allAllow from 192.124.241.Allow from 192.2.2.2

    Auszug aus .htaccess (Apache-Webserver)

    Auszug aus .htaccess (Apache-Webserver)

  • 5. Gestalte Zugriffsschutz mehrschichtig und über Indirektionen

  • 41

    Mehrschichtige Access Controls

    => Defense-in-Depth-Prinzip

  • 42

    Verwende Indirektionen

    In URLs keine „echten“ Objekt-IDs verwenden! Schließt Manipulationen und unautorisierte Zugriffe per Design aus

  • 43

    Indirektionen - Beispiel

    https://[site]/admin?cardID=18002&productID=52252

    https://[site]/admin?cardID=1&productID=3

    Mit Indirektion

    Ohne Indirektion (direkte Objekt-IDs)

    Umsetzung z.B. mittels AccessReferenceMap von OWASP ESAPI oderHDIV-Framework

  • 44

    State-ändernde Request müssen benutzer- oder request-spezifisch sein!

    CSRF

    Kein CSRF:

    Anti-CSRF-Tokens in vielen Filtern/Frameworks verfügbar, oft auch als „Replay Protection“

    Schutz vor Cross-Site Request Forgery (CSRF)

    https://[site]/admin?newPassword=123&repeat=123

    https://[site]/admin?newPassword=123&repeat=123&token=AKIJC

  • 6. Verwende sichere Standards & gestalte Sicherheit anpaßbar

  • 46

    Verwende ausgereifte Komponenten und Verfahren

    Keine sicherheitsrelevanten Algorithmen oder Implementierungen (insb. zur Kryptographie) selbst bauen sondern auf getestete und bewehrte Standardimplementierungen setzen!

    Beispiele:

    – Session Management des Application Servers

    – Apache Commons

    – Java Cryptographical Extensions (JCE)

    – OWASP Java Encoding Project

    – OWASP ESAPI

    Definition einer eigenen Enterprise Security APIs, die über welche Sicherheitsfunktionen zentral gepflegt und bereitgestellt werden.

  • 47

    Mittels „Default Secure“ werden nur die Ausnahmen behandelt Default Secure bei Kryptographie:

    Default Secure bei Ausgabevalidierung:– Bei 99% aller XSS-Angriffe werden Eingaben unvalidiert in den HTML-

    Kontext geschrieben (“/> " />< script)– Automatisches Enkodieren aller Parameter über Template-Technologie

    („Auto Encoding“); Standard bei JSTL, etc.– Problem: Daten, die am Framework „vorbeigeschrieben werden“– Ansatz: Enkodierung aller Eingaben mittels HTML Encoding und Behandlung

    der Ausnahmen (z.B. wenn Eingaben in JS-Kontext ausgegeben werden.)

    Default Secure

    Aufruf:

    String crypt = ESAPI.encryptor().encrypt(plaintext);In Config:

    KeyLength=256EncryptionAlgorithm=AES

  • 7. Nutze clientseitige Sicherheits-Features

  • 49

    Angriffstypen

    1. Direkte Angriffe

    2. Indirekt Angriffe

    SQL InjectionPriv. EscalationBrute ForcingDoS…

    XSSCSRFClickjacking…

  • 50

    Um Client-Seitige Angriffe wirkungsvoll zu unterbinden müssen Client-Seitige Security Features über Response-Header verwendet werden. Beispiele:

    – X-Frame-Options: Clickjacking-Schutz– HSTS: Erzwingen, dass Seite immer über HTTPS aufgerufen wird– secure- und httpOnly-Flag bei Session Cookies: XSS-Schutz– Content Security Policy (CSP): XSS-Schutz (u.a.)

    CORS für Cross-Domain-Zugriffe einsetzen

    Clientseitige Sicherheitsfeatures: Übersicht

  • 51

    Response‐Header Allgemeine Empfehlung Wann BeschreibungContent‐Type ...; charset=utf‐8 Immer Durchgehende Verwendung von Unicode (UTF‐8).

    Set‐Cookie

    … ;httpOnly; secure Übertragung sensibler Daten (z.B. Session‐IDs).

    Restriktives Setzen der Session‐ID. Mittels "Secure"‐Flag wird der Browser angehalten diese nur über HTTPS zu übermitteln; httpOnly verhindert das Auslesen mittels JavaScript.

    Cache‐Control no‐cache Bei Übertragung sensibler Daten.

    Verhinderung des Cachings von Daten (Header für HTTP 1.0 und 1.1).Pragma no‐cacheExpires ‐1

    Strict‐Transport‐Security

    max‐age=30758400; includeSubDomains

    Auf allen produktiven Seiten, die nur über HTTPS aufgerufen werden

    Erzwingt die Verwendung von HTTPS einer Seite für den spezifizierten Zeitraum (HTTP Strict Transport Security, HSTS).

    X‐Frame‐Options

    DENY oder SAMEORIGIN Immer Die Webseite kann nicht (bzw. nur von derselben Origin) als Frame eingebunden werden (Frame‐Busting); Schutz etwa vor Clickjacking‐ oder anderen Phishing‐Angriffen.

    X‐Content‐Type‐Options

    nosniff Immer Deaktivierung von MIME Sniffing. Dadurch wird sichergestellt, dass der Browser nicht selbstständig aufgrund des Inhalts versucht den MIME‐Typ zu bestimmen. 

    X‐XSS‐Protection1; mode=block Auf Produktivsystemen Verwenden des XSS Filters im Blocking Mode, wodurch 

    reflektierter JavaScript‐Code nicht ausgeführt wird.

    Content‐Security‐Policy

    default‐src 'self';

    script‐src 'self' [URL1] [URL2];

    frame‐src 'self' [URL1] [URL2];

    Auf Produktivsystemen Definition einer Content Security Policy (CSP), in erster Linie zur Abwehr von XSS‐Angriffen. Anwendung erfordert entsprechende Anpassungen in der Anwendung. Einsatz erfordert ggf. Umgestaltung der Struktur der Webseite.

    X‐Download‐Options

    noopen Dort wo Benutzer nicht vertrauenswürdige Dateien herunterladen können.

    Weist den Browser an ein Datei zu speichern statt diese anzuzeigen.Content‐

    Dispositionattachment; filename=

    Zum Nachlesen: Empfehlungen für Response Header

  • 8. Erkenne und behandle Angriffe

  • 53

    Indikator BeispieleHoneypots Nicht existierende Objekt‐IDs

    Nicht existierende Pfade (z.B. „/admin“) Nicht existierende Parameter (z.B. „action=delete“) Nicht verwendete Erweiterungen (z.B. „.php“ in einer Java EE‐

    Umgebung)

    Manipulation von nicht veränderbaren Werten

    Manipulation von Anwendungsparametern (Hidden Fields, etc.) Manipulation von Header Werten (Cookies, User Agent) Änderung der IP‐Adresse oder Browsersignatur einer Session

    (Session Binding)

    Tresholds Zugriffe pro Sekunde (z.B. bei Anmeldersuche, Objekt‐Zugriffe) Aufrufe pro Zeitraum (z.B. Transaktionen) Fehlerhafte Loginversuche

    Patternerkennung Erkennung von eindeutigen Angriffspatterns Identifikation gefährlicher Dateianhänge (z.B. exe) bei Dateiupload

    Klare Angriffe ermöglichen robuste Aktionen

    In einem solchen Fall: Detailliertes Logging/Alerting und invalidieren der Session /Aussperren des Accounts, (temporäres) Sperren der IP, etc.

  • 54

    Ereignis User‐Alert

    Fehlerhafte Anmeldeversuche seit letztem Login Meldung nach erfolgreichem Login

    Zeit und Ort (z.B. IP) des letzten Logins Meldung nach erfolgreichem Login

    Etwaiger erkannter Missbrauchsversuch mit Login Meldung nach erfolgreichem Login

    Setzen von Berechtigungen Bestätigung durch Benutzer, Meldung über Seitenkanal (E‐Mail, SMS)

    Durchführung hochsensibler Aktionen, wie der Änderung des Passworts

    Bestätigung durch Benutzer, Meldung über Seitenkanal (E‐Mail, SMS)

    Zugriff auf hochsensible Dateien Meldung über Seitenkanal (E‐Mail, SMS)

    User Alerting

    Benutzer in Angriffserkennung aktiv einbinden:

  • 55

    Vorbereitung treffen, um so schnell wie möglich auf identifizierte Sicherheitslücken zu reagieren

    Vir tual Patching: – Verhindern der Ausnutzung einer Schwachstelle über regulärem

    Ausdruck (z.B. innerhalb einer WAF).

    Implementierung von Security Schaltern, um im Betrieb– Funktionen abzuschalten– CAPTCHAs für bestimmte Funktionen zu aktivieren– IPs zu blockieren (selektiv oder GeoIP)– Blockierung von IPs, etc.– ….

    Security Response

  • 9. Automatisiere Sicherheitstests!

  • 57

    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) Scan auf unsicheren Abhängigkeiten / APIs (=> OWASP Dependency Check)

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

  • 58

    Security Unit & Integration Tests

    Mittels Unit Tests lassen sollten auch Sicherheitschecks durchgeführt werden (Security Unit Tests). Beispiele: Verifikation von codebasierten Access Controls, Validierung

    Einsatz von JUnit-Tests zur Durchführung von Security Integration Tests Beispiel: Checks von

    – Korrekte Enkodierung von XSS-Payloads (“),

    – Zugriff auf privilegierte URLs mit nicht privilegieren Benutzern, etc.

    – Gesetzte Security Header:

    @Testpublic void testXFrameOptionsValid() throws Exception {

    HttpResponse res = httpHelper.GetHttpHeadResponse(

    new URL("http://www.example.com"));

    // Check for valid header valueassertTrue("SAMEORIGIN".equals(

    res.getLastHeader("X-Frame-Options").getValue()));}

    Beispiel um einen gesetzten X-Frame-Options-Header zu testen

  • Zusammenfassung

  • 60

    1. Validiere restriktiv, mehrschichtig und korrekt2. Minimiere die Angriffsfläche3. Behandle Daten sicher4. Sichere die Benutzeranmeldung ab5. Gestalte Zugriffsschutz mehrschichtig und über Indirektionen6. Verwende sichere Standards & gestalte Sicherheit anpaßbar7. Nutze clientseitige Sicherheits-Features8. Erkenne und behandle Angriffe9. Automatisiere Sicherheitstests!

    9 Best Practices zur Absicherung von Webapps

    Aber: Ohne entsprechenden Management Support, Budget, Prozesse (SecuritySign-Offs), Awareness im Projekt Management und verpflichtende Vorgaben &Pentests, ist eine nachhaltige Verbesserung der Sicherheit vonWebanwendungen nicht möglich!

  • … Fragen?

    Danke! …

    Folien unter: http://bit.ly/1nOnAes