Wer sind die Angreifer im Netz, was sind Ihre Ziele und gegen welche Arten von Attacken muss ich mich wappnen?
Es gilt immensen Schaden abzuwenden und das Vertrauen der Nutzer in Ihre Plattform zu gewinnen und zu bewahren.
16. Top 10 Online Gefahren
Injection
Cross Site Scripting (XSS)
Broken Authentication and Session Management
Insecure Direct Object References
Cross Site Request Forgery (CSRF)
Security Misconfiguration
Insecure Cryptographic Storage
Failure to Restrict URL Access
Insufficient Transport Layer Protection
Unvalidated Redirects and Forwards
17. 10) Unvalidated Redirects and Forwards
In Webapplikationen kommt es h aufig zu Weiterleitungen zu anderen
Webseiten. Oft werden hierbei uber die Url mitgegebene Parameter
genommen um die Zieladresse zu ermitteln.
Gefahr:
Angreifer kann dadurch das Opfer auf Malware- oder Phishing-Seiten
weiterleiten
Umgehung von Authorisierungsmaßnahmen
http://example.org/redirect.php?url=http://evil.org
Maßnahmen:
Möglichst keine Urls aus User Parametern übernehmen
Input Validierug / White-Listing
18. 9) Insufficient Transport Layer Protection
Bei Web Applikationen wird der Netzwerkverkehr nicht mittels Verschlüsselung
geschützt, auch wenn sensible Daten übertragen
werden.
Gefahr:
Angreifer kann vertrauliche Informationen mitlesen oder verändern
(Gesundheitsdaten, Kreditkartennummern, Passwörter, geheime
Firmendaten...)
Maßnahmen:
SSL
Verschlüsseln und Signieren der Daten vor der Übertragung
19. 8) Failure to Restrict URL Access
Typische Fehler:
Es werden nur bestimmte Links und Menü-Punkte angezeigt, die anderen
werden versteckt (Security by Obscurity)
Presentation Layer Access Control: Keine Überprüfung am Server
Gefahr:
Angreifer kann Funktionen aufrufen, für die er nicht berechtigt ist
http://www.the-online-bank.com/user/getAccountData
http://www.the-online-bank.com/admin/getAccountData
Maßnahmen:
Für jede Url sicherstellen, dass der User für den Zugriff authorisiert ist
Auf bestimmten Seiten ist überhaupt kein Zugriff möglich
(Config-Files, Log-Files, etc.)
20. 7) Insecure Cryptographic Storage
Das Problem liegt oft darin festzustellen, was sensible Daten sind und wo diese
überall gespeichert sind (Logfiles, Backups...)
Gefahr:
Angreifer hat Zugriff auf sensible Daten und kann diese verändern
Maßnahmen:
Verschlüsselung (Datenbanken, Files ...) mit Standardalgorithmen
Schlüssel schützen
21. 6) Security Misconfiguration
Die Sicherheit der Web Applikation hängt von den darunterliegenden Schichten
ab. Wichtig ist hierbei die Installation der aktuellen Patches.
Gefahr:
Sicherheitslücken ausnutzen, da keine Patches installiert wurden
Standard Passwörter zu Default Accounts
Unautorisierten Zugriff auf Funktionalität durch schlechte
Server Konfiguration#
Maßnahmen:
Hardening Prozess definieren
22. 5) Cross Site Request Forgery (CSRF)
1. Angreifer sendet präparierte URL an Benutzer durch zusätzlichen
Kanal (z.B. E-Mail)
2. Benutzer ruft Seite im Browser auf. Server führt Aktion direkt aus
3. Dieser Punkt ist je nach Angriff optional. Zum Beispiel bei
Passwortänderungen greift der Angreifer mit dieser Information auf den
Server zu. Bei Aktionen ohne weiteren Zugriff des Angreifers (z.B.
Überweisungen) ist dieser Punkt nicht mehr notwendig
23. 5) Cross Site Request Forgery (CSRF)
CSRF: Missbrauch des Vertrauens der Applikation gegen uber Benutzer
Durch untergeschobene präparierte URL kann ein Angreifer einen
Benutzer zu einer Aktion am Server missbrauchen – die Daten für die Authentisierung (Session
Cookie, IP Adresse, SSL Zertifikate des Clients, etc.) werden automatisch mitgeschickt
Gefahr:
Der Angreifer kann alles machen, das der Benutzer auch kann. (Account
löschen, Logout, Überweisung machen etc.)
http://server/changePassword.php?newPassword=angreifer“
Maßnahmen
Ein (zufälliger) geheimer Token, der nicht automatisch übertragen wird, zu allen kritischen Requests
hinzufügen. Dieser Token (SharedSecret) ist nur dem Client und dem Server bekannt. Bei jeder
Anfrage vom Client wird dieser Token dem Server übermittelt.
<i n p u t name=”token ” v a l u e=”134 awe r i o a s d f 1 2 ”
type=”hidden ”/>
Bei unverschlüsselter Kommunikation kann ein Angreifer diesen Token stehlen
Verifizierung der Aktion durch Benutzer anfordern
“Möchten Sie wirklich Ihr ...?”
24. 4) Insecure Direct Object References
Ähnlich zu “Failure to Restrict URL Access”
Typische Fehler:
Es werden nur bestimmte Objekte angezeigt, die anderen werden versteckt
Presentation Layer Access Control: Keine Überprüfung auf Server-Seite
Gefahr:
Angreifer wird ähnliche Nummern ausprobieren:
www.example-bank.com?account=100
www.example-bank.com?account=102
www.example-bank.com?account=104
Maßnahmen:
Keine direkte Referenz auf Objekte - nur ein zufälliger,
Temporärer Mapping-Value
Statt ?account=100 – ?account=8w9e9fgi
Statt ?file=accounting.xls – ?file=119347
Überprüfung der Objekt Referenzen: Formatierung, ob der User die Berechtigung
hat zuzugreifen, etc.
25. 3) Broken Authentication and Session Management
Zur Erinnerung: HTTP ist ein stateless Protokoll
Die SessionID wird verwendet um den Status des Users festzuhalten
Gefahr:
Session Hijacking – Beispiel: Firesheep
User Accounts übernehmen
Aber auch die Funktionen: Passwort ändern, Sicherheitsfrage, Passwort
vergessen, etc.
Maßnahmen:
Verwendung von SSL und Sicherstellung, dass die SessionID immer durch
SSL geschützt ist
Sicherstellen, dass ein logout wirklich die Session zerstört
26. 2) Cross-Site Scripting (XSS)
Unvalidierter Benutzerinput wird genommen und ausgegeben
<s c r i p t >a l e r t (” x s s ”);</ s c r i p t >
Ausführung des Codes durch vertrauenswürdigen Server. Zertifikate und
Verschlüsselung der Kommunikation zwischen Server und Benutzer bieten
keinen Schutz.
Der eingeschleuste Code wird direkt von der vertrauten Domäne
ausgeführt.
Arten:
Reflected XSS
Stored XSS
27. 2) Cross Site Scripting (XSS)
”Reflected“
HEISE Security - News vom 22.3.2012
XSS Angriff durchgeführt auf https://www.paypal.com
28. 2) Cross-Site Scripting (XSS)
Gefahr:
Session Hijacking
Teile der Web Page überschreiben und User zu anderer Seite
weiterleiten
Maßnahmen:
Keinen Input des Users auf der Webseite anzeigen.
Falls das nicht geht: Encoding!
Validierung des User-Inputs; White-Lists
29. 1) Injection
Injection bedeutet, dass an einen Interpreter Commandos geschickt und diese
ausgeführt werden in einer Art und Weise wie es eigentlich nicht vorgesehen
ist.
Sql-Injection, OS Shell Injection, Buffer Overflows etc.
Gefahr:
Datenbankeinträge können manipuliert, ausgelesen oder gelöscht werden
Betriebssystem Zugriffe
…
30. 1) Injection - SQL Injection
Jede Eingabe MUSS validiert werden. Es ist nicht ausreichend nur
Formularfelder zu validieren. Injection ist auch zum Beispiel durch HTTP
Header-Felder möglich.
Ausfiltern von speziellen Datenbankzeichen wie zum Beispiel einfache
Hochkomma -> Blacklist Filtering
Zu bevorzugen ist eine Prüfung der Eingaben auf gültige Zeichen ->
Whitelist Filtering
Precompiled Statements verwenden. Das Statement wird in der Datenbank mit
Platzhaltern kompiliert. Spätere Manipulation des Statements durch Eingaben
nicht mehr möglich.
Minimierung der notwendigen Rechte in der Datenbank -> Principle
of „Least Privilege“. Verhindert SQL Injection nicht, verkleinert jedoch den
Schaden durch einen Angriff.
31. 1) Injection - Command Injection - Maßnahmen
Validierung der Eingaben (siehe auch SQL Injection)
Verwenden der Funktionen von Programmiersprachen zum Lesen von Dateien
Beschränken der Zugriffsrechte auf Dateien durch Rechtevergabe oder
Verwendung von chroot Umgebungen
Minimieren der möglichen ausführbaren Dateien
Berücksichtigen der System-Konfigurationen (z.B. sichere PHP Konfiguration)
32. …und immer an sichere Passworte denken!
Wie schnell kann Ihres gehackt werden?
Sample Passwords Class of Attack
Pwd Combinations Dual Core PC
darren 308.9 Million Instant
Land3rz 3.5 Trillion 58 Mins
B33r&Mug 7.2 Quadrillion 83½ Days
34. Zertifizierungen
kuehlhaus Web-Developer sind zertifiziert in
Development
allen wichtigen Basis-Technologien und Frameworks
Die zertifizierten kuehlhaus Experten sichern
Gesteigerte Budgetzuverlässigkeit*
Effizienteres Zeitmanagement und gesteigerte
Produktivität durch den sicheren Umgang mit
Produkten und Technologien*
Detaillierte Security Tests
Entwicklung unter Security-Gesichtspunkten
… und die Zertifizierung belegt, dass das Entwicklerteam
in Bezug auf diese Technologien auf dem neuesten Stand ist
* Quelle: Burlington Consultants, Value of Training and Certification study 2003
35. kuehlhaus AG
N7 5-6
D-68161 Mannheim
Dr. Nico Berndt
Head of Development
Telefon +49.621.496083-0
E-Mail info@kuehlhaus.com
Internet www.kuehlhaus.com
Die Inhalte dieser Präsentation sind das geistige Eigentum unseres
Unternehmens. Jede weitere Verwendung sowie Weitergabe an Dritte im
Original, als Kopie, in Auszügen, elektronischer Form oder durch
inhaltsähnliche Darstellung bedürfen der Zustimmung der kuehlhaus AG.