InfSi3 Zusammenfassung

INHALTSVERZEICHNIS
INHALTSVERZEICHNIS
InfSi3 Zusammenfassung
Roman Ehrbar
Oliver Nietlispach
Samuel Jost
Etienne Georgy
David Stäheli
15. August 2016
Inhaltsverzeichnis
1 Einleitung
1.1 Information Security Management . . . . . . . . . . . . . .
1.2 Treiber für Informationssicherheit . . . . . . . . . . . . . . .
1.2.1 Datenschutzgesetz DSG . . . . . . . . . . . . . . . .
1.2.2 Strafgesetzbuch StGB . . . . . . . . . . . . . . . . .
1.2.3 Health Insurance Portability and Accountability Act
1.2.4 Bankengesetz BankG . . . . . . . . . . . . . . . . . .
1.2.5 Payment Card Industry Data Security Standard . .
1.2.6 Sarbanes-Oxley Act SOX . . . . . . . . . . . . . . .
1.3 Risiken und Bedrohungen . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
HIPAA
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
5
5
6
6
6
6
6
2 Secure Software / Software Security
2.1 Most Dangerous Software Errors . . . . . . . . .
2.2 Trinity of Trouble . . . . . . . . . . . . . . . . .
2.3 Bugs + Flaws = Defects . . . . . . . . . . . . . .
2.4 Software Artefakte . . . . . . . . . . . . . . . . .
2.5 Drei Säulen der Software Security . . . . . . . . .
2.5.1 Risiko Management . . . . . . . . . . . .
2.5.2 Best Practices . . . . . . . . . . . . . . .
2.5.3 Fachwissen . . . . . . . . . . . . . . . . .
2.6 Code Analyse . . . . . . . . . . . . . . . . . . . .
2.7 Security Development Lifecycle - SDL . . . . . .
2.7.1 Training Requirements . . . . . . . . . . .
2.7.2 Security Requirements . . . . . . . . . . .
2.7.3 Quality Gates/Bug Bars . . . . . . . . . .
2.7.4 Security and Privacy Risk Assesment . . .
2.7.5 Design Requirements . . . . . . . . . . . .
2.7.6 Attack Surface Reduction . . . . . . . . .
2.7.7 Threat Modeling . . . . . . . . . . . . . .
2.7.8 Use Approved Tools . . . . . . . . . . . .
2.7.9 Deprecate Unsafe Functions . . . . . . . .
2.7.10 Static Analysis . . . . . . . . . . . . . . .
2.7.11 Dynamic Program Analysis . . . . . . . .
2.7.12 Fuzz Testing . . . . . . . . . . . . . . . .
2.7.13 Threat Model and Attack Surface Review
2.7.14 Incident Response Plan . . . . . . . . . .
2.7.15 Final Security Review . . . . . . . . . . .
2.7.16 Release/Archive . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
8
8
8
9
9
9
10
10
11
11
11
11
12
12
12
12
12
12
12
12
12
12
13
13
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
INHALTSVERZEICHNIS
3 Application Security Basics
3.1 HTTP Basics . . . . . . . . . . . . . . .
3.2 Redirect after succesful login . . . . . .
3.3 HTTP Session Management . . . . . . .
3.4 Cookies . . . . . . . . . . . . . . . . . .
3.4.1 Cookie Attribute . . . . . . . . .
3.4.2 SSL Session ID . . . . . . . . . .
3.5 Cross Site Scripting - XSS . . . . . . . .
3.6 Same Origin Policy . . . . . . . . . . . .
3.7 Cross Origin Resource Sharing - CORS
3.7.1 CORS Preflighted Request . . .
3.8 Content Security Policy - CSP . . . . .
3.9 X-Frame-Headers . . . . . . . . . . . . .
3.10 HTTP Strict Transport Security - HSTS
3.11 X-XSS-Protection . . . . . . . . . . . . .
3.12 HTTP Public Key Pinning - HPKP . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
15
16
17
17
18
18
18
19
19
19
20
20
20
20
4 OWASP Top 10
4.1 Injection . . . . . . . . . . . . . . . . . . . . . . .
4.2 Broken Authentication and Session management
4.3 Cross-Site-Scripting - XSS . . . . . . . . . . . . .
4.4 Insecure Direct Object References . . . . . . . .
4.5 Security Misconfiguration . . . . . . . . . . . . .
4.6 Sensitive Data Exposure . . . . . . . . . . . . . .
4.7 Missing Function Level Access Control . . . . . .
4.8 Cross-Site Request Forgery - CSRF . . . . . . . .
4.9 Using Components with Known Vulnerabilities .
4.10 Unvalidated Redirects and Forwards . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
22
22
22
22
23
23
23
23
5 Identity and Access Management
5.1 AAI . . . . . . . . . . . . . . . .
5.1.1 Shibboleth . . . . . . . .
5.1.2 OAuth2 . . . . . . . . . .
5.1.3 OpenID Connect . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
24
25
26
6 Web Entry Server
6.1 Reverse Proxy . . . . . . .
6.2 Pre-Authentication . . . .
6.2.1 Ablauf . . . . . . .
6.2.2 Zweck der Cookies
6.3 Filtering . . . . . . . . . .
6.4 Unique ID . . . . . . . . .
6.5 URL Encryption . . . . .
6.6 Content Rewriting . . . .
6.7 Session Store . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
27
27
27
27
28
28
28
28
7 Server Security
7.1 Hardening . . . . . . . . . . . . . . . . . . . .
7.1.1 Während der Installation des Systems
7.1.2 Netzwerksicherheit . . . . . . . . . . .
7.1.3 Authentifizierung . . . . . . . . . . . .
7.1.4 Monitoring und Auditing . . . . . . .
7.2 Unix Process Security . . . . . . . . . . . . .
7.3 File Permissions . . . . . . . . . . . . . . . .
7.3.1 Apache File Permissions . . . . . . . .
7.3.2 Tomcat File Permissions . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
29
29
29
30
30
30
31
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
7.4
7.5
7.6
INHALTSVERZEICHNIS
Privilege Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DB Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 Mobile Application Security
8.1 iOS . . . . . . . . . . . . . .
8.2 Android . . . . . . . . . . .
8.3 Windows Phone . . . . . . .
8.4 Xamarin . . . . . . . . . . .
8.5 Cordova (Phonegap) . . . .
31
31
31
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
32
32
32
32
32
9 OWASP Mobile Top 10
9.1 M1: Improper Platform Usage . . . .
9.2 M2: Insecure Data Storage . . . . . .
9.2.1 System Screenshots . . . . . .
9.2.2 Keyboard . . . . . . . . . . .
9.2.3 Clipboard . . . . . . . . . . .
9.2.4 Logs . . . . . . . . . . . . . .
9.2.5 Web Data . . . . . . . . . . .
9.2.6 Inter-Process Communication
9.3 M3: Insecure Communication . . . .
9.3.1 Certificate Pinning . . . . . .
9.4 M4: Insecure Authentication . . . . .
9.5 M5: Insufficient Cryptography . . . .
9.6 M6: Insecure Authorization . . . . .
9.7 M7: Client Code Quality . . . . . . .
9.8 M8: Code Tampering . . . . . . . . .
9.9 M9: Reverse Engineering . . . . . . .
9.10 M10: Extraneous Functionality . . .
9.11 Checkliste . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
33
33
33
34
34
34
34
35
35
35
35
35
35
35
36
36
36
10 Fraud Detection
10.1 Panopticlick / Client Correlator
10.2 E-Banking . . . . . . . . . . . .
10.2.1 Technische Daten . . . .
10.2.2 Business Informationen
10.3 Data Mining . . . . . . . . . .
10.4 Machine Learning . . . . . . . .
10.5 Vorteile / Nachteile . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
37
37
37
38
38
11 Security Testing
11.1 Notwendigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3 Vorgehen bei der Sicherheitsprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
39
39
40
12 Spezialthemen
12.1 XXE File Inclusion . . . . . . . . . . . . . . . . . .
12.2 JSON-Hijacking . . . . . . . . . . . . . . . . . . . .
12.3 URL-Redirection . . . . . . . . . . . . . . . . . . .
12.4 HTTP Request Smuggling . . . . . . . . . . . . . .
12.5 Session Fixation . . . . . . . . . . . . . . . . . . .
12.6 SSL/TLS: SSL-Cipher-Suite-Hardening, SSL-MitM
12.6.1 Apache SSL Cipher Hardening . . . . . . .
12.6.2 Apache SSL Cipher Forwarding . . . . . . .
41
41
41
41
42
42
42
42
43
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
INHALTSVERZEICHNIS
Todo list
4
1
1
EINLEITUNG
Einleitung
1.1
Information Security Management
Kleiner Rückblick zu den Begriffen aus InfSi1:
Asset Wert aus Sicht der Organisation, ob materiell oder immateriell, Informationen oder Dienstleistungen.
Threat Bedrohung, möglicher Grund für einen ungewollten Vorfall, der das System oder die Organisation schädigen kann.
Vulnerabilities Schwachstelle einer Schutzmassnahme, die durch eine oder mehrere Bedrohungen
ausgenutzt werden kann.
Controls Gegenmassnahme als Mittel zur Risikohandhabung.
Gefährdung Zusammenspiel von Asset, Threat und Vulnerabilities.
Applied Threat Die Gefährdung ist eine Bedrohung, die konkret über eine Schwachstelle auf ein
Objekt einwirkt. (Bedrohung und Schaden)
Risiko = Wahrscheinlichkeit eines Zwischenfalls * Schaden = Bedrohung * Verletzlichkeit * Schaden
1.2
Treiber für Informationssicherheit
Als hauptsächliche Treiber der Informationssicherheit zählt die Konformität zu Gesetz und Vorschriften.
Folgendes liefert ein Teil von Gesetzen und Vorschriften in den verschiedenen Sparten:
• Bearbeiter von Personendaten
– Diverse Strafgesetzbuch Artikel
– Datenschutzgesetz (DSG)
– US Health Insurance Portability and Accountability Act (HIPAA)
• Finanzdienstleister
– Bankgesetze (Bankgeheimnis, etc.)
– EU Directive on Payment Services (PSD)
– Payment Card Industry Data Security Standard (PCI)
• Telecom/ICT-Anbieter
– Fernmeldegesetz
– Lawful Interception
• Allgemeines Controlling
– Sarbanes-Oxley Act (SOX), US-börsenkotierte Firmen
1.2.1
Datenschutzgesetz DSG
Wer als Privatperson Personendaten bearbeitet oder ein Datenkommunikationsnetz zur
Verfügung stellt, sorgt für die Vertraulichkeit, die Verfügbarkeit und die Richtigkeit der
Daten, um einen angemessenen Datenschutz zu gewährleisten. - DSG Art. 8
1.2.2
Strafgesetzbuch StGB
Missbrauch einer Fernmeldeanlage - StGB Art. 179septies (Virentatbestand)
Unbefugtes Beschaffen von Personendaten - StGB Art. 179novies (Hackingtatbestand)
5
1.3
Risiken und Bedrohungen
1.2.3
1
EINLEITUNG
Health Insurance Portability and Accountability Act HIPAA
Umfasst mehrere Regeln zu Datenschutz und -Sicherheit. Dazu werden auch eine Regel für die Unique
Identifiers definiert (National Provider Identifier, NPI).
1.2.4
Bankengesetz BankG
. . . ein Geheimnis offenbart . . . [oder] zu einer solchen Verletzung des Berufsgeheimnisses
zu verleiten sucht. - BankG Art. 47
1.2.5
Payment Card Industry Data Security Standard
Dieser umfasst mehrere Bestimmungen wie z.B. der Einsatz einer Firewall, Verschlüsselte Übertragung, Beschränkung des physikalischen Zugriffs, usw.
1.2.6
Sarbanes-Oxley Act SOX
Fordert verschärfte interne Kontrollsysteme und führt zu höheren Anforderungen an die Corporate
Governance.
1.3
Risiken und Bedrohungen
Für den Umgang mit Risiken können Unternehmen unterstützend ein Information Security Management System einsetzen.
Abbildung 1: Stark vereinfachte Sicht [ISO27001:2005]
Threat Effekte, können nicht kontrolliert werden (Erdbeben, Stromausfall).
Risk Risiko, kann vermindert werden durch verminderung des Einflusses auf das Business.
Vulnerability Gefahren, können behandelt werden (Verbesserung der Software, Einschränken von
Zugriff).
Vulnerability Assessment Das eigentliche Information Security Management: Geschäftsprozesse
werden beobachtet, verknüpft mit der Compliance, Budget, Beurteilung und der Bewusstheit
der Gefahr.
Direct Attacks Angriff direkt auf das Ziel, z.B. durch eine Firewall.
Indirect Attack Ein ungeschütztes Gerät, wie z.B. ein privates Notebook, wird angegriffen und über
dieses dann dem Angreifer Zugriff auf das restliche System ermöglicht.
Man-in-the-Middle Der Angreifer hört den Datenverkehr des Opfers mit und kann diesen auch
beeinflussen, erneut versenden oder verändern.
6
1.3
Risiken und Bedrohungen
1
EINLEITUNG
Privilege Escalation Es wird versucht, mehr Berechtigungen zu erhalten, wie z.B. ausführen eines
Skripts als Root, ohne die Kennwörter zu besitzen.
Social Engineering Umgehen von technischen Einrichtungen zum Schutz vor Angriffen über menschliches Fehlverhalten und gezielte Manipulation des Menschen.
Backdoor Teil einer Software/Hardware, unter Umgehung der normalen Zugriffssicherung Zugang
zu geschützten Daten zu erlangen.
7
2
2
SECURE SOFTWARE / SOFTWARE SECURITY
Secure Software / Software Security
Durch das Aufkommen des Internets nahm auch die vom National Institute of Standards and Technology (NIST) erfassten Vulnerabilities mit hohem Ausmass zu.
2.1
Most Dangerous Software Errors
Die 25 häufigsten Schwachstellen können in drei Kategorien eingeteilt werden:
• Ausgelöst durch unsichere Wege, in denen die Daten gesendet und empfangen werden. Dazu
zählen SQL Injection, OS Command Injection, XSS, CSRF und Open Redirect.
• Ausgelöst durch die unsichere Handhabung von Systemressourcen. Dazu gehören Classic Buffer Overflow, Path Traversal, Uncontrolled Format String, Potentially Dangerous Function und
Integer Overflow.
• Ausgelöst durch falsche Verwendung, Missbrauch oder Ignorierung von defensiven Sicherheitsmechanismen. Dazu zählen Missing Authentication, Missing/Incorrect Authorization, Hard-Coded
Credentials, Missing Encryption, Reliance on Untrusted Inputs, Incorrect Permission Assignment,
Use of broken or risky Cryptographic algorithm und One-Way Hash without Salt.
2.2
Trinity of Trouble
Folgende drei Aspekte sind mitunter verantwortlich für diese Schwierigkeiten.
Connectivity Immer mehr Systeme sind über das Internet miteinander verbunden und eröffnen somit
neue Attack Vectors. Service Oriented Architecture (SOA) führt alte Systeme, welche nicht für
die Vernetzung vorgesehen wurden, zusammen und veröffentlicht diese.
Extensibility Systeme sind erweiterbar, wodurch ein teil der Kontrolle abgegeben wird. Über schlecht
gewartete Erweiterungen können so neue Schwachstellen entstehen.
Complexity Moderne Software wird immer komplexer. Mit dem Umfang nimmt auch die Fehlerrate
quadratisch zu.
2.3
Bugs + Flaws = Defects
Security Bug Implementation-level Schwachstelle
Security Flaw Design-level Schwachstelle (können selten automatisiert erkannt werden)
Security Defect Ruhender defekt in der Software, welcher durch ein Bug oder Flaw ausgelöst wird.
2.4
Software Artefakte
Es gibt ein gemeinsames Set von Artefakten, welche unabhängig vom eigentlichen Entwicklungsprozess
(Scrum, RUP, XP, . . . ) sind. Diese sind:
• Anforderungen und Use Cases
• Architektur und Design
• Testpläne
• Code
• Tests und Testresultate
• Rückmeldung von Kunden
2.5
Drei Säulen der Software Security
Zu den zentralen drei Säulen gehören Risiko Management, Best Practices und Fachwissen.
8
2.5
Drei Säulen der Software Security
2.5.1
2
SECURE SOFTWARE / SOFTWARE SECURITY
Risiko Management
Man identifiziert die betroffenen Personen, die technischen Risiken, auch die für das Unternehmen,
und priorisiert sie anhand der gewonnenen Informationen. Danach kann eine Strategie zur Minderung
entwickelt werden. Nach der Anwendung sollten die Anpassungen auf ihre Wirkung hin überprüft
werden.
Abbildung 2: Risiko Evaluations-Matrix
2.5.2
Best Practices
Es folgen einige Best Practices in der Reihenfolge ihrer Effektivität. Sie können den Kategorien
Konstruktiv (white hat) und Destruktiv (black hat) zugeordnet werden.
• Code Review K
• Architectural risk analysis (historical knowledge) K D
• Penetration testing D
• Risk-based security tests D K
• Abuse cases D K
• Security requirements K
• Security operation K
2.5.3
Fachwissen
Zum Fachwissen gibt es mehrere Perspektiven. Das Wissen über die Prinzipien, Rahmenbedingungen
und Regeln gehören zum Vorgeschriebenen Fachwissen. Dazu gesellt sich die Diagnostischen Fähigkeiten mit dem Wissen über Angriffe, Schwachstellen und Angriffsmuster. Zuletzt benötigt man auch
ein Wissen über die Vergangenheit.
9
2.6
Code Analyse
2
SECURE SOFTWARE / SOFTWARE SECURITY
Abbildung 3: Best Practices und Fachwissen angewendet auf die Software Artefakte
2.6
Code Analyse
Für die Analyse von Sourcecode bieten sich mehrere Lösungen an, welche den Quellcode und auch
das laufende Programm analysieren und auswerten können. Die ersten Generationen von solchen
Analyseprogrammen wurden auch als Intelligentes Grep bezeichnet und lieferten viele false positives.
In späteren, oft kommerziellen Tools, wurden diese, durch Parsen des Source-Codes, versucht zu
minimieren.
Das Wissen aus der Vergangenheit ist in die Regelsätze dieser Software eingeflossen. Jedoch können
Probleme in der Softwarearchitektur nicht oder nur selten erkannt werden. Ein manuelles Review ist
somit weiterhin nötig. Auch können Abhängigkeiten und falsche Benutzung externer Komponenten
nicht korrekt überprüft und erkannt werden.
2.7
Security Development Lifecycle - SDL
Der Security Development Lifecycle ist ein Prozess, welcher die Sicherheit innerhalb der Softwareentwicklung garantieren soll. Er wurde von Microsoft entwickelt und gilt als Grundlage, lässt
sich also für jede Unternehmensgrösse anpassen. Der SDL umfasst die drei Kernkonzepte Schulung,
fortwährende Verbesserung der Prozesse und Zurechenbarkeit.
Der SDL sollte auf Projekte mit folgenden Merkmalen angewendet werden:
• Eingesetzt in einem Unternehmen
• Verarbeitung von personenbezogenen Daten
• Regelmässige Kommunikation über das Internet oder andere Netzwerke
Im Prinzip kann der SDL also auf alle Projekte angewendet werden. Es ist einfacher,
diejenigen zu identifizieren, die keinen sicherheitstechnischen Massnahmen benötigen und daher auch
auf den SDL verzichten können.
Es existieren mehrere Rollen, wovon zwei besonders hervorzuheben sind. Diese lassen sich wiederum
weiter unterteilen.
10
2.7
Security Development Lifecycle - SDL 2
SECURE SOFTWARE / SOFTWARE SECURITY
Reviewer/Advisory Roles Diese Rolle soll eine Übersicht über die Sicherheit des Projektes bieten
und in der Lage sein, Pläne bezüglich Sicherheit und Datenschutz anzunehmen/abzulehnen.
Kann von Internen wie auch externen Personen übernommen werden, aber keine Teammitglieder.
Team Champions Diese Rolle ist verantwortlich für den Austausch, Akzeptanz und Verfolgung von
minimalen Anforderungen an die Sicherheit und Datenschutz. Sie sind das Gegenstück zu den
Advisory Roles und besteht aus Teammitglieder.
Finden die Sicherheitsrelevanten Aktivitäten frühzeitig und innerhalb des Entwicklungsprozesses statt,
erhält man den grössten Nutzen daraus. Um den Microsoft SDL-Prozess einzuhalten müssen die 16
zwingenden Aktivitäten eingehalten werden.
Abbildung 4: Security Development Lifecycle von Microsoft
2.7.1
Training Requirements
Alle Mitglieder des Entwicklerteams müssen eine Schulung im Bereich Softwaresicherheit erhalten und
sich über aktuelle Trends informieren. Die Themen umfassen sicheres Design, Modellierung von
Bedrohungen, sicheres Coding, Sicherheitstests und Datenschutz.
2.7.2
Security Requirements
Definition von vertrauenswürdigen Anforderungen an das Projekt. Damit können Schlüsselstellen identifiziert werden und die Sicherheit sowie Datenschutz frühzeitig integriert werden. Dies verhindert
unnötige Verzögerungen.
2.7.3
Quality Gates/Bug Bars
Quality Gates und Bug bars sind minimale Akzeptanzkriterien in Anbetracht der Sicherheit und des
Datenschutzes. Das gesamte Team muss sich an die Anforderungen halten, wobei diese nicht dynamisch
verändert werden dürfen.
Quality Gate Anforderung an die Code-Qualität bezüglich Compiler-Warnungen, Kommentare, Komplexität, etc.
Bug Bar Schwelle für Sicherheitslücken, welche noch im Projekt beim Release enthalten sein dürfen.
Z.B. keine Lücken mit der Bewertung “Kritisch“ oder “Warnung“.
2.7.4
Security and Privacy Risk Assesment
Beurteilung der Sicherheit- und Datenschutz-Anforderungen von funktionalen Komponenten, welche
eine genauere Begutachtung benötigen. Es wird bestimmt, ob weitere Threat Models, Security Design
Reviews, Penetration Testing, Zusätzliche Tests und Anforderungen an Fuzz Tests nötig sind.
Zusätzlich wird das Privacy Impact Rating festgelegt: High Privacy Risk bei der Verarbeitung von
personenbezogenen Daten und Einstellungen, Medium Privacy Risk bei Übermittlung anonymisierter Daten und Low Privacy Risk, falls keine Anforderungen für den Datenschutz nötig sind.
11
2.7
Security Development Lifecycle - SDL 2
2.7.5
SECURE SOFTWARE / SOFTWARE SECURITY
Design Requirements
Designspezifikationen sollen Sicherheits- und Datenschutz-Funktionen beschreiben, welche direkt dem
Benutzer zugänglich sind. Das sind z.B. Funktionen, welche eine Authentisierung oder die Einwilligung
des Benutzers erfordern. Gleichzeitig sollten sie auch beschreiben, wie die Sicherheit dieser Funktion
implementiert wird.
2.7.6
Attack Surface Reduction
Hierbei wird der Zugriff auf das System eingeschränkt und mehrschichtige Abwehrmassnahmen eingeführt. Eng verknüpft mit dem Threat Modeling.
2.7.7
Threat Modeling
Es werden mögliche Bedrohungen in Betracht gezogen, Diskutiert und Dokumentiert im Kontext der
geplanten Umgebung.
2.7.8
Use Approved Tools
Im gesamten Team müssen Tools definiert und festgehalten werden, wie damit die Sicherheit überprüft
werden. Wie z.B. Compiler- oder Linter-Warnungen.
2.7.9
Deprecate Unsafe Functions
Als Team werden die Funktionen und APIs definiert, welche man nicht verwenden darf. Somit können
diese dann auch überprüft und durch alternativen ersetzt werden.
2.7.10
Static Analysis
Eine skalierbare Möglichkeit zur Analyse des Codes auf Programmierfehler und Einhaltung der CodingGuidelines. Dies schliesst aber manuelle Reviews nicht aus, diese sollten weiterhin für kritische Bereiche
durchgeführt werden.
2.7.11
Dynamic Program Analysis
Verifikation während der Laufzeit, dass das Programm auch den Anforderungen entsprechend funktioniert. Es müssen Tools definiert werden, welche ein Fehlverhalten(falsche Berechtigungen) oder die
Verwendung von Ressourcen protokollieren.
2.7.12
Fuzz Testing
Dynamische Analyse anhand von automatisch generierten Eingaben (absichtlich falsch oder zufällig).
Die Strategie fürs Testen wird anhand der Funktionellen- sowie Design-Spezifikation abgeleitet.
2.7.13
Threat Model and Attack Surface Review
Abweichungen der Anwendung von der ursprünglichen Funktionellen- und Design-Spezifikation feststellen und überprüfen, ob Anpassungen nötig sind. Spätestens beim Code-Complete ist eine erneute
Analyse notwendig.
2.7.14
Incident Response Plan
Damit wird festgehalten, wie bei einem Notfall vorgegangen wird. Zudem sind weitere Informationen
enthalten, welche für die Behebung und Verarbeitung hilfreich sind.
• Ansprechperson für den ersten Kontakt sowie, wenn vorhanden, auch ein Entwicklerteam.
• Ansprechperson mit Entscheidungsgewalt, verfügbar 24/7.
12
2.7
Security Development Lifecycle - SDL 2
SECURE SOFTWARE / SOFTWARE SECURITY
• Sicherheitsrelevante Informationen von Code anderer Entwickler-Teams.
• Sicherheitsrelevante Informationen von Third-Party-Komponenten, dessen Version, Dateinamen,
Kontaktdaten und Vertragsinformationen, falls vorhanden.
2.7.15
Final Security Review
Die eigentliche Kontrolle vor dem Release, ob die Software allen im Prozess definierten Anforderungen entspricht und die Sicherheitsaktivitäten eingehalten wurden. Hier werden die Gesammelten
Informationen aus Threat Models, exception requests, Ausgabe der Tools und Performanz mit den
Quality Gates und Bug Bar verglichen. Daraus ergibt sich dann das Resultat FSR bestanden, FSR
bestanden mit Ausnahmen oder FSR mit Eskalation.
2.7.16
Release/Archive
Die Software ist aus Sicht des SDL komplett und kann nach Bestätigung des Sicherheitsberaters freigegeben werden. Für jede High Privacy Risk wird auch eine Bestätigung des Datenschutzbeauftragten
benötigt. Alle im Prozess erzeugten Artefakte müssen archiviert werden, um eine Wartung nach dem
Release zu ermöglichen.
Optionale Sicherheitsaktivitäten
Die zuvor beschriebenen Sicherheitsaktivitäten sind nur das Minimum und können noch weiter ergänzt
werden.
Ein manuelles Code-Review wird eingesetzt, wenn besonders sensitive Daten verarbeitet oder
gespeichert werden. Es macht auch Sinn, Implementationen von kryptographischen Funktionen auf
ihre Korrektheit zu überprüfen.
In einem Penetration Testing wird als Whitebox-Analyse die Sicherheit durch Spezialisten mit der
Vorgehensweise von Hackern durchgeführt. Sie bieten zusätzliche Anhaltspunkte und ergänzen CodeReviews.
Als weiterer Schritt kann auch die Analyse auf Schwächen in vergleichbaren Anwendungen
gesehen werden. Da oftmals die Informationen über Schwachstellen im Internet verfügbar sind, können
diese mit der eigenen Anwendung verglichen werden, ob diese auch zutreffen.
13
3
3
APPLICATION SECURITY BASICS
Application Security Basics
3.1
HTTP Basics
HTTP ist Zustandslos: Der Client sendet eine Anfrage (Request) an den Server, welcher ihn verarbeitet und anschliessend das Resultat als Antwort (Response) zurücksendet.
Abbildung 5: HTTP Header
Zwischen HTTP GET und POST gibt es einen wesentlichen Unterschied. Da der Server die URI in der
Regel mitloggt, werden auch die Parameter des GET-Request mitgeloggt. Beim POST-Request
geschieht dies nicht, da sich die Parameter anstatt in der URI im Body befinden. Dies ist auch bei
Proxies zu beachten. Eine Response ist beinahe Identisch zum Request. Die erste Zeile enthält nun
das Protokoll, Statuscode und Statusbeschreibung (HTTP/1.1 200 OK).
Abbildung 6: Beispielrequests für GET und POST
HTTP Methode
Verwendung
GET
normale verwendung *
POST
übermittlung von Daten (Login, Formulare) *
HEAD
Suchmaschinen (Head of page) *
PUT
Upload von Dateien (webdav, RESTful)
DELETE
Löschen von Dateien (webdav, RESTful)
OPTIONS
Auflistung verfügbarer Methoden auf Server
TRACE
Debugging in Webserver
Tabelle 1: Übliche HTTP Methoden (* meist verwendet)
14
3.2
Redirect after succesful login
Statuscode
Nachricht
3
APPLICATION SECURITY BASICS
Bedeutung
2xx - Erfolgreich
200
OK
Anfrage erfolgreich bearbeitet, Ergebnis in der Antwort
enthalten.
3xx - Umleitung
301
Moved Permanently
Header “Location: http://other-site/“
302
Moved Temporarily
Header “Location: http://other-site/“; Alternativ 303
oder 307 möglich
4xx - Clientfehler
400
Bad Request
Anfrage war fehlerhaft aufgebaut
401
Unauthorized
Authentifizierung nötig
403
Forbidden
Mangelnde Berechtigung des Clients
404
Not Found
Angeforderte Ressource nicht gefunden
405
Method Not Allowed
408
Request Timeout
5xx - Serverfehler
500
Internal Server Error
Allgemeiner Serverfehler
501
Not Implemented
Funktionalität wird vom Server nicht bereitgestellt
502
Bad Gateway
Proxy hat ungültige Antwort erhalten
503
Service Unavailable
Service steht temporär nicht zur verfügung
Tabelle 2: Übliche HTTP Statuscodes, https://de.wikipedia.org/wiki/HTTP-Statuscode
3.2
Redirect after succesful login
Unter diesem Namen verbirgt sich ein Pattern, um die “Back Button Relogin Vulnerability“ zu
adressieren. Ohne Anwendung dieses Patterns besteht die Möglichkeit, dass nach mehrmaligem Klick
auf Zurück die eingegebenen Logindaten erneut an den Server übertragen werden. Bei Fehlschlag des
Logins kann mittels eines gewöhnlichen 200 OK um eine erneute Eingabe gebeten werden.
15
3.3
HTTP Session Management
3
APPLICATION SECURITY BASICS
Abbildung 7: Redirect after succesful login
Es gibt dabei mehrere Varianten für den Redirect:
• Type 1 (302 Moved Temporarily)
– HTTP Response Status 302
– HTTP Response Header “Location: http://other-site/“
• Type 2 (200 OK)
– HTTP Response Status 200
– HTTP Response Header “Refresh: 0; URL=http://other-site/“
• Type 3 (200 OK)
– HTTP Response Page
– Meta-Tag “Refresh“
• Type 4 (Javascript)
– Client-Seitiger Code (z.B. “document.location=. . .“)
3.3
HTTP Session Management
Serverseitig wird eine Speicherstruktur erstellt, um Session-Daten zu speichern. Der Client erhält ein
Schlüssel zu dieser Struktur, auch bekannt als SessionId.
Bei jeder Anfrage des Clients an den Server muss dieser die SessionId mitgeben, damit der Server auf
16
3.4
Cookies
3
APPLICATION SECURITY BASICS
die Daten der Session zugreifen kann. Dazu gibt es mehrere Varianten, wo sich die SessionId befindet
(Session Locations):
• URI
– Sichtbar in Logs
– Problematisch beim Caching
• Request Header
– Cookie, NTLM, BasicAuth
• Body
– Als Hidden Field
– Kaum verbreitet
3.4
Cookies
Set-Cookie: PREF=ID=2744d38c32b2ec68:LD=de:TM=1094031009
expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.ch
Abbildung 8: Cookie erzeugung über HTTP Request Header
3.4.1
Cookie Attribute
• Name=Content (Key, value pair)
– Name: Cookie Name
– Content: Cookie Value
– Beispiel: jsessionid=klrezbxur234kls
• Domain
– Ort wohin das Cookie gesendet werden kann.
– Default: Cookie wird nur an den Server gesendet, von dem es stammt.
• Path
– URL-Path wohin das Cookie gesendet werden kann.
17
3.5
Cross Site Scripting - XSS
3
APPLICATION SECURITY BASICS
– Default: Cookie wird nur an den Pfad gesendet, von dem es stammt.
• Secure
– Cookie wird nur über HTTPS übermittelt.
– Default: insecure
• Expire
– Gültigkeit des Cookies.
– Default: wird nicht persistiert, nur Browsersession.
• HttpOnly
– Cookie kann nicht von JavaScript verwendet werden.
– Default: nicht vorhanden, JavaScript kann mit document.cookie darauf zugreifen.
Wann ein Cookie an den Server gesendet wird, ist abhängig von mehreren Attributen: Domain,
Path, Secure und Expire.
Das HttpOnly Attribut bietet ein Schutz gegenüber XSS, wobei es dem JavaScript, welches eingeschleust wurde, verhindert wird, auf das Cookie zuzugreifen.
3.4.2
SSL Session ID
Mithilfe der SSL Session ID können SSL-Session weiter verwendet werden, ohne einen erneuten Handshake durchzuführen. Ähnlich wie bei Cookies werden diese zu beginn der Anfrage an den Server übermittelt, welcher den zur ID passenden symmetrischen Schlüssel besitzt.
Der gesamte Payload des SSL-Pakets ist verschlüsselt, man sieht also weder die URL noch andere
Inhalte des HTTP-Paket.
3.5
Cross Site Scripting - XSS
Die Gefahr für XSS entsteht, wenn Benutzereingaben unzureichend gefiltert werden und unverändert
wieder an andere Benutzer ausgeliefert werden. Dies ermöglicht z.B. die Übernahme von Sessions,
HTML- oder JS-Injection, Exploit injection oder Keylogging.
Es werden drei Typen von Attacken unterschieden:
Stored Das injizierte Skript ist permanent auf dem Zielserver gespeichert, z.B. in Form von Forumsbeiträgen.
Reflected Das Skript wird nicht auf dem Zielserver gespeichert, der Angreifer muss aber eine URL
präparieren und diese dem Opfer unterjubeln. Dies ist z.B. über eine Suchanfrage möglich.
DOM based Angreifer muss eine URL präparieren, welche dann im Client direkt ausgelöst wird.
Server wird dabei nicht aufgerufen, clientseitige Validierung nötig.
Mögliche Gegenmassnahmen sind:
HTML entities Encoding vor dem Speichern und bei der Ausgabe.
HTTP Only Cookies Auslesen über JS nicht möglich.
CSP Content Security Policy: script-src ’self’
3.6
Same Origin Policy
Die damit wird verhindert, dass Javascript (auch Flash, Java Applet, etc.) auf DOM und Cookies
zugreifen kann. Nur bei der Übereinstimmung von Protokoll, Host und Port wird dies erlaubt.
Wird nun aber in der Ursprungs-Seite das 3rd-Party-Script durch <script src="..."> geladen,
so kann es auf das Cookie der Ursprungs-Seite zugreifen.
Die Übermittlung von Daten an fremde Seiten kann dann über Bild-Tags erfolgen, da diese nicht der
SOP unterliegen.
Wird der Javascript-Code über die URL injiziert, so spricht man von Reflected XSS. Der XSS-Schutz
im Browser kann dies verhindern, aber nicht bei Stored XSS.
18
3.7
Cross Origin Resource Sharing - CORS
3.7
3
APPLICATION SECURITY BASICS
Cross Origin Resource Sharing - CORS
Damit schützt sich nicht der eigentliche Webseitenbetreiber, sondern ein Serivce-Provider, welcher Daten für den Betreiber bereitstellt. Anfragen an den Service-Provider enthalten ein Header Origin:
http://foo.example.com. Die Antwort darauf den Header Access-Control-Allow-Origin:
http://foo.example.com (Wildcards sind auch möglich).
3.7.1
CORS Preflighted Request
Der Preflight wird ausgeführt, falls eine der folgenden Bedingungen zutrifft:
• Verwendung einer Methode ausser GET, HEAD oder POST.
• POST fordert Daten mit einem anderen Content-Type als application/x-www-form-urlencoded,
multipart/form-data oder text/xml an
• POST sendet Daten mit einem XML-Payload zum Server.
Abbildung 9: Vorgehen beim CORS Preflight
Standardmässig werden bei XMLHttpRequests aufrufen keine Credentials/Cookies mitgeschickt. Um
dies zu forcieren, muss ein spezielles Flag (withCredentials) auf dem Request-Objekt gesetzt werden.
3.8
Content Security Policy - CSP
Dahinter versteckt sich ein Sicherheitskonzept, um XSS und diverse andere Angriffe wie Clickjacking
und Code Injection, durch einschleusen von Daten in Webseiten zu verhindern. Es wird als HTTPHeader-Field Content-Security-Policy und bei IE 10+ X-Content-Security-Policy unterstützt. Dadurch kann der Server bestimmen von welchem Origin Content geladen werden darf. Trifft auf ein
Element mehrere CSPs zu, wird immer die restriktivste benutzt!
1
Listing 1: Starter Policy für CSP-Header
Content-Security-Policy: default-src ’none’; script-src ’self’;
connect-src ’self’; img-src ’self’; style-src ’self’;
Das Vorgehen beim erstellen einer neuen CSP ist wie folgt:
1. CSP-Header bei allen Requests hinzufügen mit Policy default-src ’none’
2. Verstösse in der Browser-Konsole anschauen
3. Nötige Quellen zur Policy hinzufügen
CSP hat folgende Defaults aktiviert:
1. Keine Inline Javascript-Snippets. Nur aus Files
19
3.9
X-Frame-Headers
3
APPLICATION SECURITY BASICS
2. Keine JS-URLs wie javascript:http://url
3. Eventhandling-Attribute sind deaktiviert (zum Beispiel document.click())
4. Funktion eval() ist deaktiviert
5. Der Konstruktor von function() ist deaktiviert
6. URIs sind nur für Bilder erlaubt
3.9
X-Frame-Headers
Als HTTP-Header-Feld eingesetzt dient es als Schutz vor Clickjacking-Attacken. Dabei wird dem
Opfer ein Frame über ein anderen Inhalt gelegt und so versucht, durch Klicken Aktionen auf dem
dahinterliegenden Objekt auszuführen.
CSP hat Vorrang vor X-Frame-Headers, weil die Unterbindung von Frames seit Version 2.0 dort
auch integriert ist.
Listing 2: Clickjacking mittels X-Frame-Options unterbinden
1
X-Frame-Options: DENY
3.10
HTTP Strict Transport Security - HSTS
Ein Sicherheitsmechanismus für HTTPS-Verbindungen. Er soll vor Aushebelung der Verbindungsverschlüsselung durch eine Downgrade-Attacke als auch vor Session Hijacking schützen. Durch die
Angabe des Header-Feldes wird jede weitere Verbindung bis zum erreichen des max-age als HTTPS
erzwungen, auch wenn die Links z.B. auf HTTP lauten. Zusätzlich wird eine Verbindung mit dem
Server verhindert, sobald Zertifikatsprobleme auftauchen.
Google Chrome wie auch andere Browser verwenden HSTS-Preload-Listen. Damit wird die Limitierung des trust on first use-Prinzip für eine definierte Liste von Domains umgangen.
Listing 3: HSTS-Header
1
Strict-Transport-Security: max-age=31536000
Bypassing HSTS HSTS ist Zeit basiert und wird für eine gewisse Zeit definiert. Um dies zu umgehen,
wird die Zeit geändert, wodurch das HSTS abläuft und der Browser ohne warnung auf einen Fake
Server zugreift.
3.11
X-XSS-Protection
Dieser Header aktiviert den XSS-Schutz im Browser, jedoch kann dieser nur Reflected XSS erkennen. Bisher wird es nur von IE, Chrome und Safari unterstützt. In diesen Browser sollte er jedoch
standardmässig bereits aktiviert sein.
Listing 4: Beispiel des X-XSS-Protection Headers
1
X-XSS-Protection: 1; mode=block
3.12
HTTP Public Key Pinning - HPKP
Eine Erweiterung für HTTP, das dem Webclient mitteilt, einen spezifischen kryptographischen Schlüssel
mit einem bestimmten Webserver in Verbindung zu bringen. So sollen Man-in-the-Middle-Angriffe mit
gefälschten Zertifikaten vermieden werden.
Google Chrome wie auch Firefox verwenden Preload-Listen. Damit wird die Limitierung des trust
on first use-Prinzip für eine definierte Liste von Domains umgangen.
20
3.12
HTTP Public Key Pinning - HPKP
3
APPLICATION SECURITY BASICS
Listing 5: Beispiel des HPKP-Headers
1
Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [;
includeSubdomains][; report-uri="reportURI"]
21
4
4
OWASP TOP 10
OWASP Top 10
Die OWASP Top 10 sind die zehn wohl wichtigsten Schwachstellen von Anwendungen, welche aus
dem Open Web Application Security Project hervor ging.
Die aktuellste Version ist 2013 in Englisch1 erschienen und in mehrere Sprachen übersetzt, unter anderem auch Deutsch2 . Die hier aufgeführten Kurzbeschreibungen stammen ebenfalls aus der deutschen
Version.
4.1
Injection
Injection-Schwachstellen (SQL-, OS- oder LDAP-Injection) treten auf wenn nicht vertrauenswürdige
Daten als Teil eines Kommandos oder einer Abfrage von einem Interpreter verarbeitet werden. Ein
Angreifer kann Eingabedaten dann so manipulieren, dass er nicht vorgesehene Kommandos ausführen
oder unautorisiert auf Daten zugreifen kann.
4.2
Broken Authentication and Session management
Anwendungsfunktionen, die die Authentifizierung und das Session-Management umsetzen, werden oft
nicht korrekt implementiert. Dies erlaubt es Angreifern Passwörter oder Session-Token zu kompromittieren oder die Schwachstellen so auszunutzen, dass sie die Identität anderer Benutzer annehmen
können.
4.3
Cross-Site-Scripting - XSS
XSS-Schwachstellen treten auf, wenn eine Anwendung nicht vertrauenswürdige Daten entgegennimmt
und ohne entsprechende Validierung oder Umkodierung an einen Webbrowser sendet. XSS erlaubt
es einem Angreifer Scriptcode im Browser eines Opfers auszuführen und somit Benutzersitzungen zu
übernehmen, Seiteninhalte zu verändern oder den Benutzer auf bösartige Seiten umzuleiten.
4.4
Insecure Direct Object References
Unsichere direkte Objektreferenzen treten auf, wenn Entwickler Referenzen zu internen Implementierungsobjekten, wie Dateien, Ordner oder Datenbankschlüssel von aussen zugänglich machen. Ohne
Zugriffskontrolle oder anderen Schutz können Angreifer diese Referenzen manipulieren um unautorisiert Zugriff auf Daten zu erlangen.
4.5
Security Misconfiguration
Sicherheit erfordert die Festlegung und Umsetzung einer sicheren Konfiguration für Anwendungen,
Frameworks, Applikations-, Web- und Datenbankserver sowie deren Plattformen. Sicherheitseinstellungen müssen definiert, umgesetzt und gewartet werden, die Voreinstellungen sind oft unsicher. Des
Weiteren umfasst dies auch die regelmässige Aktualisierung aller Software.
4.6
Sensitive Data Exposure
Viele Anwendungen schützen sensible Daten, wie Kreditkartendaten oder Zugangsinformationen nicht
ausreichend. Angreifer können solche nicht angemessen geschützten Daten auslesen oder modifizieren
und mit ihnen weitere Straftaten, wie beispielsweise Kreditkartenbetrug, oder Identitätsdiebstahl begehen. Vertrauliche Daten benötigen zusätzlichen Schutz, wie z.B. Verschlüsselung während der Speicherung oder Übertragung sowie besondere Vorkehrungen beim Datenaustausch mit dem Browser.
1 http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf
2 https://www.owasp.org/images/4/42/OWASP_Top_10_2013_DE_Version_1_0.pdf
22
4.7
Missing Function Level Access Control
4.7
4
OWASP TOP 10
Missing Function Level Access Control
Die meisten betroffenen Anwendungen realisieren Zugriffsberechtigungen nur durch das Anzeigen oder
Ausblenden von Funktionen in der Benutzeroberfläche. Allerdings muss auch beim direkten Zugriff auf
eine geschützte Funktion eine Prüfung der Zugriffsberechtigung auf dem Server stattfinden, ansonsten
können Angreifer durch gezieltes Manipulieren von Anfragen ohne Autorisierung trotzdem auf diese
zugreifen.
4.8
Cross-Site Request Forgery - CSRF
Ein CSRF-Angriff bringt den Browser eines angemeldeten Benutzers dazu, einen manipulierten HTTPRequest an die verwundbare Anwendung zu senden. Session Cookies und andere Authentifizierungsinformationen werden dabei automatisch vom Browser mitgesendet. Dies erlaubt es dem Angreifer
Aktionen innerhalb der betroffen Anwendungen im Namen und Kontext des angegriffen Benutzers
auszuführen.
4.9
Using Components with Known Vulnerabilities
Komponenten wie z.B. Bibliotheken, Frameworks oder andere Softwaremodule werden meistens mit
vollen Berechtigungen ausgeführt. Wenn eine verwundbare Komponente ausgenutzt wird, kann ein
solcher Angriff zu schwerwiegendem Datenverlust oder bis zu einer Serverübernahme führen. Applikationen, die Komponenten mit bekannten Schwachstellen einsetzen, können Schutzmassnahmen
unterlaufen und so zahlreiche Angriffe und Auswirkungen ermöglichen.
4.10
Unvalidated Redirects and Forwards
Viele Anwendungen leiten Benutzer auf andere Seiten oder Anwendungen um oder weiter. Dabei
werden für die Bestimmung des Ziels oft nicht vertrauenswürdige Daten verwendet. Ohne eine entsprechende Prüfung können Angreifer ihre Opfer auf Phishing-Seiten oder Seiten mit Schadcode umoder weiterleiten.
23
5
5
IDENTITY AND ACCESS MANAGEMENT
Identity and Access Management
Unter Federated Identity Management gehören Abkommen, Standards und Technologien für
Identitäten und Berechtigungen portabel über autonome Identitätsdomänen. Die Föderation (Zusammenschluss) ermöglicht es, die Identitätsinformationen von verschiedenen Systemen transparent und
sicher auszutauschen, um damit auf Sicherheitsebene zusammenarbeiten zu können.
5.1
Authentication & Authorization Infrastructure - AAI
Ohne eine einheitliche AAI benötigt jede zu schützende Ressource eine separate Benutzer-Administration
und -Authentifikation. Probleme/Nachteile ohne AAI:
• Aufwändige und fehleranfällige Registration auf für jede einzelne Ressource
• Unzuverlässige und veraltete Daten
• Verschiedene Logins/Passwörter
• Gewisse Ressourcen werden gar nicht erst benötigt
• Ressorucen sind meist nur durch IP-Adressen geschützt
Mit einer AAI muss sich der Benutzer nur noch an einer Stelle Authentifizieren. Die Authentifizierung wird dann an den verschiedenen Ressourcen für die Autorisierung benötigt. Vorteile durch
AAI:
• Keine Registration pro Ressource nötig
• Einheitliche Login-Prozedur
• Neue Ressourcen können leicht hinzugefügt werden
• Standortunabhängig
• Weniger Kennwörter zu merken
Abbildung 10: Exemplarische Übersicht von AAI (Source: switch.ch/aai)
5.1.1
Shibboleth
Eines der weit verbreiteten AAI, welches die Authentifizierung von Classic Web-Services über die
Protokolle SOAP, XML und SAML übernimmt unter Verwendung von http.
Basiert auf SAML-Assertions (Security Assertion Markup Language) ausgestellt von vertrauten
24
5.1
AAI
5
IDENTITY AND ACCESS MANAGEMENT
Home-Organisationen (Identity Providers), welche von Ressourcen (Service Providers) aus dem
Verbund akzeptiert werden.
Abbildung 11: Vollständige Loginprozedur mit Shibboleth (Source: switch.ch/aai)
Ein Beispiel für AAI mittels Shibboleth ist das System von SWITCH für Universitäten, mit dem
man sich z.B. bei Unterrichtsplattformen oder Online-Shops mit dem Login der Uni-/Fachhochschule
anmelden kann.
Dieses System übermittelt zudem zusätzliche Attribute zum authentifizierten Benutzer, wie etwa
seine Mail-Adresse oder SwissEduPersonUniqueID.
Der Standard XML Signature Syntax and Processing erlaubt die Signierung, Integritätsprüfung
und Nachrichtenauthentifizierung.
Der Standard XML Encryption Syntax and Processing erlaubt die Verschlüsselung von Daten
(sogar teile des XML-Dokumentes) innerhalb eines XML-Dokumentes.
Der Standard Secure Assertion Markup Language 2.0 kombiniert den XML Signature Syntax
und XML Encryption Syntax in einem Dokument mit Authentifikation Attriuten und Autorisation.
Das resultierende XML-Dokument ist eine portable Identität für Single Sign-On Web Services.
Die Verwendung von SAML bringt als Vorteil mit sich, dass bestehende Enterprise-Anwendungen
direkt integriert werden können. Das zu grunde liegende XML bringt aber dennoch etwa 90% Overhead mit sichs.
Über die Architektur von SuisseID lässt sich so z.B. auch die Alters-Verifikation sicherstellen, da
für die Ausstellung eine Identitätsprüfung durchgeführt wird.
5.1.2
OAuth2
Wurde entworfen für neuere Protokolle wie REST und JSON, kommuniziert über https. Es gibt
keine eingebauten Sicherheits-Funktionen, diese wird komplett durch TLS (z.B. https) übernommen.
Die Funktionsweise ist vergleichbar mit Kerberos.
Resource Owner Benutzer
Resource Server Die API
Authorization Server Autorisiert den Benutzer, oftmals auf dem selben Server wie Resource Server.
25
5.1
AAI
5
IDENTITY AND ACCESS MANAGEMENT
Client Thirt-Party application, welche auf die API zugreifen möchte.
Abbildung 12: Beispiel eines Zugriffs auf geschützte Ressourcen mittels OAuth2
Man kann OAuth2 nicht als zuverlässige Benutzerauthentisierung zählen. OpenID connect versucht
aber diese Probleme zu lösen.
Jeder Anbieter setzt eine andere Versionen davon ein oder sogar eine eigene Implementierung.
5.1.3
OpenID Connect
• OpenID Connect 1.0 is a simple identity layer on top of OAuth 2.0.
• OpenID Connect 1.0 specifies a REST-based http API, using JSON as a data format..
• OpenID Connect 1.0 uses a JSON Web Token (JWT) which can be signed using JSON Web
Signature (JWS) and optionally encrypted using JSON Web Encryption (JWE).
• OpenID Connect 1.0 is used by Google+ Sign-In.
26
6
6
WEB ENTRY SERVER
Web Entry Server
Ohne Massnahmen werden mehrere Verbindungen direkt zu den Applikationsserver in der DMZ gemacht. Um dies zu verhindern wird eine Web Entry Server eingesetzt, welcher ein modifizierter
Apache Web Server ist.
Insgesamt kann dieser Server dann auch als Web Application Firewall (WAF) bezeichnet werden,
und folgende Funktionen übernehmen:
• Network Filter Level
• SSL Termination
• Protocol Validation and Rebuilding
• Character Encoding and Unicode Verficatoin
• White/Black List Filter
• Cookie Protection
• URL Encrypting
• Smart Form Protection
• Response Content Filter
• Response Rewriting
• Pre-Authentication
6.1
Reverse Proxy
Ein Reverse Proxy lädt Ressourcen für einen Client von mehreren Servern. Die Adressen der Zielsysteme bleiben für den Client dabei verborgen. Modul: mod proxy
6.2
Pre-Authentication
Der Zweck einer Pre-Authentication ist dass jegliche Backend Requests bereits authentifiziert
sind. Zudem werden forensische Log-Daten abgelegt.
6.2.1
Ablauf
1. Anfrage des Clients auf App wird auf Login Server redirected
2. Client erhält Cookie für Authentifizierungsprozess
3. Bei erfolgreichem Login erhält Client ein neues Cookie
4. Client verwendet Cookie für Zugriff auf Applikation
6.2.2
Zweck der Cookies
Bei den Cookies muss jeweils ein Zeitstempel und eine Zufallszahl (Nonce) enthalten sein, um Replay
Attacken zu verhindern.
Das zweite Cookie nach erfolgreicher Authentifizierung wird benötigt um gegen Session Fixation zu
wirken. Bei Session Fixation bringt der Attackierer einen Benutzer dazu, sich mit seiner Session ID
zu authentifizieren, welcher dann Zugriff auf die Applikation erhält.
Modul: mod but
6.3
Filtering
Der Web Entry Server übernimmt das Herausfiltern von unerwünschten Requests, z.B. SQL Injections,
und Responses, z.B. Stack Traces.
Modul: mod security
27
6.4
6.4
Unique ID
6
WEB ENTRY SERVER
Unique ID
Über Generierung und Weiterleitung einer Unique ID innerhalb aller Systeme lassen sich die verschiedenen Logfiles miteinander korrelieren. Man spricht dabei von der Forensic Readiness.
Module: mod unique id, mod headers.
6.5
URL Encryption
Bei der URL-Encryption wird die URL dynamisch verschlüsselt, um gegen manipulierte URLs zu
kämpfen (Forceful Browsing), um Parameter zu schützen, und Technologie und Topologie
zu verstecken.
6.6
Content Rewriting
Relative URLs sind generell kein Problem. Absolute URLs, die Cookie Domain und in manchen Fällen
die Werte der Cookies müssen jedoch ersetzt werden.
Modul: mod substitute
6.7
Session Store
Falls Anpassungen der Cookies bei einer Anwendung nicht möglich sind (HttpOnly, Secure), kann
die WAF hier einspringen. Sie weist dem Client eine ID zu, und speichert alle Session-Cookies der
Anwendung selber, anstatt sie an den Client weiterzuleiten. Bei einer Anfrage reichert die WAF
die Anfrage wieder mit dem passenden Session-Cookie an. Die Session-ID des Clients kann somit mit
weiteren Client-Eigenschaften verglichen werden (Sticky Sessions). Auch ermöglicht dies die zentrale
Verwaltung von Sessions, z.B. Session Expiration.
28
7
7
SERVER SECURITY
Server Security
Man sollte davon ausgehen, dass die verwendete Software Schwachstellen besitzt. Auch wenn diese
Schwachstellen nicht ausreichen, können sie dennoch als Sprungbrett für andere Angriffe verwendet
werden. Daher ist es zwingend Nötig, das System auf allen möglichen Ebenen zu Härten und damit
die Sicherheit zu erhöhen. Man spricht dabei von einer Multi-Defense Strategy.
Statistisch gesehen existiert für eine neu entdeckte Sicherheitslücke nach 6 Tagen ein Exploit und
erst nach 54 Tagen ein Patch. Oftmals ist Lesezugriff ausreichend, um einem Unternehmen Schaden zuzufügen oder daraus zu profitieren. Schreibzugriffe sind ebenfalls nicht zu vernachlässigen.
Besitzt der Angreifer Schreibzugriff, so kann er Anwendungen auf den Server laden und diese später
ausführen. Beispiel: PHP Shell.
7.1
7.1.1
Hardening
Während der Installation des Systems
• Minimales System
• Keine Standard-Pfade
• Separate Disk/Partition für log files
• Aktuellste Patches eingespielt
• Default Secure (Umask, Path)
• Verwendung eines Install Servers
7.1.2
Netzwerksicherheit
• Nur benötigte Dienste starten
• Least File Permissions für Dienste anwenden
• Least Process Privileges anwenden
• Standard-/Beispielinstallationen entfernen
• Banner Hiding (keine Versionsinformationen sichtbar)
• Error Handling (keine Fehlerdetails sichtbar nach aussen)
7.1.3
Authentifizierung
• Verwendung einer sicheren Authentifizierung (Benutzername, Kennwort, OTP, Client Certificate)
• Password Policy (Stärke, Gültigkeitsdauer, Kennwortwechsel, Erkennung von Attacken auf geknackte Passwörter)
7.1.4
Monitoring und Auditing
• Zeitsynchronisation
• Integritätstests
• Event handling (info, debug, error, panic, log)
• Forensic Readiness
• Remote Logging
29
7.2
Unix Process Security
7.2
7
SERVER SECURITY
Unix Process Security
Unter Linux ist ein weit verbreiteter Ansatz in der Prozess-Sicherheit die Isolierung durch Chroot
(change root). Dabei wird dem Prozess ein angegebenes Verzeichnis als Root vorgegaukelt. Innerhalb
des neuen Root-Verzeichnis befinden sich alle für den Service nötigen Dateien. Er kann dabei nicht
auf Dateien zugreifen, welche sich ausserhalb des neuen Root-Directories besitzen. Man spricht dabei
auch von einem Jail.
Durch Schwachstellen im Unix-Kernel ist es aber trotzdem möglich, aus diesem Jail auszubrechen.
7.3
File Permissions
Die Berechtigungen auf Dateisystemebene sollten so restriktiv wie möglich sein. Als Grundsatz gilt:
Never give “world“ write access. Dasselbe gilt für sensitive Informationen: Keep sensitive data
secure by removing read access from “world“.
Um die Standard-Berechtigungen unter Unix zu setzen, kann mit einer Maske gearbeitet werden. Diese
ist auch bekannt als “Umask“. Um die obigen Berechtigungen für den aktuellen Prozess zu ändern,
kann z.B. $ umask 027.
Durch dieses Vorgehen kann auch die Gefahr einer Local File Inclusion vermindert werden.
Abbildung 13: Beispiel der Berechtigungen für Apache und Tomcat
7.3.1
Apache File Permissions
• Im Besitz von Root
– Konfigurationsdateien
– SSL Schlüssel
– Log
– Html
• Eigentümer des Apache Prozess benötigt nur RO
30
7.4
Privilege Escalation
7
SERVER SECURITY
– Html
7.3.2
Tomcat File Permissions
Dies gestaltet sich oftmals schwierig, denn Tomcat besitzt eine andere Prozess-Architektur. Der Eigentümer des Tomcat-Prozess benötigt RW, für Remote Deployment, Konfiguration und Load Balancing.
7.4
Privilege Escalation
Dabei versteht man die Möglichkeit, die Berechtigungen des aktuellen Prozesses so zu verändern, dass
man Zugriff auf andere geschützte Elemente erhält. Dazu können z.B. Bugs in SetUID-Tools verwendet werden.
Aber auch CRON kann gefährlich sein, da die Prozesse als Root gestartet werden. Wenn nun ein von
CRON-Skript “world-writeable“ ist, kann somit schnell etwas mit höchsten Berechtigungen ausgeführt
werden.
7.5
Network Hardening
Nur die nötigsten Dienste sollten gegen Anfragen von aussen reagieren. Alle anderen müssen an
localhost gebunden sein. Alternativ kann auch eine Firewall dafür eingesetzt werden.
Dienste wie UPNP, Bonjour / Zeroconf und DLNA sollten aufgrund ihrer grossen Attach-Surface auch
deaktiviert werden. Dies stammt daher, dass oftmals die Geräte unzureichende Authentifizierungsmechanismen implementiert haben.
Es wird in den Folien auch von der Verwendung von IPv6 abgeraten.
ICMP-Redirects deaktivieren, um MITM-Attacken vorzubeugen.
Eine Analyse mittels Nmap oder Lynis von Cisofy3 helfen, Schwachstellen aufzudecken.
7.6
DB Hardening
Wie auf das Dateisystem trifft das Prinzip Least Privileges auch auf die Datenbank zu. Der in der
Anwendung hinterlegte Benutzer darf nur auf seine Datenbanken Berechtigungen erhalten. Es können
in einer Anwendung auch mehrere Benutzer hinterlegt werden, mit unterschiedlichen Berechtigungen.
So z.B. ein Benutzer nur mit SELECT -Permissions für Abfragen, INSERT und UPDATE für Bestellungen und ein CREATE, DELETE für den DB-Admin.
Keinesfalls sollte der Applikations-User GRANT -Permissions erhalten.
3 https://cisofy.com/lynis/
31
8
8
8.1
MOBILE APPLICATION SECURITY
Mobile Application Security
iOS
Basierend auf OSX hat Apple das iOS lanciert. Dabei wurde Objective-C, Swift, und C verwendet.
iOS verfügt über Sandbox Mechanismen, ein Data Protection API, Code Signing und den Appstore
mit manueller Freischaltung.
Abbildung 14: iOS Data Protection API
Bei iOS ist das Permission Model so eingerichtet, dass bei jeder Verwendung nach Erlaubnis gefragt
wird und individuell erlaubt oder abgelehnt werden kann.
8.2
Android
Auf Linux basierend in Java und C entstand Andoid, welches von verschiedene Hardware-Anbietern
übernommen wurde. Somit hat es auch noch viele alte Versionen auf dem Markt.
Android unterstützt SD Karten, Sandboxing via JVMs, Code Signing, und mehrere verschiedene
Appstores.
Die App Permissions sind bei Android im Manifest hinterlegt und können ab Android 6 individuell
angenommen oder abgelehnt werden.
8.3
Windows Phone
Windows Phone von Microsoft unterstützt ebenfalls strict sandboxing, Address Space Layout Randomization (ASLR, zufällige Ladeposition von Programmen in Speicher als Schutz gegen Overflow),
Bit Locker Verschlüsselung, Data Protection API (ähnlich wie bei iOS), aber auch Gefahren wie automatisches Wi-Fi credential sharing über Facebook, Outlook oder Skype. (In Version 1607 wurde die
umstrittene Funktion Wi-Fi Sense wieder entfernt.)
8.4
Xamarin
Xamarin ermöglicht die Entwicklung von platformübergreifenden, nativen Apps. Dabei wird das Mono
Framework (.NET kompatibel) verwendet und in C# programmiert, welches zu IL-Code (Microsoft
Intermediate Language) kompiliert wird.
Die native APIs werden zwar zu den .NET namespaces gemapped, jedoch müssen platformabhängige
Security Features sowie User Interfaces immer noch für jede Platform geschrieben werden.
8.5
Cordova (Phonegap)
Cordova wird verwendet um Mobile Apps mit HTML, JS und CSS zu entwickeln. Es bringt somit
native Funktionalität, basiert aber auf Web View Komponente. Somit fallen jedoch auch alle bekannten
Schwachstellen an.
32
9
9
OWASP MOBILE TOP 10
OWASP Mobile Top 10
Abbildung 15: OWASP Mobile Top 10, 2016
9.1
M1: Improper Platform Usage
Missbrauch eines Platform Features oder fehlende Sicherheitsmassnahmen, und das somitige Verletzten von Guidelines.
Beispiel: Zu viele Permissions, unverschlüsseltes Ablegen von Credentials in Property-File anstelle
der KeyChain (iOS).
Lösung: Konsultieren der Platform Guidelines beim Entwickeln.
9.2
M2: Insecure Data Storage
Durch Ablegen von Daten in unsicherem Speicher oder unvorhergesehenem Datenleak (siehe Unterkapitel) besteht erhöhte Gefahr wenn das Gerät gestohlen wird/verloren geht oder mit Malware infiziert
ist nach jailbreak/rooting.
9.2.1
System Screenshots
Das Betriebssystem erstellt ein Screenshot der Anwendung, um diese unter den zuletzt verwendeten
Anwendungen darzustellen. Manchmal aber auch in anderen Fällen.
Beispiel: E-Banking Kontoinformationen können eingesehen werden über den Screenshot des Apps.
Lösung: Screenshots vom System unterbinden oder sensitiven Daten überdecken.
Listing 6: Lösung für iOS
1
2
3
(void) applicationDidEnterBackground:(UIApplication *)application{
// mask the sensitive data or add an additional layer on top
}
Listing 7: Lösung für Android
1
window.addFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
9.2.2
Keyboard
Viele Keyboards verfügen über Autocomplete. Das iOS zum Beispiel speichert bis zu 500 Wörter.
33
9.2
M2: Insecure Data Storage
9
OWASP MOBILE TOP 10
Beispiel: Passwort Feld unterstütz Autocomplete; Das Passwort wird somit auch an anderen Stellen
vorgeschlagen wenn mit dem selben Buchstaben begonnen wird.
Lösung: Autocomplete bei sensitiven Daten deaktivieren.
Listing 8: Lösung für iOS
1
2
theTextField.secureEntry = YES;
theTextField.autocorrectionType = UITextAutocorrectionTypeNo;
Listing 9: Lösung für Android
1
android:inputType="textNoSuggestions";
9.2.3
Clipboard
Standardmässig wird ein globales Clipboard für Copy & Paste verwendet, und jedes App kann darauf
zugreifen.
Beispiel: Sensitive Daten befinden sich noch im Clipboard aus der E-Banking App.
Lösung: Clipboard leeren oder ein dediziertes Clipboard verwenden.
Listing 10: Lösung für iOS
1
UIPasteBoard *uniqueBoard=[UIPasteboard pasteboardWithUniqueName];
9.2.4
Logs
Crash- und Applikationslogs können sensitive Daten enthalten. Im Apple System Log (ASL) bei iOS
werden sogar alle Logs gecached bis zum nächsten Reboot und auch nicht sandboxed. Bei Android
müssen Debug Logs bei der finalen App deaktivieren werden.
Beispiel: Bei gescheitertem Loginversuch speichert das Log Benutzername und Passwort im Log.
Lösung: Dedizierter Logger für Debug Build der App.
9.2.5
Web Data
Eine WebView speichert jegliche Daten wie ein konventioneller Web Browser. Dies umfasst ein Web
Cache, lokaler Speicher, Cookies, Passwörter die direkt oder in eine Sqlite Datenbank gespeichert
werden.
Beispiel: Ablegen von unverschlüsselten Passwörtern und Benutzernamen in Sqlite Datenbank.
Lösung: Korrekte Systemspeicher verwenden.
9.2.6
Inter-Process Communication
Apps können URL Handlers registrieren, wobei der Empfänger und die überlieferten Informationen
nicht geprüft werden können. Zudem entsteht ein Problem wenn mehrere Apps für ein Handler bestehen. Bei Android kann dann die aufzurufende Applikation gewählt werden, bei iOS wird die zuletzt
installierte App automatisch ausgewählt.
Beispiel: Sensitive Daten werden bei Aufruf über einen Handler abgefangen.
Listing 11: Aufruf von Skype
1
skype://090012312312?call
Lösung: Bei Android direkter Aufruf eines Intent aus der anderen App.
34
9.3
M3: Insecure Communication
9.3
9
OWASP MOBILE TOP 10
M3: Insecure Communication
Das Verwenden von inkorrekten oder alten SSL Versionen, schwache Protokollaushandlung oder einfach Plain Text Kommunikation.
Ab iOS 9 wurde mit App Transport Security durch mimimum Anforderungen eingeführt (TLS 1.2
mit PFS, Zertifikat und SHA-256 Signatur, 2048-bit RSA oder 256-EC Key). Apps unterstehen diesen
Vorbestimmungen oder müssen explizite Ausnahmen definieren.
9.3.1
Certificate Pinning
Standardmässig wird bestimmten Certificate Authorities (CA) vertraut. Deren Root Zertifikate sind
auf jedem Gerät vorinstalliert.
Beispiel: Die CA wurde gehacked oder ein Attackierer hat dem Gerät eine falsche CA hinzugefügt.
Lösung: Certificate Pinning, eingeführt durch Google Chrome. Speichert das Zertifikat oder dessen
Public Key in der App und überprüft dieses.
9.4
M4: Insecure Authentication
Das Verletzten von Privacy durch Mitschicken von Gerät-spezifischen Daten, spoofing, vohersehbare
Session IDs, oder kein Session Timeout.
9.5
M5: Insufficient Cryptography
Schwache Ciphers und/oder Keys, ungeschützte Keys in App, oder sebstgemachte Bastel-Krypto.
Android besitzt die Bouncy Castle Library. Alternativ kann dieses auch in die App eingebunden werden als Klon, welches dann Spongycastle genannt wird.
iOS hat das Common Crypto API CCCRypt. Die KeyChain kann zudem für asymmetrische Kryptographie verwendet werden. Alternativ kann OpenSSL verwendet werden.
9.6
M6: Insecure Authorization
Das authorisieren von unerlaubten Benutzern oder Methoden ausführen von zu wenig authorisierten
Benutzern. Ein klassisches Beispiel ist Forced Browsing.
9.7
M7: Client Code Quality
Implementationsprobleme wie Buffer Overflows, XSS, format string Schwachstellen etc. Muss im Code
selbst gefixed werden.
9.8
M8: Code Tampering
Es besteht die Möglichkeit dass Code selbst verändert oder ausgetauscht wird. Dazu gibt es mehrere
Möglichkeiten:
Binary/Monkey Patching Runtime Patch ohne Kopie des originalen Source Codes.
Resource Modification Manipulation von lokalen Ressource-Files, welche z.B. URLs beinhalten.
Method Hooking Bei erweiterbaren Frameworks das missbrauchen von Hooks für eigene Zwecke.
Method Swizzling Implementation zweier Methoden austauschen.
Jailbreak/Rooting Root Access zu System, kann aber anhand von Filestrukturen, Libraries oder
OS-abhängigen Merkmalen erkannt werden.
35
9.9
M9: Reverse Engineering
9.9
9
OWASP MOBILE TOP 10
M9: Reverse Engineering
Der Code kann eingesehen werden durch Binary Inspection, Dissasembly oder geleaktem Source Code.
Gegen die ersten zwei kann ein Code Obfuscator verwendet werden, wie etwa ProGuard im Android
SDK. Grundsatz: Verlass dich nicht auf Security by Obscurity.
9.10
M10: Extraneous Functionality
Schwachstellen wie Backdoors für die Entwickler, Funktionen die nicht für den Release gedacht wurden
sondern lediglich für Tests, oder Passwörter in Kommentaren.
9.11
Checkliste
• Data at Rest
– iOS: DataProtection
– Keychain API
– Backup Exclusion
– Caching
• Data in Motion
– Certificate Pinning
– Transport Security
• Data Leakage
– Prevent side-channel leakage: logs, keyboard, screenshots...
• Input Validation
– Input sanitization e.g. URL handler parameters
– Format strings
• Code Protections
– Code Obfuscation
– Stack protection
– Anti-Debug controls
– Compiler settings
– Code Injection Checks
• Web View Hardening
– Disable local file access
– Disable plugins
– Disable javascript
– URL whitelisting
• Environment integrity
– Jailbreak / Rooting detection
– Version control / mandatory updates
36
10
10
FRAUD DETECTION
Fraud Detection
Fraud Detection beschreibt das Vorgehen um Betrugsfälle, wie zum Beispiel beim E-Banking, möglichst
schnell zu erkennen und zu melden. Dabei wird der Computer als Hilfsmittel verwendet. Bis jetzt ist
die Quote der gefundenen Fälle per Fraud Detection noch sehr gering. Weit über die Hälfte der Fälle
werden durch Hinweise oder ein Management Review gefunden.
10.1
Panopticlick / Client Correlator
Panopticlick ist ein Softwareprojekt der Electronic Frontier Foundation (EFF). Das Konzept hinter
der Software liegt darin, den Benutzer bei Besuch einer Webseite zu identifizieren, ohne dass dieser
sich authentifizieren muss. Dafür wird ein Javascript auf dem Client ausgeführt, welches Informationen
über den Browser sammelt. Daraus wird eine CCID (Client Correlation ID) generiert. Diese wird auf
dem Server mit bisherigen CCIDs verglichen. Somit kann man feststellen ob der Request von einem
bereits bekannten Gerät kommt oder nicht. Um den Fingerprint des Browsers zu erstellen werden
unter anderem folgende Daten einbezogen:
• Verschlüsselte IP
• Installierte Fonts
• Installierte Plugins
• Screen Resolution
• Name des OS
• User Agent String
10.2
E-Banking
E-Banking Systeme Verwenden zwei unterscheidliche Informationstypen um allfällige Frauds zu erkennen. Sollte bei der Überprüfung ein Verdacht auftauchen, kann die Transaktion gesperrt oder zum
Beispiel per Telefon vom User bestätigt werden.
10.2.1
Technische Daten
Die Technischen Daten werden aus der Session gelesen. Die ausgelesenen Daten werden gegen alte
gesammelte Daten verglichen. Unter Anderem werden folgende Daten verwendet:
• User Agent
• Source IP
• Zeit
• Tippgeschwindigkeit
• Durchschnittliche eingeloggte Zeit
10.2.2
Business Informationen
Bei den Business Informationen geht es um die getätigte Transaktion selber. Aufgrund dieser Daten
könnte eine Fraud Transaction eventuell erkannt werden. folgende Punkte werden untersucht:
• Betrag
• erstmalige Zahlung
• An welche Bank geht die Zahlung (Inland / Ausland)
10.3
Data Mining
Data Mining beschreibt den Vorgang, um aus riesigen Mengen von Daten und Datensätzen, die wichtigen Informationen und zusammenhänge herauszufiltern. Diese Fähigkeit, wichtige Informationen aus
einer grossen Masse zu filtern, ist besonders für Vorhersagen oder Machine Learning interessant. Durch
37
10.4
Machine Learning
10
FRAUD DETECTION
Data Mining werden die Daten in Gruppen unterteilt. Drei Common Tasks sind besonders nützlich
für Fraud Detection:
• Classification: Predictive, Kunden mit einer guten Kreditwürdigkeit suchen zum Beispiel
• Clustering: Descriptive, Alle Kunden mit ähnlichem Einkaufsverhalten gruppieren
• Association Rules: Artikel finden die oft mit dem gekauften zusammen gekauft werden
10.4
Machine Learning
Aufgrund der Informationen aus den Data Minings können Machine Learning Algorithmen eingesetzt
werden, um zum Beispiel eine Transaktion als Verdächtig oder Harmlos einzustufen. Dies geschieht
immer aufgrund bisher erhaltenen Transaktionen. Der Input (Neue Transaktion) wird also nacher als
Richtwert für die nachfolgenden Transaktionen verwendet. So lernt der Automat dann von alleine. In
der Vorlesung wurden verschiedene Algorithmen aufgezeigt:
• Dempster–Shafer Theory
• BLAST-SSAHA Hybridization
• Hidden Markov Model
• Evolutionary-fuzzy System
10.5
Vorteile / Nachteile
Die aufgezeigten Systeme können bereits automatisiert betrügerische Zahlungen erkennen und diese
Melden, damit sie z.B. durch ein Mensch weiterverarbeitet werden. Je mehr Daten über den eigentlichen Benutzer zur verfügung stehen, umso besser funktioniert das ganze System. Ein automatisches
System kann schneller reagieren und den Betrüger bereits stoppen, bevor ein Schaden entstanden ist.
Diese Fraud-Detection bringt jedoch viele Nachteile mit sich. Es ist es sehr aufwändig, ein solches
System einzurichten und zu Betreiben. Damit sind grosse Kosten verbunden, denn es existieren kaum
standardisierte Lösungen und auch keine ausgearbeiteten Konzepte. Zudem liefert es immer noch viele
False Positives. Daher wird der Mensch wohl weiterhin eine zentrale Rolle spielen.
38
11
11
11.1
SECURITY TESTING
Security Testing
Notwendigkeit
Die Bedrohung von Informationssystemen ist allgegenwärtig und man kann jederzeit ein Ziel eines
Angriffes werden. Auch aus der Sicht der Beteiligten gibt es viele verschiedene Risiken, welche als
Treiber für ein Security Testing dienen.
Rollen
Risiken
Firmeninhaber, -Teilhaber
Finanzielle Risiken, Verlust von Assets, Reputationsrisiko
Aufsicht, Regulatoren
Schädigung des Wirtschaftsplatzes, Reputationsrisiko
Verwaltung, Schulen
Druck der Aufsichtsbehörde
Entwickler, Ingenieure, Forscher
Know-How Abfluss
Sicherheitsverantwortliche
Jobverlust
Kunden, Nutzer
Persönlichkeitsschutz (Datenschutz, Finanzielle Risiken)
Tabelle 3: Risiko der Beteiligten in verschiedenen Rollen
Bei einer Sicherheitsprüfung muss die Bedeutung aller Ebenen (Prozess-, Applikations- und InfrastrukturEbene) beurteilt werden. Es muss sichergestellt werden, dass der Prüfbereich sinnvoll (in Abhängigkeit
der Risikoeinschätzung) festgelegt wird.
Neben den Risiken gibt es auch noch andere Motivationen zur Durchführung von Sicherheitstests:
• Firmen interne Anforderungen
– Sicherheitsprüfung im Rahmen von Projekt-Abnahmen durch externe Firmen.
– Sicherheitssensitive Unternehmen verlangen Sicherheitstests für aus dem Internet erreichbare Systeme.
– Nachweis von sicherheitsrelevanten Bedenken.
– Nachweis von Handlungsbedarf (Budgetbeschaffung).
• Qualitätsnachweis
– Zertifizierung
• Regulatorische Anforderungen
– Regelmässige Überprüfung der Systeme und Prozesse durch unabhängige Prüfinstitute. Oft
bei Finanzinstituten wie Banken, Versicherungen und Kreditkarten-Unternehmen.
• Sicherheitsrelevante Zwischenfälle
11.2
Begriffe
Sicherheitsprüfung Allgemeine Bezeichnung für die Beurteilung einer oder mehrerer Komponenten
(Systeme oder Prozesse) bezüglich Sicherheit.
Security Audit Untersuchungsverfahren die dazu dienen, Prozesse hinsichtlich der Erfüllung von
Anforderungen und Richtlinien (z.B. Standards) zu bewerten.
Review Beurteilung von Software oder von Komponenten.
Penetration Test Überprüfung der Sicherheit von Systemen und Anwendungen (Netzwerkkomponenten, Server, Softwarekomponenten) mit Mitteln und Methoden, die ein Angreifer anwenden würde, um unautorisiert in das System einzudringen (Penetration).
White-Box-Test Methode des Software-Tests, bei der die Tests mit Kenntnissen über die innere
Funktionsweise des zu testenden Systems entwickelt werden.
39
11.3
Vorgehen bei der Sicherheitsprüfung
11
SECURITY TESTING
Black-Box-Test Im Gegensatz zum White Box Test besitzt man hier keine Kenntnis über die innere
Funktionsweise, dieses muss erarbeitet werden. Das Hauptaugenmerk liegt auf den Anforderungen des Tests und nicht auf der Implementation.
Gray-Box-Test Dies ist eine Kombination aus Black- und White-Box-Test. Der Tester besitzt teilweise Informationen über das System und die verwendeten Algorithmen.
Social Engineering Dabei wird der Mensch als Schwachstelle des Informationssystems angesehen
und ausgenutzt. Oftmals ist dies die einfachste Variante.
False Positive Der Test ergibt ein positives Resultat, obwohl keine Gefahr besteht.
False Negative Dies ist ein Trugschluss von nicht vorhandener Sicherheit. Dies geschieht, wenn der
Test Entwarnung gibt, obwohl das System verwundbar ist.
Plausibilisierung Verifiziert nicht die Richtigkeit eines Ergebnisses, zeigt aber offensichtliche Unrichtigkeit auf.
Inspektion Die Inspektion dient der Feststellung des ordnungsgemässen Zustandes eines Gegenstandes, eines Sachverhaltes oder einer Einrichtung. Die korrekte Funktion wird dabei üblicherweise
nicht verifiziert.
Prüfung Beurteilung einer Leistung. Der zu prüfende Bereich oder Gegenstand wird gegen einen
definierten und erwarteten Zustand, Funktion verifiziert.
11.3
Vorgehen bei der Sicherheitsprüfung
Schritt
Aktionen → Resultat
Scoping
Erkennen von Hanldungsbedarf, Risiko-Analyse, Erteilung Prüfauftrag, Offertenstellung, Prüfplanung → Scope
Analyse
Bestandesaufnahme, Funktionen analysieren, Dokumentstudium → Testplan
Stärken und Schwächen
Konzeptbeurteilung
Konzept beurteilen → Stärken und Schwächen des Konzeptes
Verifikation
Detailierte Testplanung, Manuelle und automatisierte Tests durchführen,
Design und Aufbau bewerten → Mängel, Empfehlungen, Risiken
Dokumentation
Reports erstellen, Resultate mit Kunden abgleichen, Ergebnisse Präsentieren
→ Formeller Bericht
Nachprüfung
Verifikation von getroffenen Massnahmen → Aktualisierte Beurteilung
Tabelle 4: Übersicht über die einzelnen Schritte
40
12
12
12.1
SPEZIALTHEMEN
Spezialthemen
XXE File Inclusion
Unter dem Begriff ist eine Attacke über das XML External Entity Processing möglich. Dabei können
externe Daten, wie z.B. lokale Dateien, in das XML inkludiert werden. Bei der Verarbeitung solcher
Inclusions, welche im DTD angegeben sind, fügt sie der Parser in die angegebenen Stelle ein.
Lösung: Deaktivierung des Features für DTDs (External Entities) beim Parser.
Listing 12: Beispiel der XXE
1
2
3
4
5
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
12.2
JSON-Hijacking
JSON-Hijacking zielt darauf ab, sensitive Daten, die mittels JSON Format an einen authentifizierten
Empfänger übermittelt werden, zu stehlen. Dabei präpariert der Angreifer eine Seite mit einem JavaScript, welches die Callback-Funktion oder den Property Setter überschreibt. Als zweites wird ein GET
Request auf die verwundbare Seite durchgeführt. Die Response kann dann vom Angreifer verarbeitet
werden und die Daten (möglicherweise sensitive Informationen) auf seinem System speichern.
Lösung:
• Token in Request URLs verwenden, sodass diese nicht erraten werden können
• JSON Response mit einem Infinite Loop beginnen
• JSONP vermeiden
• Arrays in ein JSON-Objekt einbetten
12.3
URL-Redirection
URL-Redirection wird häufig im Zusammenhang mit Phishing verwendet, mit dem Ziel, eine Session
übernehmen zu können. Dazu wird dem Opfer einen Link untergeschoben, der auf den ersten Blick vertrauenswürdig aussieht. In Wirklichkeit enthält dieser jedoch einen Redirect auf eine Landing-Page des
Hackers. Klickt das Opfer auf diesen Link, so wird normal das Login-Formular der vertrauenswürdigen
Webseite geladen. Gibt das Opfer nun seine Credentials ein, werden diese auf Korrektheit geprüft und
es wird eine Session ausgestellt. Nach dem erfolgreichen Login, wird nun durch Redirection nicht die
vertrauenswürdige Webseite geladen, sondern die Landing-Page des Hackers. Dadurch sieht der Hacker im Log seiner Page die ausgestellte Session und kann diese übernehmen. Das Opfer selbst erhält
nur eine Meldung, dass die gewünschte Seite nicht erreichbar ist.
Beispiel: http://www.example.com/login?redirect=http://www.hack.er
Lösung:
• Inputvalidierung
– Parameter die Redirect URLS enthalten validieren
– Prüfen ob URL wirklich zur Seite gehört
• Lookup Tables
– Erstellen von Mappings zwischen Parameter und URL
– redirect=1
41
12.4
HTTP Request Smuggling
12
SPEZIALTHEMEN
– redirect=acc
12.4
HTTP Request Smuggling
HTTP Request Smuggling Attacken werden benutzt, um beispielsweise WAFs zu umgehen. Dabei
wird die Schwachstelle ausgenutzt, dass verschiedene Sicherheitssysteme HTTP Requests unterschiedlich interpretieren. Beispielsweise kann mit CR/LF (Carriage Return / Line Feed) erreicht werden,
dass innerhalb eines einzigen Requests sich zwei Requests befinden. Die WAF erkennt nur den einen,
der dahinter verborgene Webserver antwortet jedoch auf beide Requests. Somit können Informationen, die eigentlich nur zwischen WAF und Webserver sichtbar sein sollten, nach “aussen“ gelangen.
Beispielsweise ein Cookie welches zwischen WAF und Webserver einen User authentifiziert.
Oftmals werden die Felder Location und Set-Cookie als Ziel verwendet. Übliche Escape-Sequenzen
sind: %0a %0d %0a%0d %0d%0a
Listing 13: Beispiel eines Präparierten Request zur Umgehung einer Pre-Authentication
1
username=hacker10&url=%2Fsecure%0aSet-Cookie:LOGON=OK;
%0aSet-Cookie:MOD_BUT_Username=admin;&lang=EN&password=compass
Lösung:
• Web Application Firewalls verwenden, die nicht verwundbar gegen HTTP Request Smuggling
sind.
• Strenges Sessionmanagement verwenden, z.B Session nach jedem Request terminieren.
• Aktivieren von Strict Parsing beim Webserver, z.B. Apache.
12.5
Session Fixation
Bei einer Session Fixation Attacke erzeugt der Hacker bei der verwundbaren Webseite eine Session
(ohne Login). Diese Session wird nun dem Opfer mit einem Link mitgeteilt. Das Opfer authentifiziert
sich auf der Webseite unter Verwendung dieser Session und ermöglicht es somit dem Hacker, die
authentifizierte Session zu benützen.
12.6
12.6.1
SSL/TLS: SSL-Cipher-Suite-Hardening, SSL-MitM
Apache SSL Cipher Hardening
Der Nachteil des Apache SSL Cipher Hardening ist, dass der Benutzer eine unfreundliche ErrorNachricht erhält, falls dieser den Angeforderten SSL Cipher nicht unterstützt.
• SSLProtocol
– Definiert, welche protokolle akzeptiert werden
• SSL-Cipher-Suite-Hardening
– Definiert, welche SSL-Cipher akzeptiert wird
• SSLHonorCipherOrder
– Die Server SSL-Cipher Suit hat mehr priorität als die des Clients.
42
12.6
SSL/TLS: SSL-Cipher-Suite-Hardening, SSL-MitM
12
SPEZIALTHEMEN
Abbildung 16: Apache SSL Configuraiton
12.6.2
Apache SSL Cipher Forwarding
Der Vorteil dieser Variante ist, dass auch ältere Browsers sich mit der Applikation verbinden können,
da der Apache alle Ciphers akzeptiert.
Apache leitet dann die SSL Informationen zu der Applikation, via dem mod header weiter, welche
dann den Entscheid für die entsprechende SSL Cipher Suit macht.
• Applikation muss die Cipher prüfen
• Bei Änderungen oder neuen Cipher muss die Applikation neu konfiguriert werden.
43