Montag, 2. Januar 2012


Topthema

Donnerstag, 15. Mai 2008 | Topthema

About Security #155: Schwachstellensuche: Session Hijacking

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/043215)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Um Angriffe auf Zustandsinformationen zu verhindern oder zumindest zu erschweren, müssen diese Informationen auf dem Server anstatt auf dem Client gespeichert werden. Das Speichern an sich ist dabei kein Problem. Es stellt sich aber die Frage, wie die Webanwendung die einzelnen Benutzer erkennt bzw. unterscheidet. Und welche neuen Angriffspunkte ergeben sich dadurch? Antworten auf diese Fragen erhalten Sie in dieser Folge.

N E U ! Security aktuell
Täglich aktuelle Security-Infos!

Sessions

Damit die während der Benutzung anfallenden Zustandsinformationen auf dem Server gespeichert und dem jeweiligen Benutzer zugeordnet werden können, wird jede Benutzung der Webanwendung durch einen Benutzer als Sitzung zusammengefasst und mit einer eindeutigen Kennung identifiziert. Diese Kennung muss zwangsläufig auf dem Client gespeichert werden, wodurch sie vom Angreifer beliebig manipuliert werden kann.

Session Identifier

Ein Session Identifier oder kurz eine Session ID ist eine Zahl oder eine Zahlen-Buchstaben-Kombination, über die eine Session eindeutig identifiziert werden kann. Jedem Benutzer wird bei seinem ersten Aufruf der Website eine solche Session ID zugewiesen, die dann während seines Besuchs auf der Website mitgeführt wird. Jeder folgende Request enthält die Session ID, sodass die Webanwendung die verschiedenen Benutzer unterscheiden und die jeweils zugehörigen Zustandsinformationen auf dem Server speichern und verwalten kann. Da die Session ID zwingend auf dem Client gespeichert werden muss, ergeben sich die bereits bekannten Möglichkeiten zu ihrer Speicherung und Manipulation. Dabei ist es egal, ob die Speicherung in einem Cookie (About Security #151), in dem URL (About Security #150) oder einem versteckten Formularfeld (About Security #149) erfolgt.

Schritt 4e: Session Hijacking

Beim Session Hijacking versucht ein Angreifer, die Session ID eines Benutzers auszuspähen, um sich danach selbst als dieser Benutzer auszugeben.

Ein Spezialfall des Session Hijacking ist der 'Authorization bypass', der am einfachsten an einem Beispiel zu erklären ist: Die Webanwendung erkennt ihre Benutzer an einem Cookie, der den Namen, eine Benutzer-ID und das Datum der letzten Benutzung enthält:

Name=Alice
BenutzerID=1234
Zuletzt=15-05-2008

Interessant ist in diesem Fall die Benutzer-ID, durch die die Anwendung den Benutzer eindeutig identifizieren kann. Wenn Alice die Benutzer-ID 1234 hat, gibt es dann vielleicht auch einen Benutzer mit der ID 1235? Ein Angreifer kann den Cookie nach seinen Vorstellungen manipulieren und den Wert der Benutzer-ID auf 1235 ändern. Was passiert, wenn die Webanwendung erneut aufgerufen wird? Statt "Willkommen Alice" steht da dann z.B. "Willkommen Bob" – der Angreifer hat die Identität eines anderen Benutzers angenommen. Der beste Schutz gegen solche Angriffe ist die Verwendung einer zufällig erzeugten, nicht vorhersagbaren ID.

About Security: Die komplette Serie
Schwachstellen finden

Vor jedem Angriff steht die Suche nach Angriffspunkten. Im Fall von Session-Hijacking muss vom Angreifer also eine Session ID identifiziert werden. Was dem Angreifer recht ist, ist dem Schwachstellensucher billig: Gesucht werden zuerst Parameter, die z.B. ID, TOKEN, SESSIONID, SID oder ähnlich heißen oder diese Zeichenketten als Teil des Namens enthalten. Dabei können die Parameter sowohl in Cookies als auch in versteckten Formularfeldern oder der URL gespeichert sein. Nun ist es nicht ungeschickt, dem Angreifer die Arbeit etwas zu erschweren und keinen so auffälligen Namen für die Session-ID zu verwenden. Das verhindert den Angriff aber natürlich nicht: Ein weiterer Hinweis darauf, das ein Parameter als Session ID dient, ist sein Verhalten während der Benutzung der Webanwendung: Konstante Parameter, die bei jedem neuen Seitenaufruf mitgesendet werden, sind verdächtig.

Schwachstellen testen

Wurde eine mutmaßliche Session ID erkannt, wird ihr Wert geändert. Handelt es sich wirklich um eine Session ID und ist der neue Wert gültig, hat der Angreifer damit die Identität eines anderen Benutzers angenommen. Das erkennt er daran, das er z.B. mit einem anderen Namen begrüßt wird, andere Funktionen nutzen oder auf bisher verbotene Bereiche der Anwendung zugreifen kann. Schlägt der Angriff fehlt, gibt es eine Fehlermeldung, die im für den Angreifer günstigsten Fall schon Hinweise auf das weitere Vorgehen liefert. Der einzige schwierige Teil des Angriffs ist für den Angreifer das Ausspähen oder Ermitteln gültiger Session IDs. Beim Test der eigenen Anwendung haben Sie es einfacher, da Sie den Aufbau der Session ID kennen und selbst eine gültige ID erzeugen können. Dann bleibt nur, zu prüfen, wie sich die Anwendung beim Austausch des Werts verhält. In den meisten Fällen wohl wie erwartet: Mit der ID wird auch die Identität des Benutzers gewechselt. Ein Angreifer, der sich die Session ID eines anderen Benutzers beschaffen oder selbst eine gültige Session ID erzeugen oder erraten kann, wäre damit also erfolgreich. Wie Sie entsprechende Angriffe wenn schon nicht verhindern, so doch erschweren können, erfahren Sie in der nächsten Folge.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Schwachstellensuche – II. Zustandsbasierte Angriffe"

Kommentare

Folgende Links könnten Sie auch interessieren