Channel Security

In About Security #217 wurden die Stellen aufgeführt, an denen ungeschützt übertragene Zugangsdaten von einem Dritten beobachtet werden können. Selbst wenn man davon ausgeht, dass nur vertrauenswürdige Personen zum Zugriff auf die beteiligten Komponenten autorisiert sind, besteht immer noch die Möglichkeit, dass sich ein Angreifer Zugriff darauf verschafft hat.

Hijacking

Wie in About Security #217 indirekt aufgeführt, durchlaufen die Daten nach der Eingabe durch den Benutzer oft mehrere Netze, bevor sie bei der Webanwendung ankommen: Ausgehend vom Rechner des Benutzers wandern die Daten durch dessen lokales Netz in das seines Zugangsproviders, weiter über den Internet-Backbone in das Netz des Zugangsproviders der Webanwendung, dann in deren lokales Netz bis sie letztendlich auf dem Server der Webanwendung ankommen. Auf jedem beteiligten Rechner, Router, ... können sie dabei beobachtet werden. Und angesichts der Möglichkeit, eine Verbindung über einen anderen Rechner umzuleiten, wie es in About Security #57 ff. beschrieben wurde, ist das nicht mal auf die direkt beteiligten Komponenten beschränkt.

Wolf im Schafspelz, oder: Angreifer im lokalen Netz

Im eigenen lokalen Netz wird oft auf die sichere Übertragung vertraulicher Daten verzichtet, da man den eigenen Benutzern vertraut und die i.A. auch andere Möglichkeiten haben, an die Daten zu gelangen. Dabei wird übersehen, das einem Angreifer das Eindringen in das Netz gelungen sein kann, dem die ungeschützt übertragenen Zugangsdaten sehr gelegen kommen, um danach Zugriff auf ihm bisher unzugängliche Bereiche des Netzes zu erlangen.

HTTPS unsicher verwendet

Selbst wenn die Anmeldung über das verschlüsselte HTTPS statt des unverschlüsselten HTTP erfolgt, gibt es noch mehrere Stellen, an denen die Zugangsdaten ungeschützt sein können:

• GET-Parameter, d.h. im Query-String übertragene Parameter, werden in den Logfiles des Webservers und evtl. genutzter Proxy-Server, der Browser-History des Benutzer und ggf. auch in Bookmarks gespeichert. Gelingt einem Angreifer ein Einbruch in eines dieser Systeme, kann er die so gespeicherten Daten lesen.
• Auch wenn die Daten als POST-Parameter übertragen werden, können sie indirekt in den Query-String gelangen, und zwar wenn die Anmeldung von einem anderen Skript vorgenommen wird und die Daten im Rahmen eines Redirects zu diesem Skript in der URL übertragen werden.
• Werden die Zugangsdaten in Cookies auf dem Client gespeichert, sind sie ebenfalls gefährdet:
  • Die Cookies können auf dem Client ausgespäht und danach vom Angreifer zur Anmeldung bei der Webanwendung verwendet werden. Das kann zum einen indirekt über XSS geschehen (siehe z.B. About Security #131), zum anderen kann ein Angreifer, der auf den Client-Rechner z.B. über eine Backdoor zugreifen kann, die Cookies auch direkt lesen.
  • Während einer HTTPS-Sitzung gesetzte Cookies, deren 'Secure'-Flag nicht gesetzt ist, können z.B. bei der Nutzung eines ungeschützten WLAN ausgespäht werden. Wie, wird z.B. im Standpunkt Sicherheit vom 18. August 2008 beschrieben.

Ein weiteres Problem bei der Verwendung von HTTPS ist die Frage nach dem richtigen Zeitpunkt für den Wechsel vom ungeschützten HTTP zum geschützte HTTPS. Oft wird die Seite für die Anmeldung über HTTP geladen und erst beim Versenden der Zugangsdaten zu HTTPS gewechselt. Dies ist aber unsicher, schon die Anmeldeseite muss über HTTPS geladen werden. Nur so kann der Benutzer sicher sein, dass er die richtige Seite verwendet und die eingegebenen Daten auch wirklich an den gewünschten Server geschickt werden. Ansonsten könnte ein Angreifer im Rahmen eines Man-in-the-Middle-Angriffs die Anmeldeseite so manipulieren, dass die Zugangsdaten an seinen Server und/oder unverschlüsselt geschickt werden.

Schwachstellen suchen

Zuerst wird ein Anmeldevorgang komplett durchlaufen, dabei werden alle zwischen Client und Server ausgetauschten Daten aufgezeichnet. Danach werden alle anderen Aktionen ermittelt, bei denen die Zugangsdaten vom Client zum Server oder vom Server zum Client übertragen werden.

Jedes Mal, wenn die Zugangsdaten
- in der URL
oder
- in einem Cookie
oder
- vom Server zum Client
übertragen werden, wird untersucht, was passiert und wieso es passiert (wobei man bei der Untersuchung der eigenen Anwendung den Vorteil hat, das genau zu wissen und nicht nur aus dem Umständen schließen zu können). Danach wird geprüft, ob und wie ein Angreifer die Anwendungslogik manipulieren kann, um an die Zugangsdaten anderer Benutzer zu gelangen.

Als Klartext übertragenen Zugangsdaten können leicht entdeckt werden und sind daher auch während der Übertragung zwischen Client und Server gefährdet. Werden keine Zugangsdaten beobachtet, müssen alle kodierten Daten daraufhin untersucht werden, ob sie sich dekodieren oder entschlüsseln lassen und dabei die gesuchten Zugangsdaten preis geben.

Werden die Zugangsdaten über HTTPS übertragen, die Anmeldeseite aber über HTTP, ist ein Man-in-the-Middle-Angriff möglich (s.o.). Als Gegenmaßnahme muss bereits die Anmeldeseite über HTTPS übertragen werden.

In der nächsten Folge wird die Untersuchung kodierter Daten beschrieben.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #214: Schwachstellen-Suche: Authentifizierung - Grundlagen
• About Security #215: Schwachstellen-Suche: Authentifizierung - Brute Force
• About Security #216: Schwachstellen-Suche: Authentifizierung - Namen finden
• About Security #217: Schwachstellen-Suche: Authentifizierung - Ein Angriff
• About Security #218: Schwachstellen-Suche: Authentifizierung - Die Übertragung