Sicherheit in Webanwendungen „CrossSite“, „Session“ und „SQL“ Angriffstechniken und Abwehrmaßnahmen Mario Klump.

Präsentation zum Thema: "Sicherheit in Webanwendungen „CrossSite“, „Session“ und „SQL“ Angriffstechniken und Abwehrmaßnahmen Mario Klump."—  Präsentation transkript:

1 Sicherheit in Webanwendungen „CrossSite“, „Session“ und „SQL“ Angriffstechniken und Abwehrmaßnahmen Mario Klump

2 Die „Cross-Site“-Familie

3 Die Cross-Site-Arten ● Cross-Site-Scripting (CSS/XSS) ● Cross-Site-Request-Forgery (CSRF/XSRF)

4 Cross-Site-Scripting (CSS/XSS) Allgemeines ● Code (i.d.R. JavaScript) wird in fremde Website eingeschleust, um z.B. Daten auszuspähen ● auch als „HTML-Injection“ bezeichnet. ● Häufig werden per JavaScript Daten ausgelesen und anschliessend zum „bösen“ Server geschickt

5 Cross-Site-Scripting (CSS/XSS) Angrifftechniken XSS-Anriff auf ein anfälliges Gästebucheintrag: ● Beim Absenden wird Eintrag in Datenbank gespeichert. ● Bei der Ausgabe des Gästebuches wird „Max Mustermann schrieb: Hallo Leute boese(); “ im HTML- Code ausgegeben. ● Der HTML-Code wird ● interpretiert und das ● JavaScript ausgeführt.

6 Cross-Site-Scripting (CSS/XSS) Abwehrmaßnahmen ● Um XSS-Angriffe zu verhindern, sollten alle Daten, die ausgegeben werden, vor der Ausgabe maskiert werden. ● Der auszugebene Text („ boese(); “) sieht nach der Maskierung wie folgt aus: „<script>boese();</script>“ => Ausgabe wird nicht mehr als HTML interpetiert ● Einsetzen eine Web Application Firewall (WAF) Diese kann z.B. prüfen, ob ein ausgerufenes Formular die richtige Anzahl an Parametern hat und die Anfrage in einem solchen Fall blockieren.

7 Cross-Site-Request-Forgery (CSRF) Allgemeines ● Code (i.d.R. JavaScript) wird in fremde Website eingeschleust, um beim Benutzer ungewollte Aktionen im Hintergrund auszuführen. ● Dieser Angriff nutzt eine einfache HTTP-Anfrage.

8 Cross-Site-Request-Forgery (CSRF) Angrifftechniken ● CSRF-Angriff auf ein anfälliges Gästebuch: ● Beim Aufrufen der Website wird eine HTTP-Anfrage an „http://onlinebanking.meinebank.de/ueberweisen.php?von=12 3456&zu=789456“ geschickt. ● Falls der Benutzer bei der ● Bank eingeloggt ist, wird ● die Überweisung ● ausgeführt.

9 Cross-Site-Request-Forgery (CSRF) Abwehrmaßnahmen (1) ● Um XSRF-Anriffe zu verhindern, sollte man das Einbinden externer Ressourcen (z.B. Bilder) unterbinden. ● Falls Einbindung externer Ressourcen notwendig ist, diese auf dem Server zwischenspeichern. ● Alle Ausgaben vor dem Ausgaben maskieren. ● Überprüfung des MIME-Types (verringert nur das Risiko)

10 Cross-Site-Request-Forgery (CSRF) Abwehrmaßnahmen (2) ● Überprüfung des Referrers auf Server-Seite ● Auf Website (z.B. Website der Bank) sog. „token“ verwenden ● Die sog. „Angemeldet bleiben“-Funktionen vermeiden.

11 Angriffe auf Sessions

12 Was sind Sessions? ● HTTP ist ein verbindungsloses Protokoll Es gibt keine direkte Verbindung zwischen Client und Server. ● Server legt für jeden Client eine Session (Sitzung) an und generiert eine eindeutige ID (die Session-ID) ● Client weist sich mit Session-ID beim Server aus ● Session-ID kann per POST oder GET übertragen oder in einem Cookie gespeichert und übertragen werden ● Jeder Besitzer der Session-ID kann sich beim Server als (einen anderen) Client „ausweisen“. ● Und genau hier setzen die Angriffe auf Sessions an…

13 Angriffsarten auf Session ● Session-Hijacking ● Session-Fixation

14 Session-Hijacking Allgemeines ● Session-Hijacking beschreibt das „Klauen“ einer Session-ID eines anderen Benutzers. ● Dies kann über Sniffing (Abhören des Datenverkehrs) oder Auslesen der Session-ID durch z.B. CrossSite-Scripting passieren.

15 Session-Hijacking Angrifftechniken ● Wenn die Zielseite auf XSS anfällig ist und die Session-ID in einem Cookie gespeichert wird, könnte man über einen XSS- Angriff das Cookie auslesen. ● In dem Javascript wird ein neues Bild geladen und das Cookie der Website als GET-Parameter an das serverseitige Skript übertragen. ● Auf dem Server kann dies ● dann z.B. zwischen- ● gespeichert und vom ● Angreifer für eine ● Übernahme der Sitzung ● verwendet werden.

16 Session-Fixation Allgemeines ● Ebenfalls um eine Angriffstechnik, um die Session (Sitzung) eines anderen Anwenders zu übernehmen. ● Session-Hijacking und Session-Fixation unterscheiden sich jedoch im Ursprung der Session. ● Bei der Session-Fixation wird die Sitzung vom Angreifer erzeugt und versucht, dem Anwender die Session-ID unterzujubeln. ● Beim Session-Hijacking wird die Session vom Benutzer gestaret und die Session-ID vom Angreifer gestohlen.

17 Session-Fixation Angrifftechniken ● Wenn die Session-ID per GET übertragen könnte der Angreifer dem Anwender eine URL unterjubeln. Z.B.: http://socialnetwork.com/start.php?session_id=32947329574 2957 ● Somit ist der Angreifer schonmal im Besitz der Session-ID. ● Wenn sich der Anwender nun mit der Session einloggt, kann sich der Angreifer sehr einfach in die Sitzung einklinken.

18 Session-Hijacking & Session-Fixation Abwehrmaßnahmen ● Die Session an z.B. die IP-Adresse des Benutzers binden. ● Ebenfalls sollte eine verschlüsselte Verbindung (über HTTPS) eingesetzt werden, sodass auch die Session-ID über diesen sicheren Kanal übertragen wird. Somit wird das Auslesen des Netzwerkverkehrs erschwert.

19 SQL-Injection

20 SQL-Injection Allgemeines ● Bei der SQL-Injection wird eine SQL-Abfrage, die auf dem Server ausgeführt wird, manipuliert. ● Durch die Manipulation sollten meistens Daten (z.B. Kennwörter) ausgelesen oder Daten manipuliert werden. ● SQL-Injection funktioniert nur, wenn Daten vom Client (z.B. einem GET-Parameter) in einer SQL-Abfrage verwendet werden.

21 SQL-Injection Angrifftechniken SQL-Injection durch GET-Parameter-Manipulation: ● http://www.website.de/profile.php?user_id=1338 ● Auf der Serverseite wird folgende SQL-Abfrage durchgeführt (Beispiel in PHP): „SELECT * FROM users WHERE id_users = „.$_GET[‚user_id‘]; => SELECT * FROM users WHERE id_users = 1338 Nach Manipulation: ● http://www.website.de/profile.php?user_id=1338;DROP TABLE users => SELECT * FROM users WHERE id_users = 1338;DROP TABLE users Resultat: Daten vom Benutzer 1338 werden abgefragt und anschliessend wird die Tabelle „users“ gelöscht

22 SQL-Injection Abwehrmaßnahmen ● Alle Parameter, die in einer SQL-Anweisung verwendet werden, sollten maskiert werden. ● Prüfen, ob Parameter der richtige Datentyp ist. (User-ID ist Integer-Wert) ● Minimale Privilegien für Datenbankbenutzer festlegen (z.B. nur SELECT-Abfagen erlauben) ● In Webanwendung Prepared-Statements verwenden ● Einsatz einer Database-Firewall

23 Vielen Dank für Eure Aufmerksamkeit!