Absicherung von Webanwendungen

Transcription

JAX 2014 - Security Day - 15. Mai 2014
Matthias Rohr
m.rohr@secodis.com
Matthias Rohr




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 Automatisierung
2. Secure Development Lifecycle (SDL)
Prozesse-Design, Vorgaben/Guidelines,
Integrationen, Schulungen/Coaching, …
Ab Sommer 2014 im Handel
2
93 %
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 repor t, April 2012, PwC
Prozentsatz aller (Cyber-)Angriffe die über
den Anwendungslayer erfolgen.
UK Security Breach Investigations
Report 2010
86 %
Cyber-Angriffe
=
Angriffe auf Webanwendungen!
Netzwerk vs. Application Layer
5
Hardened OS
Firewall
Quelle: OWASP
Web Server
Firewall
Network Layer
App Server
Billing
Human Resrcs
Directories
APPLICATION
ATTACK
Web Services
Custom Developed
Application Code
Legacy Systems
Databases
Application Layer
Angriffe erfolgen heute über den
Application Layer (Por ts 80/443)
Drei Sichten
I.
Angriffszentrisch
1.
2.
3.
4.
SQL Injection
Cross-Site Scripting (XSS)
Brute Forcing
Denial of Service (DoS)
II. Schwachstellenzentrisch
1.
2.
3.
4.
5.
6.
Fehlerhafte Datenvalidierung
Fehler in Zugriffskontrollen
Ungenügende Anti-Automatisierung
Fehlerhafte Konfiguration
Fehlerhafte Authentifizierung
Unsichere Passwörter
Quelle: Web‐Hacking‐Incident‐Database
6
III. Auswirkungszentrisch
1.
2.
3.
4.
5.
6.
Downtime
Information Leakage
Defacement
Monetäre Schäden
Malware
Phishing
Drei Sichten
I.
Angriffszentrisch
1.
2.
3.
4.
SQL Injection
Brute Forcing
1.
2.
3.
4.
5.
6.
7
1.
2.
3.
4.
5.
6.
Downtime
Information Leakage
Defacement
Monetäre Schäden
Malware
Phishing
Drei Sichten
I.
Angriffszentrisch
1.
2.
3.
4.
SQL Injection
Brute Forcing
1.
2.
3.
4.
5.
6.
8
1.
2.
3.
4.
5.
6.
Downtime
Information Leakage
Defacement
Monetäre Schäden
Malware
Phishing
Handlungsgebiete




9
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 (manuell und automatisch)
Sicherer Betrieb
–
Här tung des Web- und TLS/SSL-Servers
–
Einsatz von Web Application Firewalls
–
Laufende Scans / Change Management
Handlungsgebiete




10
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 (manuell und automatisch)
Sicherer Betrieb
–
Här tung des Web- und TLS-Servers
–
Einsatz von Web Application Firewalls
–
Laufende Scans / Change Management
9 Best Practices zur
1. Validiere restriktiv, mehrschichtig und
korrekt
Eingabevalidierung Architektonisch
13
Datenvalidierung = Ein- & Ausgabevalidierung
Eingabevalidierung dient primär dazu
sicherzustellen, dass Eingaben der
Spezifikation entsprechen und keine
unnötigen Zeichen und Wer te enthalten
(Korrektheit von Syntax und Semantik).
14
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.
Verwende ein positives Sicherheitsmodell

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“.
Nicht daran denken „Was muss ich verbieten?“ (negatives
Sicherheitsmodell) sondern „Was muss ich erlauben?“ (positives
Sicherheitsmodell)!
15
Am Anfang steht der Datentyp…


(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, ..
16
Mapping von Eingaben auf (restriktive) Datentypen
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
Mehrschichtige Eingabevalidierung

Eingabevalidierung sollte immer mehrschichtig (Defense-in-Depth-Prinzip)
durchgeführt und auf alle Parameter und Schnittstellen (Single Access Points)
angewendet werden!
JSR-303 Bean Validation
public class RegisterBean {
@Pattern(regexp = "[a-zA-Z0-9]+”
…
private String userName;
18
Eingabevalidierung - Sonderfälle

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)
* Johannes Ullrich, 8 Basic Rules to Implement Secure File Uploads, SANS Institut, 28. Dezember 2009, http://softwaresecurity.sans.org/blog/2009/12/28/8-basic-rules-to-implement-secure-file-uploads
19
Ausgabevalidierung am Backend



Alle Parameter, die die Anwendung ausgibt, müssen enkodiert
werden
Immer Parametrisierungs-API (oder ORM) einer Enkodierungs-API
bevorzugen!
Alle Parameter parametrisieren!
String sql = "SELECT * FROM tbl WHERE user = ?";
PreparedStatement prepStmt = con.prepareStatement(sql);
prepStmt.setString(1, userId);
20
Ausgabevalidierung – Vermeiden von XSS

21
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 (CrossSite Scripting)
Zeichen
HTML Entity Encoding
“
&
<
>
"
&
< >
Enkodierung am Frontend - Beispiel
Programmatischer Ansatz mittels OWASP Java Encoder Project:
<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 korrekten
Ausgabekontext berücksichtigt (z.B. GWT)!
22
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
23
XSS – Maßnahmen

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 JavaScriptKontext ausgegeben werden:
24
XSS – Weitere Maßnahmen

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
25
Content Security Policy (CSP)


Ermöglicht die Unterbindung von Inline-Skriptcode (und damit von
den meisten XSS-Varianten)
Beispiel HTTP Response Header
Content-Security-Policy: default-src 'self'; script-src 'self' s.site.com

26
Aber: Erfordert entsprechende Gestaltung der Webseite (bzw.
Unterstützung vom Webframework):
IE >=10
FF >= 23
Chrome >= 25
Safari >=7
2. Minimiere die Angriffsfläche
(oder: „Weniger ist manchmal mehr!“)
Angriffsfläche


28
Jede Anwendung besitzt eine Angriffsfläche.
Je größer diese ist, desto mehr Möglichkeiten besitzen Angreifer!
Angriffsfläche

Beispiel: Anwendungsparameter
https://[site]/bookin?cid=18002&STEPS=4&WDS_WR_CHANNEL=COM&comman
d=latelogin&exController=AddElements.action&ibecoc=DE&productID=2
3434&pageTicket=232&debug=0&ticketID=ClWPRpdhf5Wv6SD&channel=23&m
ode=select&ibemode=ll&allowAccess=false

29
Beispiel: Schnittstellen
Minimiere die Angriffsfläche!
30

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
Minimiere Angriffsfläche: Separiere
31

Externe Systeme von internen auch netzwerkseitig separieren!

Wenn möglich: Priviligierten (z.B. administrativen) Code von NichtPriviligierten separieren
Infrastruktureller Schutz einer Webapp
Här tung des TLS-Stacks
Nur minimale Services,
Funktionen, Berechtigungen
Häufig in einem System kombinier t
(z.B. Apache + ModSecurity + mod_ssl)
32
3. Behandle Daten sicher
Verschlüsselung

34
Sichere Protokolle und Schlüsselstärken einsetzen:
–
Sym. Verfahren: AES >= 128 Bit
–
Asym. Verfahren: RSA, min: 2048 Bit
–
Über tragung. TLS >=1.0, 1.2 mit Forward Secrecy
unterstützten (kein RC4!)
Weitere Empfehlungen:
• BSI TR-02102
Kryptographische Verfahren
(Teil 1+2)
• www.bettercrypto.org

Sichere Block Chiffre Modes einsetzen (kein ECB!)

Passwör ter (später)

Sichere und getestete Implementierungen einsetzen

Aber: Verschlüsselung ist nicht nur der Einsatz sicherer Verfahren!
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 wenn
nur für technischen Abgleich erforderlich.
35
4. Sichere die Benutzeranmeldung ab
Benutzerpasswör ter



37
Re striktive Po licy (Passwor tstärke ! = Passwo r t länge)
–
Benutzerpasswör ter sollten immer ablaufen!
–
Min. 8 Zeichen, aber inkl. Groß- und Kleinschreibung + Sonderzeichen
–
Passwor t-Stärke-Funktionen verwenden: Testen der Policy, und „Common Passwords“
S i c h e re Ve rar b e i t u n g
–
Passwör ter niemals anzeigen oder ausgeben!
–
Immer über HTTPS über tragen und eingeben!
–
Passwor tspeicherung: PBKDF2, scrypt oder bcrypt (Key Stretching + Salting)
Für hohen Schutzbedarf ist Mehr faktorauthentifizierung (z.B. +++RSA Token, +SMS, +SSL
Zer tifikate) besser geeignet! Auch als zusätzlicher Schutz (z.B. „Geräteauthentifizierung“)
Anti-Automatisierungs-Schutz
(Brute-Forcing-Schutz)



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.
Abschottung von Admin-Zugängen



Wenn möglich: nicht über das Internet verfügbar machen!
Nur HTTPS zulassen!
IP-Whitelisting
Order Deny, Allow
Deny from all
Allow from 192.124.241.
Allow from 192.2.2.2

Auszug aus
.htaccess (ApacheWebserver)
Zusätzliche Basic Auth (mit anderem Benutzer)
AuthUserFile /secure/htpasswd
AuthName "secured"
Auszug aus
.htaccess
(ApacheAuthType Basic
Webserver)
Require user mrohr

39
SSL-Client-Zerts / MFA, etc.
5. Gestalte Zugriffsschutz mehrschichtig und
über Indirektionen
Mehrschichtige Access Controls
=> Defense-in-Depth-Prinzip
41
Verwende Indirektionen


42
In URLs keine „echten“ Objekt-IDs verwenden!
Schließt Manipulationen und unautorisierte Zugriffe per Design aus
Indirektionen - Beispiel

Ohne Indirektion (direkte Objekt-IDs)
https://[site]/admin?cardID=18002&productID=52252

Mit Indirektion
https://[site]/admin?cardID=1&productID=3
Umsetzung z.B. mittels AccessReferenceMap von OWASP ESAPI oder
HDIV-Framework
43
Schutz vor Cross-Site Request Forgery (CSRF)

State-ändernde Request müssen benutzer- oder request-spezifisch
sein!

CSRF
https://[site]/admin?newPassword=123&repeat=123

Kein CSRF:
https://[site]/admin?newPassword=123&repeat=123&token=AKIJC

44
Anti-CSRF-Tokens in vielen Filtern/Frameworks verfügbar, oft auch
als „Replay Protection“
6. Verwende sichere Standards & gestalte
Sicherheit anpaßbar
Verwende ausgereifte Komponenten und Verfahren

Keine sicherheitsrelevanten Algorithmen oder Implementierungen (insb. zur
Kryptographie) selbst bauen sondern auf getestete und bewehrte
Standardimplementierungen setzen!

Beispiele:

46
–
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.
Default Secure


Mittels „Default Secure“ werden nur die Ausnahmen behandelt
Default Secure bei Kryptographie:
Aufruf:
String crypt = ESAPI.encryptor().encrypt(plaintext);
In Config:
KeyLength=256
EncryptionAlgorithm=AES

Default Secure bei Ausgabevalidierung:
– Bei 99% aller XSS-Angriffe werden Eingaben unvalidiert in den HTMLKontext 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.)
47
7. Nutze clientseitige Sicherheits-Features
Angriffstypen
1. Direkte Angriffe
2. Indirekt Angriffe
49
SQL Injection
Priv. Escalation
Brute Forcing
DoS
…
XSS
CSRF
Clickjacking
…
Clientseitige Sicherheitsfeatures: Übersicht

Um Client-Seitige Angriffe wirkungsvoll zu unterbinden müssen
Client-Seitige Security Features über Response-Header verwendet
werden. Beispiele:
–
–
–
–

50
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
Zum Nachlesen: Empfehlungen für Response Header
Response‐Header
Content‐Type
Allgemeine Empfehlung
...; charset=utf‐8
… ;httpOnly; secure
Set‐Cookie
Cache‐Control
Pragma
Expires
Strict‐Transport‐
Security
no‐cache
no‐cache
‐1
max‐age=30758400; includeSubDomains
Wann
Immer
Übertragung sensibler Daten (z.B. Session‐IDs).
Bei Übertragung sensibler Verhinderung des Cachings von Daten (Header für Daten.
HTTP 1.0 und 1.1).
DENY oder SAMEORIGIN
Auf allen produktiven Seiten, die nur über HTTPS aufgerufen werden
Immer
nosniff
Immer
1; mode=block
Auf Produktivsystemen
default‐src 'self';
Auf Produktivsystemen
X‐Frame‐Options
X‐Content‐Type‐
Options
X‐XSS‐Protection
Content‐Security‐
Policy
script‐src 'self' [URL1] [URL2];
X‐Download‐
Options
Content‐
Disposition
noopen
51
frame‐src 'self' [URL1] [URL2];
attachment; filename=<dateiname>
Beschreibung
Durchgehende Verwendung von Unicode (UTF‐8).
Restriktives Setzen der Session‐ID. Mittels "Secure"‐
Flag wird der Browser angehalten diese nur über HTTPS zu übermitteln; httpOnly verhindert das Auslesen mittels JavaScript.
Dort wo Benutzer nicht vertrauenswürdige Dateien herunterladen können.
Erzwingt die Verwendung von HTTPS einer Seite für den spezifizierten Zeitraum (HTTP Strict Transport Security, HSTS).
Die Webseite kann nicht (bzw. nur von derselben Origin) als Frame eingebunden werden (Frame‐
Busting); Schutz etwa vor Clickjacking‐ oder anderen Phishing‐Angriffen.
Deaktivierung von MIME Sniffing. Dadurch wird sichergestellt, dass der Browser nicht selbstständig aufgrund des Inhalts versucht den MIME‐Typ zu bestimmen. Verwenden des XSS Filters im Blocking Mode, wodurch reflektierter JavaScript‐Code nicht ausgeführt wird.
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.
Weist den Browser an ein Datei zu speichern statt diese anzuzeigen.
8. Erkenne und behandle Angriffe
Klare Angriffe ermöglichen robuste Aktionen
Indikator
Honeypots
Beispiele




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
In einem solchen Fall: Detailliertes Logging /Alerting und invalidieren der Session /
Aussperren des Accounts, (temporäres) Sperren der IP, etc.
53
User Alerting

54
Benutzer in Angriffserkennung aktiv einbinden:
Ereignis
User‐Alert
Fehlerhafte Anmeldeversuche seit letztem Login

Meldung nach erfolgreichem Login
Zeit und Ort (z.B. IP) des letzten Logins

Etwaiger erkannter Missbrauchsversuch mit 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,
Zugriff auf hochsensible Dateien

Security Response


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
–
–
–
–
–
55
Funktionen abzuschalten
CAPTCHAs für bestimmte Funktionen zu aktivieren
IPs zu blockieren (selektiv oder GeoIP)
Blockierung von IPs, etc.
….
9. Automatisiere Sicherheitstests!
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.
57
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 privilegier te URLs mit nicht privilegieren Benutzern, etc.
–
Gesetzte Security Header:
@Test
public void testXFrameOptionsValid() throws Exception {
HttpResponse res =
httpHelper.GetHttpHeadResponse(
new URL("http://www.example.com"));
// Check for valid header value
assertTrue("SAMEORIGIN".equals(
res.getLastHeader("X-Frame-Options").getValue()));
}
Beispiel um einen gesetzten X-Frame-Options-Header zu testen
58
Zusammenfassung
9 Best Practices zur Absicherung von Webapps
1.
2.
3.
4.
5.
6.
7.
8.
9.
Validiere restriktiv, mehrschichtig und korrekt
Minimiere die Angriffsfläche
Behandle Daten sicher
Sichere die Benutzeranmeldung ab
Gestalte Zugriffsschutz mehrschichtig und über Indirektionen
Verwende sichere Standards & gestalte Sicherheit anpaßbar
Nutze clientseitige Sicherheits-Features
Erkenne und behandle Angriffe
Automatisiere Sicherheitstests!
Aber: Ohne entsprechenden Management Support, Budget, Prozesse (Security
Sign-Offs), Awareness im Projekt Management und verpflichtende Vorgaben &
Pentests, ist eine nachhaltige Verbesserung der Sicherheit von
Webanwendungen nicht möglich!
60
Danke! …
… Fragen?
Folien unter: http://bit.ly/1nOnAes

Absicherung von Webanwendungen

Transcription

Similar documents

Ohne Übergriffe – Mädchen sein und Frau werden

Einladung Mülheims Vielfalt ist seine Stärke Davetiye Çok Renklilik