Sitzungsfixierung - Session fixation

In Computer - Netzwerk - Sicherheit, Session - Fixation - Angriffe versuchen, auszunutzen die Anfälligkeit eines Systems , das eine Person zu fixate (find oder Set) einer anderen Person ermöglicht Sitzungskennung . Die meisten Angriffe zur Sitzungsfixierung sind webbasiert und die meisten beruhen darauf, dass Sitzungskennungen von URLs ( Abfragezeichenfolge ) oder POST-Daten akzeptiert werden.

Angriffsszenarien

Alice hat ein Konto bei der Bankhttp://unsafe.example.com/

Mallory beabsichtigt, Alices Geld von ihrer Bank ins Visier zu nehmen.

Alice hat ein angemessenes Vertrauen in Mallory und wird die Links besuchen, die Mallory ihr schickt.

Ein einfaches Angriffsszenario

Einfaches Szenario:

  1. Mallory hat festgestellt, dass http://unsafe.example.com/jede Sitzungskennung akzeptiert, Sitzungskennungen aus Abfragezeichenfolgen akzeptiert werden und keine Sicherheitsvalidierung vorliegt. http://unsafe.example.com/ist somit nicht sicher.
  2. Mallory schickt Alice eine E-Mail: "Hey, sieh dir das an, es gibt eine coole neue Kontoübersichtsfunktion auf unserer Bank. http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID" Mallory versucht, die SID auf I_WILL_KNOW_THE_SID.
  3. Alice ist interessiert und besucht http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID. Der übliche Anmeldebildschirm erscheint und Alice meldet sich an.
  4. Mallory besucht http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SIDund hat jetzt unbegrenzten Zugriff auf Alices Konto.

Angriff mit servergenerierter SID

Ein Missverständnis ist, dass ein Server, der nur vom Server generierte Sitzungskennungen akzeptiert, vor einer Fixierung sicher ist. Dies ist falsch .

Szenario:

  1. Mallory besucht http://vulnerable.example.com/und prüft, welche SID zurückgegeben wird. Der Server kann beispielsweise antworten: Set-Cookie: SID=0D6441FEA4496C2.
  2. Mallory kann Alice jetzt eine E-Mail schicken: "Schau dir dieses neue coole Feature auf unserer Bank an, http://vulnerable.example.com/?SID=0D6441FEA4496C2."
  3. Alice meldet sich mit fester Sitzungskennung an SID=0D6441FEA4496C2.
  4. Mallory besucht http://vulnerable.example.com/?SID=0D6441FEA4496C2und hat jetzt unbegrenzten Zugriff auf Alices Konto.

Angriffe mit Cross-Subdomain-Cookies

Diese Art von Angriff ähnelt einem Cross-Site-Cookie-Angriff, außer dass sie nicht auf der Schwachstelle des Browsers des Benutzers beruht. Vielmehr beruht es auf der Tatsache, dass Wildcard-Cookies von einer Subdomain gesetzt werden können und dass diese Cookies andere Subdomains beeinflussen können.

Szenario:

  1. Eine Website www.example.comvergibt Subdomains an nicht vertrauenswürdige Dritte
  2. Eine solche Partei, Mallory, die sie jetzt kontrolliert evil.example.com, lockt Alice auf seine Seite
  3. Ein Besuch zum evil.example.comSetzen eines Sitzungscookies mit der Domain .example.comin Alices Browser
  4. Wenn Alice ihn besucht, wird www.example.comdieser Cookie mit der Anfrage gesendet und Alice hat die Sitzung, die von Mallorys Cookie angegeben wird.
  5. Wenn Alice sich jetzt anmeldet, kann Mallory ihr Konto verwenden.

Wenn dieser Angriff abgeschlossen ist, kann Mallory www.example.comals Alice zugreifen .

Es ist nicht unbedingt erforderlich, dass sich ein Benutzer anmeldet, um Sitzungsfixierungsangriffe auszunutzen, und obwohl diese nicht authentifizierten Angriffe nicht auf subdomänenübergreifende Cookie-Angriffe beschränkt sind, sind die Auswirkungen von Subdomänenangriffen für diese nicht authentifizierten Szenarien relevant. Zum Beispiel kann Mallory eine URL von ihrer bösen Site bereitstellen, eine Sitzung auf ein nicht authentifiziertes Szenario fixieren und diese Techniken verwenden, um ihr Ziel auszunutzen. Dies umfasst Szenarien, die sowohl die nicht authentifizierten Szenarien (zB Formulare oder Registrierung) ausnutzen als auch die Möglichkeit, dem Benutzer eine eingerichtete Sitzung zuzuführen, um die Anmeldung vollständig zu umgehen.

Stellen Sie sich zum Beispiel vor, dass Mallory einen Benutzer A1ice auf www.example.com erstellen und diesen Benutzer einloggen kann, um eine aktuelle, gültige Sitzungskennung zu erfassen. Mallory fängt Alice dann mit einer URL von böse.example.com ein, die dieses Sitzungscookie in Alices Browser fixiert (wie oben beschrieben) und zu www.example.com umleitet, um eine bestimmte Transaktion (oder tatsächlich eine breitere Verwendung) abzuschließen. Mallory ist somit in der Lage, die Sitzung aus ihrem ursprünglichen Login zu löschen, Daten abzukratzen und Operationen als 'A1ice' auf 'www.example.com' auszuführen. Wenn Alice erfolgreich getäuscht wurde und ihre Kreditkarte auf dem Konto gespeichert hat, kann Mallory dann mit dieser Karte Einkäufe tätigen.

Gegenmaßnahmen

Akzeptieren Sie keine Sitzungskennungen von GET / POST-Variablen

Sitzungskennungen in URL (Abfragezeichenfolge, GET-Variablen) oder POST-Variablen werden nicht empfohlen, da sie diesen Angriff vereinfachen – es ist einfach, Links oder Formulare zu erstellen, die GET / POST-Variablen setzen.

  • Die SID wird an andere Personen weitergegeben, wenn Benutzer "interessante Links" aus der Adressleiste ausschneiden und in Chats, Foren, Communities usw. einfügen.
  • Die SID wird an vielen Stellen gespeichert (Browserverlaufsprotokoll, Webserverprotokoll, Proxyprotokolle, ...)

Hinweis: Cookies werden zwischen Tabs und Popup-Browserfenstern geteilt. Wenn Ihr System mit derselben Domain (www.example.com/?code=site1 und www.example.com/?code=site2 ) aufgerufen werden muss, können die Cookies zwischen den Registerkarten in Konflikt stehen.

Es kann erforderlich sein, die Sitzungskennung auf der URL zu senden, um diese Einschränkung zu überwinden. Verwenden Sie nach Möglichkeit site1.example.com oder site2.example.com, damit keine Domänenkonflikte in den Cookies auftreten. Dies kann bei zusätzlichen SSL-Zertifikaten Kosten verursachen.

Dieses Verhalten kann auf vielen Websites beobachtet werden, indem Sie einen anderen Tab öffnen und versuchen, nebeneinander Suchergebnisse zu erstellen. Eine der Sitzungen wird unbrauchbar.

Beste Lösung: Identitätsbestätigung

Dieser Angriff kann weitgehend vermieden werden, indem die Sitzungs-ID beim Anmelden des Benutzers geändert wird. Wenn jede spezifische Anfrage eines Benutzers eine Authentifizierung des Benutzers bei der Site erfordert, muss ein Angreifer die ID des Opfers kennen Login-Sitzung. Wenn das Opfer jedoch den Link mit der festen Sitzungs-ID besucht, muss es sich in sein Konto einloggen, um etwas "Wichtiges" als es selbst zu tun. Zu diesem Zeitpunkt ändert sich ihre Sitzungs-ID und der Angreifer kann mit der anonymen Sitzungs-ID nichts "Wichtiges" tun.

Eine ähnliche Technik kann verwendet werden, um das Phishing- Problem zu lösen . Wenn der Benutzer sein Konto mit zwei Passwörtern schützt, kann dies weitgehend gelöst werden.

Diese Technik ist auch bei Cross-Site-Request-Forgery- Angriffen nützlich .

Lösung: Sitzungskennungen in HTTP-Cookies speichern

Die Sitzungskennung auf den meisten modernen Systemen wird standardmäßig in einem HTTP-Cookie gespeichert , das ein moderates Sicherheitsniveau hat, solange das Sitzungssystem GET/POST-Werte ignoriert. Diese Lösung ist jedoch anfällig für Cross-Site-Request-Forgery und erfüllt nicht die Anforderungen an die Staatenlosigkeit von REST .

Lösung: Verwenden Sie die SSL / TLS-Sitzungskennung

Beim Aktivieren der HTTPS- Sicherheit erlauben einige Systeme Anwendungen, die SSL-/TLS- Sitzungskennung abzurufen. Die Verwendung der SSL/TLS-Sitzungskennung ist sehr sicher, aber viele Webentwicklungssprachen bieten hierfür keine robuste integrierte Funktionalität.

SID bei jeder Anfrage neu generieren

Eine Gegenmaßnahme gegen die Sitzungsfixierung besteht darin, bei jeder Anforderung eine neue Sitzungskennung (SID) zu generieren. In diesem Fall kann ein Angreifer zwar einen Benutzer dazu verleiten, eine bekannte SID zu akzeptieren, die SID wird jedoch ungültig, wenn der Angreifer versucht, die SID erneut zu verwenden. Die Implementierung eines solchen Systems ist einfach, wie die folgenden Beispiele zeigen:

  • Rufen Sie die vorherige Sitzungskennung OLD_SIDaus der HTTP-Anforderung ab.
  • Wenn OLD_SIDnull, leer oder keine Sitzung mit SID= OLD_SIDvorhanden ist, erstellen Sie eine neue Sitzung.
  • Generieren Sie eine neue Sitzungskennung NEW_SIDmit einem sicheren Zufallszahlengenerator.
  • Sitzung durch SID= identifizieren lassen NEW_SID(und nicht mehr durch SID= OLD_SID)
  • Senden Sie eine neue SID an den Client.

Beispiel:

Wenn Mallory Alice erfolgreich zum Besuch verleitet http://victim.example.com/?SID=I_KNOW_THE_SID, wird diese HTTP-Anfrage gesendet an victim.example.com: 

GET /?SID=I_KNOW_THE_SID HTTP/1.1
Host: victim.example.com

victim.example.comakzeptiert SID=I_KNOW_THE_SID, was normalerweise schlecht wäre. Ist victim.example.comjedoch sicher, da es eine Sitzungsregeneration durchführt. victim.example.combekommt folgende Antwort: 

HTTP/1.1 200 OK
Set-Cookie: SID=3134998145AB331F

Alice verwendet nun das SID=3134998145AB331F, was Mallory nicht bekannt ist und SID=I_KNOW_THE_SIDungültig ist. Mallory ist somit beim Versuch der Sitzungsfixierung nicht erfolgreich.

Leider ist eine Sitzungsregeneration nicht immer möglich. Probleme treten bekanntermaßen auf, wenn Drittanbietersoftware wie ActiveX- oder Java-Applets verwendet wird und wenn Browser-Plugins mit dem Server kommunizieren. Software von Drittanbietern kann zu Abmeldungen führen oder die Sitzung kann in zwei separate Sitzungen aufgeteilt werden.

Wenn die Implementierung von Sitzungen die Übertragung der SID über GET- oder POST-Variablen umfasst, kann dies auch dazu führen, dass die Schaltfläche "Zurück" in den meisten Browsern unbrauchbar wird, da der Benutzer dann eine ältere, ungültige Sitzungskennung aus einer früheren Anfrage verwendet.

Akzeptieren Sie nur vom Server generierte SIDs

Eine Möglichkeit zur Verbesserung der Sicherheit besteht darin, Sitzungs-IDs nicht zu akzeptieren, die nicht vom Server generiert wurden. Dies verhindert jedoch, wie oben erwähnt, nicht alle Angriffe auf die Sitzungsfixierung. 

if (!isset($_SESSION['SERVER_GENERATED_SID'])) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier
$_SESSION['SERVER_GENERATED_SID'] = true;

Abmeldefunktion

Eine Logout-Funktion ist nützlich, da sie es Benutzern ermöglicht, anzugeben, dass eine Sitzung keine weiteren Anfragen zulassen soll. Somit können Angriffe nur wirksam sein, während eine Sitzung aktiv ist. Beachten Sie, dass der folgende Code keine Cross-Site-Request-Forgery- Prüfungen durchführt, was es einem Angreifer möglicherweise ermöglicht, Benutzer zu zwingen, sich von der Webanwendung abzumelden. 

if (logout) {
    session_destroy(); // Destroy all data in session
}

Timeout alte SIDs

Diese Verteidigung ist einfach zu implementieren und hat den Vorteil, dass sie ein Maß an Schutz gegen unbefugte Benutzer bietet, die auf das Konto eines autorisierten Benutzers zugreifen, indem sie eine Maschine verwenden, die möglicherweise unbeaufsichtigt gelassen wurde.

Speichern Sie eine Sitzungsvariable, die einen Zeitstempel des letzten Zugriffs durch diese SID enthält. Wenn diese SID erneut verwendet wird, vergleichen Sie den aktuellen Zeitstempel mit dem in der Sitzung gespeicherten. Wenn die Differenz größer als eine vordefinierte Zahl ist, sagen wir 5 Minuten, zerstören Sie die Sitzung. Aktualisieren Sie andernfalls die Sitzungsvariable mit dem aktuellen Zeitstempel.

Sitzung zerstören, wenn Referrer verdächtig ist

Beim Besuch einer Seite setzen die meisten Webbrowser den Referrer- Header – die Seite, die den Link enthielt, dem Sie gefolgt sind, um zu dieser Seite zu gelangen.

Wenn der Benutzer bei einer Site angemeldet ist, die wahrscheinlich nicht von außerhalb dieser Site verlinkt wird (z. B. Banking-Websites oder Webmail ), und die Site nicht die Art von Site ist, auf der Benutzer längere Zeit angemeldet bleiben Zeit sollte der Referrer von dieser Site stammen. Jeder andere Referrer sollte als verdächtig eingestuft werden. Wenn die ursprüngliche Anfrage jedoch von einer HTTPS-Seite stammt, wird der Referrer entfernt, sodass Sie sich nicht auf dieses Sicherheitssystem verlassen können.

Könnte zum Beispiel http://vulnerable.example.com/die folgende Sicherheitsüberprüfung durchführen: 

if (strpos($_SERVER['HTTP_REFERER'], 'http://vulnerable.example.com/') !== 0) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier

Stellen Sie sicher, dass die zusätzlichen Informationen während der gesamten Sitzung konsistent sind

Eine Möglichkeit zur weiteren Verbesserung der Sicherheit besteht darin, sicherzustellen, dass der Benutzer derselbe Endbenutzer (Client) ist. Dies macht es etwas schwieriger, eine Sitzungsfixierung und andere Angriffe durchzuführen.

Da immer mehr Netzwerke beginnen, RFC 3704 und andere Anti- Spoofing- Praktiken zu erfüllen , wird die IP-Adresse als Identifikator "der gleichen Quelle" zuverlässiger. Daher kann die Sicherheit einer Website verbessert werden, indem überprüft wird, dass die Quell-IP-Adresse während einer Sitzung konsistent ist.

Dies könnte auf diese Weise durchgeführt werden: 

if ($_SERVER['REMOTE_ADDR'] != $_SESSION['PREV_REMOTEADDR']) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier
$_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];

Vor der Anwendung dieses Ansatzes sind jedoch einige Punkte zu beachten.

  • Mehrere Benutzer können sich eine IP-Adresse teilen. Es ist nicht ungewöhnlich, dass sich ein ganzes Gebäude über NAT eine IP-Adresse teilt .
  • Ein Benutzer kann eine inkonsistente IP-Adresse haben. Dies gilt für Benutzer hinter Proxys (wie AOL- Kunden). Dies gilt auch für einige mobile/Roaming-Benutzer sowie für Benutzer, die sich hinter Internetverbindungen mit Lastausgleich befinden. Benutzer mit aktivierten IPv6-Datenschutzerweiterungen können auch ihre IPv6-Datenschutzadressen jederzeit ändern.
  • Es funktioniert nicht zuverlässig mit Dual-Stack-Clients, da Anfragen zwischen IPv4 und IPv6 verschoben werden.
  • Es wird bei mobilen Benutzern nicht zuverlässig funktionieren, da mobile Benutzer auch zwischen Adressen wechseln.

Bei einigen Websites überwiegt die zusätzliche Sicherheit den Komfortmangel, bei anderen nicht.

User-Agent

Browser identifizieren sich selbst durch "User-Agent"-HTTP-Header. Dieser Header ändert sich normalerweise während der Verwendung nicht; es wäre äußerst verdächtig, wenn das passieren würde. Eine Webanwendung verwendet möglicherweise die User-Agent-Erkennung, um zu verhindern, dass böswillige Benutzer Sitzungen stehlen. Dies zu umgehen ist jedoch trivial, da ein Angreifer den User-Agent des Opfers leicht mit seiner eigenen Site erfassen und dann während des Angriffs fälschen kann. Dieses vorgeschlagene Sicherheitssystem verlässt sich auf Sicherheit durch Unklarheit . 

if ($_SERVER['HTTP_USER_AGENT'] != $_SESSION['PREV_USERAGENT']) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier
$_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];

Vor der Anwendung dieses Ansatzes sind jedoch einige Punkte zu beachten.

  • Mehrere Benutzer können den gleichen Browser-Benutzeragenten im Internet-Café haben .
  • Mehrere Benutzer können denselben Standardbrowser verwenden (z. B. Internet Explorer 6 in Windows XP SP3 oder Minibrowser in Mobiltelefonen).

In einigen Fällen kann sich der Benutzeragent jedoch rechtlich ändern. Die folgenden Beispiele sind die gleichen Benutzer.

  • Ein Smartphone, dessen Bildschirm sich seit der letzten Anfrage gedreht hat
    • Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 854X480 motorola DROID2
    • Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 480X854 motorola DROID2
  • Kompatibilitätsmodus für Internet Explorer:
    • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
    • Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
  • Ein Benutzer, der über einen auf mehrere Server verteilten Proxy auf eine Website zugreift, von denen nicht alle auf die neueste Version der Proxy-Software aktualisiert wurden
    • Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/0.0.5; +http://flipboard.com/browserproxy)
    • Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)

Verteidigung in der Tiefe

Hauptartikel: Verteidigung in der Tiefe (Computer)

Defense in Depth besteht darin, mehrere Gegenmaßnahmen zu kombinieren. Die Idee ist einfach: Wenn ein Hindernis einfach zu überwinden ist, können mehrere Hindernisse sehr schwer zu überwinden sein.

Eine Defense-in-Depth-Strategie könnte Folgendes beinhalten:

  • HTTPS aktivieren (zum Schutz vor anderen Problemen)
  • Korrekte Konfiguration (keine externen SIDs akzeptieren, Timeout setzen etc.)
  • Führen Sie session_regeneration durch, unterstützen Sie die Abmeldung usw.

HTTP-Referrer werden nicht mit SSL/TLS (HTTPS) übergeben.

Das folgende PHP-Skript demonstriert mehrere solcher Gegenmaßnahmen, die auf eine tiefgehende Art und Weise kombiniert werden: 

if (isset($_GET['LOGOUT']) ||
    $_SERVER['REMOTE_ADDR'] !== $_SESSION['PREV_REMOTEADDR'] ||
    $_SERVER['HTTP_USER_AGENT'] !== $_SESSION['PREV_USERAGENT']) {
    session_destroy();
}

session_regenerate_id(); // Generate a new session identifier

$_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];
$_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];

Beachten Sie, dass dieser Code die aktuelle REMOTE_ADDR (die IP-Adresse des Benutzers) und den User-Agent mit der REMOTE_ADDR und dem User-Agent der vorherigen Anfrage abgleicht. Dies kann für einige Websites, wie oben beschrieben, unpraktisch sein.

Siehe auch

Verweise

Externe Links