Skip to content

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.

Carsten Eilers


Ü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
Es gibt schon wieder schlechte Nachrichten zu SSL bzw. konkret zu HTTPS: Da wird von den Webservern nicht so sicher eingesetzt, wie es eigentlich nötig wäre. Dadurch sind in sehr vielen Fällen SSL-Stripping-Angriffe möglich.

Dipl.-Inform. Carsten Eilers am : HTML5 Security - Formulare auf Abwegen

Vorschau anzeigen
Nach der Einführung und einigen XSS-Angriffen geht es in dieser Folge um einen weiteren Angriff auf und über HTML5: Das Manipulieren von Formularen. Zuvor aber wieder der Hinweis, dass die Texte hier im Blog dem Inhalt meines Vortrag

Dipl.-Inform. Carsten Eilers am : HTML5 Security - Gift für den Application Cache

Vorschau anzeigen
Nach der Einführung, den XSS-Angriffen und dem Angriff auf Formulare geht es nun um Angriffe auf lokale gespeicherte Daten, konkret die Daten im Application Cache Webanwendungen, die auch offline, also ohne Verbindung zum zugeh&o

Dipl.-Inform. Carsten Eilers am : Drucksache: Entwickler Magazin 2.2014 - Die OWASP Top 10, Teil 1

Vorschau anzeigen
Im Entwickler Magazin 2.2014 ist der erste Teil eines zweiteiligen Artikels über die OWASP Top 10, die zehn gefährlichsten Schwachstellen in Webanwendungen, erschienen. Die Reihenfolge der Schwachstellen ergibt sich aus vier Faktoren

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!