absicherung von webanwendungen - secodis gmbh...jax 2014 - security day - 15. mai 2014 matthias rohr...
TRANSCRIPT
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): “><script>…</script>
– Path Traversal: ../../../etc/passwd%00
– Cross-Site Request Forgery (CSRF): “><img src=http://....>
– …
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
<input type="text" value="<%= Encode.forHtmlAttribute(dataValue) %>" />
<textarea name="text"><%= Encode.forHtmlContent(textValue) %>" />
<button onclick="alert('<%= Encode.forJavaScriptAttribute(alertMsg) %>');">click me
</button>
<script type="text/javascript">var msg = "<%= Encode.forJavaScriptBlock(message) %>";alert(msg);
</script>
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 => " />< 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‐cache
Expires ‐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=<dateiname>
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