[dsxs]

Für unseren Onlineshop muss ich mit Sessions arbeiten. Damit dieser auch für User funktioniert, welche Cookies ablehnen, habe ich session.use_trans_sid aktiviert.

Funktioniert bestens, um Hijacking zu unterbinden möchte ich nun jedoch etwas realisieren, was ich auf jeder Seite einbinden kann.

Wie müsste eine solche Funktion aussehen, damit Session Hijacking (Eingabe einer sid über Adresse (GET)) ausgeschlossen werden kann, primär Cookies verwendet werden und trans_sid nur als Fallback angewandt wird?!
Was wenn der User Cookies akzeptiert, dann aber versucht, die ID per GET zu übermitteln?

Über allfällige Codeschnipssel eurer Webshos, Adminpanels etc wäre ich sehr froh.

Danke und Gruss

[Ben]

Das mit dem Fallback könntest du ja so lösen, dass, wenn der User Cookie akzeptiert (etwas ins Cookie schreiben und wieder auslesen und dann vergleichen!), die SessionID per URL nicht erlaubt wird und aus dem URL herausgeschnitten wird.

Werden Cookies nicht akzeptiert ... tjoa .. wüsste nicht, wie man da absichern soll, dass wirklich der "richtige" User mit der SID weiterarbeitet.

Ich würde ja sagen .. wer den Shop nutzen will soll Cookies für ihn akzeptieren. Fertig.

[dsxs]

Hmm letzteres habe ich mir auch bereits überlegt. Leider bin ich jedoch immer noch der Meinung, dass ich es mir nicht leisten kann, von unserer Kundschaft zu erwarten, dass sie diverse Dinge haben oder eben nicht haben - es ist meine Arbeit sicherzustellen, dass es auf jeden Fall funktioniert.

Ich habe schon davon gelesen, die IP des Users in die Session zu packen und jedesmal zu vergleichen. Wenns nicht übereinstimmt, session_destroy und wieder session_start. Bringt's so was?

Sehr mühsam das ganze, aber danke für den Post.

[Ben]

Afaik wechselt die IP bei AOL-Usern aber auch mal so einfach zwischendurch. Das würde also auch nicht so funktionieren, wie du das möchtest.

stell das ganze auf https um und du hast ruhe, alles andere ist kinderkram.

grüße
axo

[dsxs]

Warum wechseln die IP's der AOL user denn einfach mal so? Ist ja voll fürn Arsch?!

SSL ist leider nicht möglich, da nicht von unserem Host unterstützt.

Es muss hier ne Lösung geben, Foren basieren ja prinzipiell auf demselben Prinzip?! Wie handhaben die's?


Gratulation zur neuen Couch axo

Es gibt da so einen methode session_regenerate_id oder so ähnlich (schon lang nix mehr mit php gemacht :>). Da würd ich dir empfehlen, dass du sofern du viele Resourcen hast die ID bei jedem Aufruf neu generierst oder vor dem Bezahlen eine Passwortabfrage machst

Die IP Lösung ist nicht so toll, weil Benutzer oft mit Proxies unterwegs sind.

SSL ist leider nicht möglich, da nicht von unserem Host unterstützt.

Du kannst doch keinen Onlineshop ohne SSL betreiben!

Zitat von dsxs

Warum wechseln die IP's der AOL user denn einfach mal so? Ist ja voll fürn Arsch?!

nein, es ist loadbalancing. das ist schon ok so. (fast) jeder, der hinter einem proxy sitzt, wechselt nach außen seine ip permanent.

SSL ist leider nicht möglich, da nicht von unserem Host unterstützt.

das fällt unter grobe fahrlässigkeit.

Es muss hier ne Lösung geben,

ja, ssl. das wurde dafür gemacht.

Foren basieren ja prinzipiell auf demselben Prinzip?! Wie handhaben die's?

die daten in foren sind bei weitem nicht so sensitiv wie shop-daten, aus diesem grund kann man schlampigere lösungen tolerieren. what the heck, wenn irgend ein cracker einen user-account hijackt und ein paar postings löscht ... das backup spielt das wieder ein und gut is. wenn jemand aber durch einen fehler deinerseits an meine kreditkartennummer (oder sonstige private daten) kommt, hole ich dich als verantwortlichen aber vor's (jüngste) gericht.

Gratulation zur neuen Couch axo

dankeschön... inzwischen ist sie ja gar nicht mehr so neu, die couch... ohje, wie die zeit vergeht :heul:

[dsxs]

Zitat von Jay

Du kannst doch keinen Onlineshop ohne SSL betreiben!

SSL ist für uns im Moment leider nicht möglich, ich sehe keine Alternative.

Was die Bezahlung anbelangt so läuft die selbstverständlich verschlüsselt über den Gateway unseres Finanzinstituts.

SSL würde am Sessionproblem aber rein gar nichts ändern, kann mich aber auch täuschen.

Habe mich entschieden - Ohne Rücksicht auf Verluste: der User muss Cookies erlauben und darf sonst gerne draussen bleiben. Mühsame Sache, aber so passts.

Zitat von dsxs

SSL würde am Sessionproblem aber rein gar nichts ändern, kann mich aber auch täuschen.

doch, weil die verbindung abgesichert wird und die session-ID über einen sicheren kanal hin-und-her-geschickt wird (ob GET oder COOKIE sei egal). damit kann hijacking nur dann passieren, wenn irgend ein depp den URI inklusive session-ID in ein mail kopiert und an den cracker schickt. ohne https kann man die daten an jedem router zwischen webserver und client-rechner anzapfen.

[dsxs]

Zitat von axo

damit kann hijacking nur dann passieren, wenn irgend ein depp den URI inklusive session-ID in ein mail kopiert und an den cracker schickt. ohne https kann man die daten an jedem router zwischen webserver und client-rechner anzapfen.

Wobei wir wieder beim Thema sind.
Das mit SSL ist ein Argument und ich werde versuchen den Host zu überzeugen, uns diese Möglichkeit schnellstmöglichst zu besorgen, damit wir es einsetzen können.

Nun aber zum Hijacken - mein Problem liegt genau dort - User (Deppen), die die sid in der URL weitermailen, in nem IM verschicken, in Foren posten...
Wie kann ich dies kontrollieren?

IP ist schonmal nicht möglich.

Ich sehe gerade zwei Möglichkeiten

1.) den Referer zu checken, wenn die Ursprungsseite nicht eine von uns ist: session weg, neue machen
Frage: Kann ich grundsätzlich auf den Referer bauen oder kann der auch fehlen? Dass er manipuliert werden kann ist klar, aber so sicher muss der Shop auch wieder nicht sein.

2.) User muss Cookies akzeptieren - Ben's Vorschlag. Ich bin nicht sehr überzeugt davon, wenns aber dank Dummheit (bzw. Unwissenheit) unserer Kunden nicht anders geht, oke.

[Ben]

Du kannst so etwas nicht überprüfen. Dummheit ist einfach nicht kontrollierbar.
Wenn jemand sein Passwort mit einer Mail verschickt .. jupp, dann ist das auch nicht kontrollierbar.

Seh ich jedenfalls so!

nein, auf den referer kannst du nicht bauen. nimm zweiteres, mit cookies. und dazu noch ein abschnitt in den online-FAQ, warum cookies die sicherheit erhöhen.

[dsxs]

Danke ihr beiden - genau dafür habe ich mich nun entschieden:

Shop kann normal durchgewühlt werden, sobald jedoch ein Artikel in den Warenkorb gelegt werden soll oder sich ein User einloggen will, braucht er Cookies durchzulassen. Somit erspare ich mir zugleich das Problem, die URLS (bzw die sid darin) für Suchmaschinen rauszuschneiden...
Alle anderen dürfen gerne draussen bleiben...

Dennoch werde ich auf jeder seite ein session_start machen müssen, falls sich jemand anmeldet soll er dies ja auch bleiben. Da meine Sessions grundsätzlich in der Datenbank gespeichert werden kann ich ein Feld 'uses_cookies' definieren und den Wert auf 1 setzen, wenn nach session_start die entsprechende sid vom Cookie ausgelesen werden kann.
Ein Cron der alle zwei Minuten alle Sessions die älter als 5 Minuten sind und bei uses_cookies den Wert 0 haben löscht sollte dann auch sämtliche Sessions eliminieren, die User, welche keine Cookies benutzen bei jedem Seitenaufruf neu gestartet haben...

Nicht sehr Resourceschonend - wobei es auf diesem System diesbezüglich keine Probleme geben wird.
Habt ihr dennoch eine andere Idee?


P.s: der Hint mit SSL gibt mir auch bischen zu denken; ich werde den Host mal zu überreden versuchen, dies verfügbar zu machen.


Danke und Gruss,
dsxs

Ich sags nochmal:

Es gibt da so einen methode session_regenerate_id oder so ähnlich (schon lang nix mehr mit php gemacht :>). Da würd ich dir empfehlen, dass du sofern du viele Resourcen hast die ID bei jedem Aufruf neu generierst oder vor dem Bezahlen eine Passwortabfrage machst

Nur Cookies kannst vergessen.

[dsxs]

Zitat von Jay

Ich sags nochmal:

Nur Cookies kannst vergessen.

Jetzt verstehe ich was du genau meinst. Die sid wird _ständig_ neu generiert, also sowohl im GET als auch im COOKIE permanent neu gemacht.
Hier müsste ich einfach darauf achten, die Datenjeweils in die neue Session zu portieren, falls dies nicht sogar selber bereits passiert (Session wird wohl einfach umbenannt, Inhalt bleibt).

Gut, das würde mir erlauben, den Usern höchstmöglichen Komfort und dazu noch Sicherheit bzgl Sessionklau zu ermöglichen.

Wie verhindere ich jedoch, dass Google&Co meine Links samt sid indexiert, bzw. deswegen nicht beachtet? Session nur starten, wenn es kein bekannter Bot ist? Hat diesbezüglich schon wer was realisiert?

Wenn der User eingeloggt ist wird die ID sowieso geändert, es ist also relativ egal ob da die SessionId drinnen ist oder nicht.

[dsxs]

Richtig, es geht mir hier jedoch mehr um die SuMafreundlichkeit und eine maximale Indexierung.

Session erst nach erfolgreichem Login oder nach "Was-in-Korb-schmeissen" starten wäre eine weitere Möglichkeit.

und wieso sollte die SessionId die Indexierung stören? Man kann die ja auch schön in die URL integrieren:
z.B.
http:/www.asdf.de/produkte/elektronik/tv/flat_screen/samsung/ueberfernseher/31k43jk475l45435j/