Hochschule Darmstadt Fachbereich Informatik. Entwicklung webbasierter Anwendungen

Transkript

1 Hochschule Darmstadt Fachbereich Informatik Entwicklung webbasierter Anwendungen 1 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

2 Hochschule Darmstadt Fachbereich Informatik 5. Sicherheit 2 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

3 Vorbemerkung Dieser Abschnitt bietet lediglich einen Einstieg in das Thema es werden ständig neue Sicherheitslücken und Angriffsformen entdeckt es gibt große Unterschiede zwischen den Betriebssystemen, Browsern, Webservern etc. der Sicherheitsbedarf hängt von der Anwendung ab Für den Betrieb einer professionellen Webanwendung ist Sicherheit ein Dauerthema wenn Sie das nicht leisten können, mieten Sie sich einen Server mit einem entsprechenden Update-Service für Betriebssystem, Apache, PHP, DB etc. dann müssen Sie "nur" noch kontinuierlich Sicherheitslücken in Ihrer Anwendung beseitigen 3 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

4 Überblick Client Internet Server Webbrowser Webserver CGI-Programm HTML Seite (Eingabe- Formular) 1. Eingabedaten übermitteln Daten 2. CGI-Programm starten HTML Seite (Ausgabe) 4. Eingabedaten übermitteln HTML Seite 3. erzeugte HTML-Seite DB 4 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

5 Hochschule Darmstadt Fachbereich Informatik 5.1. Formulareingaben 5 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

6 Daten aus Formularen Beispiel-Formular: 6 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

7 Daten aus Formularen Verarbeitung des Formulars im Backend: Was könnte hier das Problem sein? 7 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

8 Daten aus Formularen Traue NIE Input JEGLICHER FORM, der von Nutzern stammt in $_GET[ startpage ] erwarten Sie die folgenden Inhalte: Später inkludieren Sie im Backend basierend darauf eine PHP Datei: Vollkommen unsicher! Angreifer kann das Formular nach Belieben verändern. 8 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

9 Daten aus Formularen Per Web Inspector 9 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

10 Daten aus Formularen Per URL Parameter (nur bei GET): &startpage=../../../whatever Per HTTP Client (bspw. Postman -> Chrome Extension): Per curl (oder ähnlichem Tool) direkt von der Commandline. 10 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

11 Daten aus Formularen Daher: Nehmen Sie nur die URL Parameter an, die Sie auch wirklich erwarten und validieren Sie diese auf das, was Sie erwarten.. foreach über $_GET / $_POST / $_REQUEST ist in 99,9% aller Fälle ein Antipattern! 11 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

12 Daten aus Formularen Besser: Nehmen Sie nur die URL Parameter an, die Sie auch wirklich erwarten und validieren Sie diese auf das, was Sie erwarten.. 12 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

13 Daten aus Formularen Verlassen Sie sich nie auf clientseitige Validierung. Garantiert Ihnen weder, dass $_GET[ mail ] eine gültige ist $_GET[ mail ] überhaupt gesetzt ist 13 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

14 Daten aus Formularen Validierungsregeln: Verwenden Sie den Validator des Frameworks, welches Sie benutzen. Wo immer möglich, bei Validierung auf erprobte Libraries zurückgreifen. Falls nicht möglich: filter_var Funktionsfamilie in PHP: htmlentities / htmlspecialchars gegen Cross Site Scripting (kommt später noch) Reguläre Ausdrücke für erwartete Formate: Prepared Statements und entsprechendes Escaping gegen SQL Injection (kommt später noch) grundsätzliches Misstrauen! 14 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

15 Hochschule Darmstadt Fachbereich Informatik 5.2. Infrastruktur 15 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

16 Angriffe auf die Infrastruktur Es gibt viele Installationen mit Standardkonfiguration (MySQL + PHP + Apache...) Webserver geben großzügig Auskunft über die Versionen Default-Passwörter sind bekannt installierte Skripte sind teilweise bekannt Quellcode ist verfügbar Sicherheitslücken können gezielt gesucht und erprobt werden Angriffsziele (Auswahl): Auslesen von Daten Transaktionen unter fremden Namen Lahmlegen eines Internetauftritts 16 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

17 Angriffe auf die Infrastruktur Daher: Halten Sie Ihren Webserver und die verwendete Software (PHP, MySQL ) immer up to date! Verfolgen Sie Changelogs und einschlägige Blogs (bspw. Nutzen Sie Vulnerability Scanner, bpsw. - (erkennt die Verwendung unsicherer PHP Packages) - (scannt Ihre php.ini Datei nach unsicheren Konfigurationen) Verraten Sie nicht, welche Software zum Einsatz kommt Apache2: In /etc/apache2/apache2.conf ServerTokens ProductOnly ServerSignature Off PHP: In /etc/apache2/php.ini expose_php Off 17 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

18 Angriffe auf die Infrastruktur Dem Nutzer keine Fehlermeldungen zeigen! Fehlermeldungen sind wichtig, auch im Produktivbetrieb - aber dann bitte in einer Log-Datei und nicht auf dem Bildschirm Fehlermeldungen aus Bibliotheken nicht dem Benutzer zeigen - versteht er meist ohnehin nicht - enthalten evtl. wertvolle Hinweise für Hacker - Entwickler muss dem Benutzer anwendungsbezogene Meldungen zeigen - Entwickler muss systembezogene Meldungen in Log-Datei schreiben ini_set("error_reporting", E_ALL); // alles melden ini_set("display_errors", 0); // aber nicht ausgeben ini_set("log_errors", 1); // sondern loggen ini_set("error_log", "./mylog.txt"); // in diese Datei Vorsicht: mysqli::error() zeigt u.u. DB-Passwort in Fehlermeldung 18 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

19 Hochschule Darmstadt Fachbereich Informatik 5.3. Musterangriffe: Code Injection 19 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

20 Code-Injektion Man stelle sich mal folgendes vor: Kommentarfunktion in einem Blog mit Account ( + Passwort): Der Kommentar wird im Backend in der Datenbank gespeichert. 20 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

21 Code-Injektion Der Angreifer schreibt nun folgenden Kommentar: Was würde nun passieren, wenn der nächste Blogleser einen Kommentar schreibt? 21 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

22 Code-Injektion Daher: Validieren Sie stets den Nutzer-Input. Nehmen Sie kein HTML an, wo Sie kein HTML erwarten. Machen Sie Gebrauch von den Validierungs-Funktionen Ihres Frameworks. htmlentities und htmlspecialchars stehen Ihnen ebenfalls zur Verfügung. 22 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

23 Hochschule Darmstadt Fachbereich Informatik 5.4. Musterangriffe: Cross Site Scripting (XSS) 23 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

24 Cross Site Scripting Als Komfort-Feature hat der Entwickler dieser Webseite eine Vorbefüllung der Formularfelder eingebaut. Dies wird gerne gemacht, um den Nutzer zu ersparen, alle Daten erneut einzugeben, wenn das Formular nicht korrekt ausgefüllt sollte. Angriffsmöglichkeiten? 24 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

25 Cross Site Scripting Der Angreifer schickt dem Opfer einen präparierten Link, der HTML beinhaltet und aus dem Formularfeld ausbricht. Auch Javascript möglich. Eine ähnliche Attacke wie unter Code Injection gezeigt ist möglich! 25 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

26 Cross Site Scripting Daher: Validieren Sie stets den Nutzer-Input. Nehmen Sie kein HTML an, wo Sie kein HTML erwarten. Machen Sie Gebrauch von den Validierungs-Funktionen Ihres Frameworks. htmlentities und htmlspecialchars stehen Ihnen ebenfalls zur Verfügung. 26 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

27 Hochschule Darmstadt Fachbereich Informatik 5.5. Musterangriffe: Command Injection 27 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

28 Command Injection Szenario Sie bieten Nutzern an, mittels Ihres Webdiensts zu prüfen, ob andere Webseite erreichbar sind. Dazu führen Sie einen ping aus. Angriffsmöglichkeiten? 28 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

29 Command Injection Szenario Angreifer übermittelt in $_POST[ url ] nun h-da.de; rm -rf /* Der ausgeführte Befehl: ping h-da.de; rm -rf /* 29 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

30 Command Injection Daher: Versuchen Sie, wo möglich, auf das Durchreichen von User-Input auf Shell-Ebene komplett zu verzichten. Validieren Sie den Nutzer-Input, bevor Sie ihn weiterreichen. Im gezeigten Beispiel könnten Sie validieren, dass es sich um einen gültigen Domainnamen handelt. Verwenden Sie entsprechendes Escaping auf Shell-Ebene: Beschränken Sie die Rechte und das Verzeichnis des Nutzers, mit dem der Webserver läuft (Üblicherweise www-data). So wäre im Beispiel dem Nutzer Apache der Befehl rm -rf /* garnicht erlaubt. Beschränken Sie die Executables, die ein Nutzer auf Shell-Ebene ausführen darf. 30 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

31 Hochschule Darmstadt Fachbereich Informatik 5.6. Musterangriffe: SQL Injection 31 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

32 SQL Injection Szenario Sie wollen beim Login eines Nutzers prüfen, ob sich dieser mit den richtigen Daten einloggt: Angriffsmöglichkeiten? 32 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

33 SQL Injection Szenario Angreifer übermittelt in beiden Feldern nun ' OR '1=1 Der ausgeführte Befehl sieht dann wie folgt aus: SELECT COUNT(*) AS c FROM users WHERE username='' OR '1=1' AND password='' OR '1=1' Das ist immer wahr, somit kann sich der Nutzer auch ohne gültige Daten einloggen. 33 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

34 SQL Injection Andere Angriffsmöglichkeiten Löschen der Datenbank durch entsprechende DROP TABLE Statements Auslesen von Account-Daten anderer Nutzer 34 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

35 SQL Injection Daher: Beste Lösung: Verwenden Sie Prepared Statements. Falls Sie Prepared Statements nicht verwenden können: Validieren und Escapen Sie den Datenbankinput vor der Ausführung der Query: htmlspecialchars / htmlentities helfen NICHT für die Verhinderung von SQL Injection, genau wie mysqli real escape string nicht bei der Verhinderung von Cross Site Scripting hilft! 35 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

36 Hochschule Darmstadt Fachbereich Informatik 5.7. Musterangriffe: Cross Site Request Forgeries (CSRF) 36 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

37 CSRF Man stelle sich vor, gmail hätte eine CSRF Verwundbarkeit Sie als Angreifer setzen eine Webseite mit lustigen Katzenbildern auf: Sie senden Ihrem Opfer diese Webseite und binden versteckt ein Bild auf dieser Webseite ein: Der HTTP Request wird nun ausgeführt und dem Chef im Hintergrund die Mail gesendet, ohne dass es das Opfer mitbekommt. 37 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

38 CSRF Keine wirksamen Gegenmaßnahmen Nur POST-Request annehmen. Auch POST-Requests können problemlos von einer Webseite im Hintergrund abgesetzt werden. Nur den Referer Header prüfen Viele Proxy-Installationen in Firmen filtern den Referer Header heraus, sodass auch eine legitime Verwendung der Webseite nicht mehr möglich wäre Redirects der Zielseite könnten ausgenutzt werden 38 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

39 CSRF Daher... CSRF-Tokens verwenden. Bei Erstellung des Formulars wird ein geheimer Token in das Formular integriert, den das Backend generiert hat. Das Backend erwartet auch genau diesen String wieder beim Empfangen des Formulars. Der CSRF Token kann durch den Angreifer nicht mitgeschickt werden. Viele Frameworks bieten Optionen an, dieses Token automatisch zu integrieren. Die Webseite darf über keine XSS-Lücken verfügen! Sonst kann der Angreifer den Token auslesen. Zusammenfassung der Gegenmaßnahmen: evention_cheat_sheet 39 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

40 Hochschule Darmstadt Fachbereich Informatik 5.8. Musterangriffe: Session Highjacking 40 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

41 Session Highjacking Ein eingeloggter Nutzer wird durch seine Session ID identifiziert. Diese befindet sich üblicherweise in einem Session-Cookie und wird bei jedem Request mitgesendet. Angriffsmöglichkeiten? 41 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

42 Session Highjacking Angriffs-Szenario Durch eine Cross Site Scripting Lücke könnte ein Angreifer Javascript in die Webseite einschleusen. Mit diesem Javascript liest der Angreifer dann per document.cookie den Session Cookie des Opfers aus und übermittelt diesen an sich. Der Angreifer setzt sich nun selbst diesen Cookie und besucht die Webseite. Anschließend ist der Angreifer als sein Opfer eingeloggt. 42 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

43 Session Highjacking Daher... Webseite muss absolut frei von XSS-Lücken sein. Die Session-ID des Nutzers sollte bei jedem Seitenaufruf neu generiert werden. Die alten Session-Informationen werden übernommen: Session Cookies sollten nicht per Javascript ausgelesen werden dürfen (php.ini Einstellung: cking-und-session-fixation/) Maximale Session-Laufzeit definieren. 43 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

44 Hochschule Darmstadt Fachbereich Informatik 5.9. Absicherung der Kommunikation 44 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

45 HTTP und HTTPS HTTP ist unverschlüsselt kann mit Sniffer (z.b. Wireshark) abgehört werden Passwort und persönliche Daten im Klartext Gerade in Internet Caffes und an Hotspots sehr leicht möglich! HTTPS ist verschlüsselt mit TLS erfordert ein Zertifikat Mittlerweile sind auch valide Zertifikate kostenlos dank Konsequenz für Entwickler: jede Website sollte HTTPS verwenden Konsequenz für Anwender: nicht dasselbe Passwort für verschlüsselte und unverschlüsselte Verbindungen verwenden 45 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

46 Hochschule Darmstadt Fachbereich Informatik Lesetipps 46 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer

47 Lesetipps - DIE Ressource für sichere Webentwicklung. Cheatsheets, Checklisten, Hintergrundwissen, Top 10 Sicherheitslücken, Best Practices - Aktuelle Sicherheitslücken (full disclosure, Zero Days ) ct - WebGoat: Hacker spielen und in verschiedenen Levels verschiedene Angriffe ausprobieren spielangriff/ - Vierteilige Serie mit Grundlagenwissen zur Websecurity - Javascript Hackit incl. Bestenliste ;-). 47 Entwicklung webbasierter Anwendungen, SS2016, Stefan Zander / Maximilian Madl/ Thomas Sauer