Wie Session-Hijacking verhindern?

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 6. Dezember 2006, 11:52

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?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Mittwoch 6. Dezember 2006, 12:05

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
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Mittwoch 6. Dezember 2006, 18:23

jens hat geschrieben: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
TUFKAB – the user formerly known as blackbird
Gromit
User
Beiträge: 51
Registriert: Montag 8. Mai 2006, 19:07

Mittwoch 6. Dezember 2006, 18:29

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.
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 6. Dezember 2006, 18:32

blackbird hat geschrieben:Damit hast du alle AOL user ausgesperrt.
Warum?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Mittwoch 6. Dezember 2006, 19:05

Weil die alle über ein paar wenige Proxies ins "richtige" Internet gehen, also viele User sich die gleiche IP teilen.
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 6. Dezember 2006, 21:58

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

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? :lol:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Donnerstag 7. Dezember 2006, 14:16

jens hat geschrieben:Ja das ist fein. Deswegen sind die AOL Leute aber doch nicht ausgesperrt. :wink:
Deren Proxy Server ändert sich minütlich
TUFKAB – the user formerly known as blackbird
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Donnerstag 7. Dezember 2006, 16:46

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 7. Dezember 2006, 17:44

keppla hat geschrieben: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:
Zen of Python hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 7. Dezember 2006, 18:04

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... :lol:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Blattlaus
User
Beiträge: 55
Registriert: Donnerstag 24. August 2006, 08:55

Freitag 8. Dezember 2006, 09:30

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?
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 8. Dezember 2006, 09:49

Ich nutzte seid je her Cookies für die Session-ID ;)
Blattlaus hat geschrieben: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:
Wikipedia hat geschrieben: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 ;)

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Freitag 8. Dezember 2006, 10:34

jens hat geschrieben: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?
TUFKAB – the user formerly known as blackbird
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 8. Dezember 2006, 10:43

blackbird hat geschrieben:Was hat das damit zu tun?
Nichts, das war indirekt an Leonidas gerichtet:
Leonidas hat geschrieben:Wieso sollten "offizielle" Zertifikate sicherer sein?
http://www.python-forum.de/post-51447.html#51447

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten