Wie Session-Hijacking verhindern?

[jens]

Mir ist durch den Thread Sinn oder Unsinn des PyLucids JS-MD5-Login... aufgefallen, das es neben dem eigentlichen Login noch ein weiteres Sicherheitsproblem gibt: http://de.wikipedia.org/wiki/Session-Hijacking

Klar ist das https auch hier wieder zuverlässig Abhilfe schaffen kann.Ich frage mich aber was kann man aber ohne SSL/TLS tun?

Man muß irgendwie die Session-ID vor übernahmen schützen.

Die einfachste Variante habe ich schon länger Implementiert. Die Session-ID ist an der IP Adresse gekoppelt. Stimmen die später nicht überein, gehts nicht weiter: https://pylucid.net/trac/browser/trunk/ ... v=631#L321

Wenn jemand es allerdings schafft, die Session ID zu sniffen, wird es auch die IP Adresse fälschen können.

Irgendwelche weiteren Ideen?

[BlackJack]

Aufgeben. Ganz im Ernst, Sicherheit ist immer ein Abwägen zwischen Aufwand und Nutzen und Du machst Dir IMHO viel zuviele Gedanken und erstellst zu komplizierte Lösungen. Wer es sicher haben will nimmt https, alle anderen können/müssen sowieso damit leben das es nicht wirklich sicher ist.

Und wie man sieht sind Deine Lösungen teilweise recht "zerbrechlich".

[mitsuhiko]

Die einfachste Variante habe ich schon länger Implementiert. Die Session-ID ist an der IP Adresse gekoppelt. Stimmen die später nicht überein, gehts nicht weiter: https://pylucid.net/trac/browser/trunk/ ... v=631#L321

Damit hast du alle AOL user ausgesperrt. Gratulation.

Für Session Hijacking Probleme: HTTPS. Was anderes kannst du nicht tun. Ney. du kannst USER_AGENT hashen, aber das ist kein Schutz. Wer snifft kann auch gleich den User Agent mit ändern

[Gromit]

Wenn Dir wirklich soviel dran liegt ohne https auszukommen kannst du natürlich einen https-like verschlüsselten RPC mit jason in javascript schreiben. Einschließlich der client-side-zertifikate, die nur ganze wenige sites fordern.

Sorry, konnt mich nicht beherrschen.

[jens]

Damit hast du alle AOL user ausgesperrt.

Warum?

[BlackJack]

Weil die alle über ein paar wenige Proxies ins "richtige" Internet gehen, also viele User sich die gleiche IP teilen.

[jens]

Ja das ist fein. Deswegen sind die AOL Leute aber doch nicht ausgesperrt.

Es geht ja nicht darum, das über eine IP nur eine Session zugelassen wird. Es geht darum, das eine Session nicht zu einer anderen IP wechseln kann. Der Proxy-Server von AOL sollte wohl immer in einer Sitzung die selbe IP haben, oder etwa nicht?

[mitsuhiko]

Ja das ist fein. Deswegen sind die AOL Leute aber doch nicht ausgesperrt.

Deren Proxy Server ändert sich minütlich

[keppla]

Ich glaube, man kann guten Gewissens sagen, dass man Session Hijacking bei HTTP nicht verhindern kann.

Ein Session-Hijackender Angreifer muss die Kommunikation zwischen Server und Client also mindestens auf HTTP-Ebene abhören können (sonst käme er nicht an die Session-ID).
Also fallen alle Daten auf der HTTP-Ebene als Validationskriterium weg, da sie auch dem Angreifer bekannt sind.
Darunter liegt TCP/IP, über welches man aus Userfreundlichkeit keine Annahmen treffen darf (beispiel AOL-Kunden).

Daher mein Fazit: alle Daten, die man erhält, sind entweder zu fälschen oder nicht aussagekräftig, also: verhindern unmöglich.

Der Versuch, trotzdem "sicherheit zu Programmieren" tut nichts, ausser das ganze Komplizierter zu machen, und kompliziertere Dinge sind imho immer unsicherer als einfache, man schadet also effektiv der Sicherheit.

[Leonidas]

Der Versuch, trotzdem "sicherheit zu Programmieren" tut nichts, ausser das ganze Komplizierter zu machen, und kompliziertere Dinge sind imho immer unsicherer als einfache, man schadet also effektiv der Sicherheit.

Das denkst nicht nur du:

If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.

[jens]

Also mir fällt nur eine Variante ein: Ein ständiger challenge/response. Aber das geht nicht, denn dazu brauche ich auf dem Client und auf dem Server irgendwelche gleichen Daten X die nicht ausgetauscht werden.
Der Server sickt zu der Seite eine Nonce die der Client per JS mit den Daten X zu einer MD5 zurück schickt. Der Server kann dann das selbe tun und vergleichen.
Das Problem ist allerdings, das man keine Daten auf dem Client irgendwie hinterlegen kann...

Also Käse...

[Blattlaus]

Die einfachste Lösung: Die Session ID nicht an die Uri anhängen, sondern in einem Cookie speichern.

Ablauf:

• User loggt sich ein
• Cookie mit Session ID (irgendein Hash/whatever) und einer Lebenszeit von X wird an den Client verschickt.
• Die selbe Session ID wird mit Ablaufdatum und Benutzer-ID in einer DB gespeichert.
• Auf jeder Seite wird geprüft ob der Cookie noch gültig ist und ob die Benutzer ID dem entspricht was in der DB steht.
• Ist alles in Ordnung gehts weiter, andernfalls wird man ausgeloggt

Warum ist das sicher? Browser schicken Cookies nur an die Domain von der er stammt, d.h. ein Angreifer hat keine möglichkeit von aussen irgendwie an den Cookie zu kommen.

Schwachpunkte dieser Methode:

• Man könnte den Netzwerkverkehr mitsniffen und kommt so an die Session-Daten.
  Irrewant, weil: Wenn jemand die Netzwerkverkehr mitsnifft, hat er eh das Loginpasswort, das wird schleißlich im Klartext übertragen.
• Man könnte den Benutzer fragen ob er einem den Cookie nicht mal per Mail schickt.
  Irrelevant, weil: Wer so doof ist hat eh verloren. Außerdem ist es nicht eure Aufgabe einem möglichen Social Engenierung vorzubeugen.
• Man könnte einen Trojaner auf dem Rechner des Opfers installieren.
  Irrelevant weil: Dann hat man eh gewonnen und außerdem kann man dann gleich nen Keylogger benutzen
• XSS Scripting. Falls eure Seite die möglichkeit bietet, das User HTML einbetten, könnte man darüber ein Loginformular über das echte legen und damit den Login abfangen. Außerdem werden die nächsten Browser Generationen das abfangen und warnen.
  Irrelevant weil: Hat nichts mit der Unsicherheit der Cookie Methode zu tun.
• JS-Injection. Falls eure Seite die möglichkeit bietet, dass User HTML einbinden, und ihr das nicht sauber escaped und prüft, dann wäre es möglich, dass man ein JS einbettet, das den Cookie ausliest und die Daten vie XhhtpRequest woanders hin schickt.
  Irrelevant weil: Eure Prüfung von eingebettetem Code ist mangelhaft.

Comments anyone?

[jens]

Ich nutzte seid je her Cookies für die Session-ID

Schwachpunkte dieser Methode:

• Man könnte den Netzwerkverkehr mitsniffen und kommt so an die Session-Daten.
  Irrewant, weil: Wenn jemand die Netzwerkverkehr mitsnifft, hat er eh das Loginpasswort, das wird schleißlich im Klartext übertragen.
  ...

Nein
Er kommt nicht an das Passwort herran, siehe: http://www.python-forum.de/post-51668.html#51668

Nur, wenn er ein man-in-the-middle ist, dann hat er Zugriff. Aber das hat er auch bei SSH/https:

Am effektivsten lässt sich dieser Angriffsform mit einer Verschlüsselung der Datenpakete entgegenwirken, wobei allerdings die Fingerprints der Schlüssel über ein zuverlässiges Medium verifiziert werden sollten. D. h. es muss eine gegenseitige Authentifizierung stattfinden, die beiden Kommunikationspartner müssen auf anderem Wege ihre digitalen Zertifikate oder einen gemeinsamen Schlüssel ausgetauscht haben, d. h. sie müssen sich kennen. Sonst kann z. B. ein Angreifer bei einer ersten SSL- oder SSH-Verbindung beiden Opfern falsche Schlüssel vortäuschen und somit auch den verschlüsselten Datenverkehr mitlesen.

Und das ich auch der Grund, warum nur signierte, offizielle Zertifikat wirklich was taugen
Wobei mir auch klar ist, das ein unsigniertes Zertifikat wohl besser ist als überhaupt keins

[mitsuhiko]

Und das ich auch der Grund, warum nur signierte, offizielle Zertifikat wirklich was taugen
Wobei mir auch klar ist, das ein unsigniertes Zertifikat wohl besser ist als überhaupt keins

Was hat das damit zu tun?

[jens]

Was hat das damit zu tun?

Nichts, das war indirekt an Leonidas gerichtet:

Wieso sollten "offizielle" Zertifikate sicherer sein?

http://www.python-forum.de/post-51447.html#51447

[Blattlaus]

HTTP ist per Defintion ein Verbindungloses und unverschlüsseltes Protokoll. Wenn man wirklich so sensible Daten hat (und das Passwort zu irgendeiner Community fällt da wohl defintiv nicht drunter), dann sollte man es nicht nutzen. Da kann man anfangen mit irgendwelchen Hashes anfangen und sich irgendwas basteln und so eine Krüppellösung basteln oder man nutzt gleich HTTPS das per Defintion für sowas vorgesehen ist.

Ich versteh immer nicht wieso es sich manche so schwer machen...

[jens]

Ich versteh immer nicht wieso es sich manche so schwer machen...

Darüber nachdenken darf man aber schon, oder?

[keppla]

Darüber nachdenken darf man aber schon, oder?

Klar, darf man. Nur meistens (dies ist nicht die erste Erörterung eines solchen Themas, die ich lese) wird da weniger nachgedacht, sondern viel mehr wilder Aktionismus verbreitet.
Wie gesagt: man kann recht einfach zeigen, dass man HTTP nicht vor jemanden schützen kann, der mithören kann. Damit sollte das Thema erledigt sein (nicht im sinne von "keiner DARF was sagen", ist nicht als Zensur gemeint).

Ich warte schon etwas länger auf meinen lieblings-sinnlosvorschlag, die passwörter vorher per javascript o.Ä. zu md5- oder sha1en.

[jens]

Ich warte schon etwas länger auf meinen lieblings-sinnlosvorschlag, die passwörter vorher per javascript o.Ä. zu md5- oder sha1en.

Hasz du bei http://www.python-forum.de/topic-8180.html nicht mitgelesen?

[Leonidas]

Nichts, das war indirekt an Leonidas gerichtet:

Wieso sollten "offizielle" Zertifikate sicherer sein?

Wie gesagt, ich kann mir auch ein Thawte-Zertifikat besorgen. Und dann?