HTTPS und Cookies sicher einsetzen
Der unsichere Einsatz von HTTPS und Cookies kann auch die beste Authentifizierungsfunktion einer Webanwendung nutzlos machen: Der Angreifer späht die Zugangsdaten entweder schon vor der Authentifizierung aus, oder verschafft sich über einen ausgespähten Session- oder Authentifizierungscookie Zugang zur Webanwendung.
Der unsichere Einsatz von HTTPS
Oft enthalten über HTTP geladene Seiten ein Formular zum sofortigen Einloggen, dessen Eingaben ordnungsgemäß über HTTPS an den Server gesendet werden. Diese Kombination ist aber unsicher, ebenso die Variante, dass die Seite für die Eingabe der Zugangsdaten über HTTP geladen und erst beim Versenden der Zugangsdaten zu HTTPS gewechselt wird.
Nur wenn die Seite, auf der die Zugangsdaten eingegeben werden, schon über HTTPS geladen wurde, ist sicher gestellt, dass die Seite wirklich vom richtigen Server stammt und nicht manipuliert wurde. Dies kann insbesondere durch die in letzter Zeit verbesserte Kennzeichnung HTTPS-geschützter Seiten durch die Webbrowser erkannt werden, so dass der Benutzer sicher sein kann, dass er die richtige Seite verwendet und die eingegebenen Daten auch wirklich an den gewünschten Server geschickt werden.
Werden Zugangsdaten auf einer über HTTP geladenen Seite eingegeben, könnte ein Angreifer diese Seite im Rahmen eines Man-in-the-Middle-Angriffs so manipulieren, dass die Zugangsdaten an seinen Server und/oder unverschlüsselt übertragen werden. Diese Manipulation kann vom Browser gar nicht erkannt werden, vom Benutzer allenfalls, wenn er den Quelltext der Seite untersucht - und welcher Benutzer macht das schon, selbst wenn er die nötigen Kenntnisse besitzt?
Die Lösung dieses Problems ist sehr einfach: Auf über HTTP geladenen Seiten darf es keine Login-Funktion geben, und die für die Anmeldung verwendete Seite muss über HTTPS geladen werden.
Trotz sicherer HTTPS-Nutzung gefährdet u.U. zweites, damit verbundenes Problem die Webanwendung:
Der unsichere Einsatz von Cookies
Während der unsichere Einsatz von HTTPS i.A. problemlos korrigiert werden kann, erfordert die Korrektur der zweiten potentiellen Schwachstelle u.U. größeren Aufwand: Die unsichere Übertragung von Session- und/oder Authentifizierungscookies (im folgenden der Einfachheit halber allgemein als Sessioncookie bezeichnet).
Cookies enthalten das sog. 'Secure'-Flag, mit dem festgelegt wird, ob ein Cookie nur über geschützte HTTPS-Verbindungen oder auch über ungeschützte HTTP-Verbindungen übertragen werden darf (siehe z.B. About Security #151). Durch das Setzen dieses Flags wird verhindert, dass die so markierten Cookies über ungeschützte HTTP-Verbindungen übertragen und dabei ausgespäht werden können.
Praktisch sieht das z.B. so aus: Ein Benutzer meldet sich auf einer HTTPS-geschützten Seite bei der Webanwendung an, und die setzt nach erfolgreicher Authentifizierung einen Sessioncookie mit gesetztem 'Secure'-Flag. Solange sich der Benutzer im HTTPS-geschützten Bereich der Webanwendung bewegt, wird dieser Cookie bei jedem Aufruf mit übertragen und der Benutzer daran erkannt. Verlässt er den geschützten Bereich und ruft eine Seite über HTTP auf, wird der Cookie nicht übertragen. Ein Angreifer, der die Kommunikation des Benutzers belauschen kann, z.B. in einem ungeschützten WLAN, bekommt den Sessioncookie also nie zu sehen, da er immer nur über die geschützte HTTPS-Verbindung übertragen wird. Der Nachteil dieser Lösung: Die Webanwendung erkennt den Benutzer aufgrund des nun fehlenden Cookies nicht mehr.
Wird das 'Secure'-Flag nicht gesetzt, wird der Cookie beim Aufruf jeder Seite der betreffenden Website übertragen: Verlässt der authentifizierte Benutzer aus obigen Beispiel den geschützten Bereich, wird sein Sessioncookie weiterhin an die Webanwendung gesendet. Da die Verbindung nun nicht mehr über HTTPS, sondern das ungeschützte HTTP erfolgt, kann ein Angreifer den Cookie ausspähen und sich danach gegenüber der Webanwendung als der betreffende Benutzer ausgeben, sofern es keine weiteren Schutzmaßnahmen gibt.
I.A. werden nur Seiten mit sensitiven Daten über HTTPS übertragen. Außer den Zugangsdaten im Rahmen der Authentifizierung betrifft das z.B. die Abwicklung der Bestellung in einem Webshop oder die Verwaltung der Benutzerinformationen in einem Forum. Alle anderen Seiten wie z.B. die Produktbeschreibungen im Webshop oder die Diskussionen im Forum werden meist schon aus Performancegründen unverschlüsselt übertragen. Soll der Benutzer auch in diesen ungeschützten Bereichen der Website anhand der entsprechenden Cookies identifiziert werden können, darf ihr 'Secure'-Flag nicht gesetzt werden.
In der nächsten Folge werden ein möglicher Angriff auf Cookies ohne 'Secure'-Flag sowie mögliche Gegenmaßnahmen beschrieben.
Übersicht über alle Artikel zum Thema
- HTTPS und Cookies sicher einsetzen
- Angriff und Abwehr des CookieMonster
- Firesheep fängt ungeschützte Cookies
- Standpunkt: Firesheep - unverantwortlich oder dringend nötig?
Trackbacks
Dipl.-Inform. Carsten Eilers am : SSL/HTTPS - Schon wieder schlechte Nachrichten
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : HTML5 Security - Formulare auf Abwegen
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : HTML5 Security - Gift für den Application Cache
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: Windows.Developer Magazin 5.2013 - Web-API-Entwickler sind Webentwickler
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: Entwickler Magazin 2.2014 - Die OWASP Top 10, Teil 1
Vorschau anzeigen
entwickler.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 2.17 - SSL&TLS: Protokolle unter Dauerbeschuss
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #2: Unsichere Authentifizierung/Autorisierung, Teil 4
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #4: Fehlende Transportverschlüsselung
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : WLAN-Sicherheit 3 - Tools für WEP-Angriffe
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : WLAN-Sicherheit 19 - WLAN-Hotspots
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 5.18 - OWASP Top 10, Platz 4 - 6 - "XML External Entities (XXE)", "Broken Access Control" und "Security Misconfiguration"
Vorschau anzeigen