können session-cookies manipuliert werden?

[Cord Worthmann]

dies ist eigendlich keine spezielle PHP-frage (sie könnte genauso gut auch im ASP-forum gestellt werden können), aber ich habe mal dieses forum wegen seiner höheren frequenz gewählt.

eigendlich steht schon alles im titel - "kann man session-cookies auf irgendeine art clientseitig manipulieren?"

das ist ja vor allem insofern sehr interessant, da viele entwickler die session-cookies ja nutzen, um darin benutzer-angaben (z.b. passworte) abzuspeichern.


grtz
chief

[Felix Kaiser]

In der Theorie ist alles irgendwo manipulierbar, nur die Schwierigkeit der Manipulation differenziert sehr. Bei Cookies ist das schon recht knifflig, da sie vom Server verschlüsselt werden und auch nur verschlüsselt wieder beim Server landen. Zu dem ist der Server der einzige der sie wieder entschlüsseln kann (siehe Prinzip Unix crypt()).

[Cord Worthmann]

bei php/unix ist das klar, da gibt es ja die wunderbare encrypt-funktion als standard...
aber bei ASP muss so eine encrypt-funktion natürlich wieder mal als extra-komponente installiert werden :-( !

da würde mich das halt mal interessieren (hätte wahrscheinlich doch eher in ASP-forum gehört), wie das insbesondere mit den session-cookies ist - kann man als client überhaupt irgendwie an sein session-cookie herankommen? wo wird es gespeichert?


grtz
chief

[Felix Kaiser]

Die Verschlüsselung der Cookies übernimmt der Server (httpd), nicht php Interpreter, nicht Perl Interpreter und auch nicht der ASP Interpreter. Welche Methode allerdings unter Windows verwendet wird, weiß ich nicht genau. Hab dort auch noch nicht näher reingeschaut :(

[KarateKid]

Könnte man Cookies oder Sessionvariablen manipulieren oder imaginär darstellen, hätten Sie ja keinen Sinn mehr :)

Nein, wenn man seinen Rechner gut geschützt hat und sich die Cookies nicht klauen lässt, dann sollte da doch nichts passieren :)

[Jan Krüger]

Meine Cookies für dieses Board werden vom Server offensichtlich nicht verschlüsselt. Die User-ID steht im Klartext drin und das Passwort sieht mir schwer nach MD5-Hash oder Ahnlichem aus. Obwohl ein Hash die Sache an dieser Stelle nicht unbedingt sicherer, sondern eher unsicherer machen würde.
Und wenn jemand dir die Cookies klaut und exakt so an den Server schickt, hat er deinen Zugang. Außer, die Sessions sind an eine IP-Adresse gebunden (wie bei meinem großen momentanen PHP-Projekt ;))...

[KarateKid]

Wo findet man dein großes momentanes PHP Projekt? :)

[Cord Worthmann]

ich muss meine frage nochmal etwas umformulieren...

gegeben dem fall, in session-variablen werden unverschlüsselte werte abgelegt - ist es dritten möglich (welche sich in die verbindung einklinken), die session-variablen abzufangen und dann ggf. auszulesen?


grtz
chief

[sami]

also per crypt werden die sessions bestimmt ned verschlüsselt.
crypt wär ned umkehrbar (auch ned vom server selbst), da es einen hash macht.

[Felix Kaiser]

Welchen Zweck hat eine Verschlüsselung die nicht entschlüsselbar ist? In meinen Augen so sinnvoll wie ein Sandkasten in der Wüste :rolleyes:

[sami]

falsch.
crypt wird z.b. für sämtliche passwörter der unixwelt verwendet.
da wird das passwort verschlüsselt (bzw. als hash) abgelegt.
wenn nun einer ein passwort eingibt, wird das ebenfalls durch crypt gelassen, danach werden der gespeicherte hash mit dem neuen verglichen und wenn er stimmt war es (mit grösster wahrscheinlichkeit) das selbe passwort.
geht bei windows übrigens genau gleich, nur wird da ned crypt verwendet.

[Felix Kaiser]

Erscheint mir unlogisch, wenn bei beidem Verschlüsselungen dasselbe Ergebnis rauskommt, gibts auch nen Weg das wieder rückgängig zu machen. Auch wenn noch keiner draufgekommen sein sollte, solange bei gleichem Input derselbe Output herscht gibts eine Möglichkeit.... Alles andere wäre unlogisch.

[cYrus]

@Guru
es gibt ja mehrere Inputs die den gleichen Output ergeben! :] wie willste da auf den gedanklichen Input kommen? ;)

so long
cYrus

[Felix Kaiser]

Dann isses keine echte Verschlüsslung mehr, sondern eher Prüfsummenberechnung. Und das geht freilich nicht mehr rückgängig, ist klar.

[sami]

Original von Guru
Dann isses keine echte Verschlüsslung mehr, sondern eher Prüfsummenberechnung. Und das geht freilich nicht mehr rückgängig, ist klar.
ich rede ja die ganze zeit von hash (das ist ne prüfsumme).
zu knacken ist das nur per bruteforce, und auch da ist nicht sichergestellt, ob man nun das tatsächliche passwort hat.

[Felix Kaiser]

Orginal von sami
da wird das passwort verschlüsselt (bzw. als hash) abgelegt.

Und nun mecker nicht rum X(
Ich habs verstanden. Ist nur blöd die Routine dann crypt zu nennen, naja, deren Schöpfer sind für mich halt ein Völkchen für sich :)

[Jan Krüger]

Original von KarateKid
Wo findet man dein großes momentanes PHP Projekt? :)

noch gar nicht, aber ich arbeite dran, und wenns was wird, werdet ihr es in ein paar monaten in einer großen community-webseite wiederfinden ;)...

zu crypt: ja, der name ist etwas ungünstig gewählt.
zu sessions: die session-ID wird bei jedem Erstkontakt mit der Seite zugewiesen und in einem cookie gespeichert, und danach bei jedem seitenaufruf mitübermittelt. der server sieht die ID in der datenbank (oder woanders) nach und liest dort die entsprechenden session-variablen (username, passwort, einstellungen etc.) aus. optimalerweise überprüft der server vorher, ob die anfrage von der gleichen adresse kommt, an die die Session-ID vergeben wurde. Wenn ein solcher Mechanismus fehlt, kann jeder, der die Session-ID kennt, die Session weiterbenutzen.
Ein Sicherheitsmechanismus, der fast immer integriert ist, sorgt dafür, dass die Session-ID nach einer bestimmten Zeitspanne (z.B. 30 Minuten) verfällt.
Bei diesem Board hier werden in zwei weiteren Cookies die User-ID und das Passwort (irgendwie verschlüsselt, keine Ahnung :D) gespeichert. Wenn die Session-ID abläuft, kann somit sofort eine neue Session mit Authentizierung eröffnet werden. Für Leute, deren Browser Cookies unterstützt, sind Session-IDs in diesem Board daher sinnlos, weil die Logindaten sowieso immer mitübermittelt werden.

[Cord Worthmann]

die funktion, welche den gültigkeitsbereich einer session-variablen festlegt, ist der session-timeout, und der ist serverseitig.
bei asp zumindest hast du nicht die möglichkeit die lebensdauer einzelner session-variablen zu beeinflussen - sondern lediglich den sesssion-timeout!

das was du da gerade zu session-ids und deren abgleich mit datenbankwerten sagtest, kann so nicht stimmen!
der server vergibt an jedes neuen browser eine neue session-id mit der lebensdauer session-timeout. angenommen, du machst keine aktionen mehr oder schliesst einfach das browser-fenster oder klickst woanders hin, dann würdest du ja schon beim nächsten aufruf der seite keine passende session-id mehr zu deinen db-einträgen haben, so dass der login scheitern würde.
ausserdem, sollte der server mal runtergefahren werden, fängt er jedesmal mit den session-ids wieder bei ´´0´´ an.
nein, um das zu ermöglichen, müsstest du eine eigene id einführen, welche beim login die daten abgleicht, und welche fix ist, so dass sie z.b. auch mit daten in einem cookie verglichen werden kann.
mit der server-session-id ist es zumindest nicht möglich.

also ASP codiert seine session-variablen automatisch - soviel konnte ich nun schon in erfahrung bringen - ein javascript, welches von logindaten und cookie-daten einen hash (md5,sha1) anlegt, habe ich auch schon gefunden - halt wie bei linux das crypten, nur ohne componente dazuinstallieren.

weiss denn nun wer, ob es möglich ist, die mitgesendeten session-cookies abzufangen und auszulesen, oder nicht?


grtz
chief

[Cord Worthmann]

Original von Guru .... Ist nur blöd die Routine dann crypt zu nennen, naja, deren Schöpfer sind für mich halt ein Völkchen für sich :)



was ist daran falsch?
´´crypten´´ heisst nicht verschlüsseln sondern unentzifferbar machen - der ausdruck ist also richtig!

du hast doch sicher schonmal von cryptischer hanschrift gehört?! ;-)
das ist keine verschlüsselte sondern absolut unleserliche handschrift.


grtz

[Jan Krüger]

die sachen, die ich gepostet habe, sind im wesentlichen schon korrekt (denke ich... ;)), aber ich glaube, ich habe mich nicht deutlich genug ausgedrückt.

Das mit den Session-Timeouts stimmt. So und nicht anders habe ich es auch gemeint. Auch stimmt es, dass die Timeouts serverseitig passieren. ;)

Die Sache mit der Datenbank hast du allerdings möglicherweise falsch verstanden.
Um genau zu sein, PHP4 speichert die Sessiondaten standardmäßig nicht in einer Datenbank, sondern in Flat Files.
In den Session-Daten werden *nur* solche Daten gespeichert, die nur während der Session gültig sind, also z.B. Username/-ID und Passwort und vielleicht noch irgendwelche Informationen, welche Foren man gelesen hat, damit die Einfärbung der Icons korrekt passieren kann.
Alles andere (Userprofil und -einstellungen) wird in einem separaten Speicher abgelegt. Die Sessions werden meistens ausschließlich dazu benutzt, jemanden identifizieren zu können.

Folgendermaßen arbeitet das wBB:
Session-IDs werden in einem Cookie gespeichert. Außerdem aber auch User-ID (unverschlüsselt) und Passwort (verschlüsselt/gehasht oder so).
Deshalb sind die Session-IDs im wBB eigentlich überflüssig, solange der User Cookies aktiviert hat.

Und zu deiner ursprünglichen Frage nochmal. Man kann Cookies abfangen und auslesen. Ich habe Mozilla als Browser, da gibt es sogar eine Funktion dafür, alle Cookies mitsamt Inhalt zu lesen.
Ob der Inhalt der Cookies verschlüsselt ist, obliegt dem Script, das sie an den Browser schickt.

Hier sind meine Cookies fürs coding-board:
user_password - be1849f1467fb4e7bab742c02a1f873c (aus Sicherheitsgründen abgeändert)
user_id - 673
vote_poll[] - 1
PHPSESSID - be1849f1467fb4e7bab742c02a1f873c (aus Sicherheitsgründen abgeändert)

Da user_id und user_password hier sowieso bei jedem abruf mitübermittelt werden, hätte man sich im wBB den Cookie PHPSESSID sparen können.

[Cord Worthmann]

da haben wir wohl doch ein bisschen aneinander vorbeigeredet... :-)

du meinst, dass nach erfolgtem erfolgreichen login (entweder über auslesen eines cookies oder manuellen login) die session-id mit zur verifizierung des session-inhabers (man selber) dient - richtig?

...das habe ich nun auch so verstanden.

ich dachte, du meinst, das sofort beim betreten der site die automatisch vergebene session-ID dazu dienen kann, den user in der db zu identifizieren - was natürlich nicht geht, sondern nur dann, wenn der user einmal einwandfrei identifiziert wurde (s.o.)

übrigens - wenn der browser cookies annimmt und das nicht explicit im script unterbunden ist, wird überall die session-ID in jedem fall versendet - das dient natürlich der browser-identifizierung.

noch mal zu meiner frage - es geht mir im grunde, vor allem darum, ob ein dritter das session-cookie abfangen könnte - um z.b. das passwort zu entnehmen, und zu entschlüsseln (sollte, für die, welche ahnung haben, ja kein prob sein)....
danach könnte dieser dritte nämlich sein eigenes cookie manipulieren, indem er dieses entschlüsselte und anschliessend gehashede PW dort einsetzt (und ggf. mit dem usernamen eines abgefangenen session-cookies genauso verfährt, oder anderen relevanten daten)???
das würde mich interessieren - die gefahr durch dritte!


grtz
chief

[Jan Krüger]

Es ist unwahrscheinlich, dass jemand Cookies oder irgendwelche HTTP-Kommunikation abfängt und austauscht.
Aber es ist theoretisch möglich.
Kann zum Beispiel durch einen zwischengeschalteten Router passieren, den sich ein Cracker unter den Nagel gerissen hat.
Hier kann man noch mit SSL-Cookies zusätzliche Sicherheit kriegen.

[Cord Worthmann]

aber denkbar ist das wohl schon, oder?
ich werde für mein projekt auf jeden fall nur noch gehashede daten im regulären cookie ablegen (abgesehen von lastvisit u.ä.), und bei manuellem login werden die übermittelten daten auch gehashed - man weiss ja nie!

ssl ist natürlich immer ne gute idee - aber für mein vorhaben muss immer von den minimalsten bedingungen ausgegangen werden.
also maximal machbare sicherheit, die aber auf jeder art von webspace läuft.

danke für die hilfe


grtz
chief

[Jan Krüger]

Hashen bringt in der Regel nicht viel mehr an Sicherheit. Macht für mich auch keinen Sinn - Hashes sind ja nur dazu gut, dass man nicht herausfinden kann, welche Daten ursprünglich angegeben wurden. Wenn direkt der Hash von z.B. einem Passwort übermittelt wird, kann man ihn sich auch direkt sparen, das wäre so, als würde man nur Fotos von einem Schlüssel in eine Tür stecken und die Tür nimmt auch die Fotos an ;).
Angenommen, jemand fängt so gehashte cookies ab, kann er sie selber weiterbenutzen. Denn wenn man sowieso nur das gehashte passwort per Cookie schicken muss, um authentifiziert zu werden, hat er ja alle Informationen.

Auf jeden Fall wünsche ich dir bei deinem Projekt viel Erfolg. :)

[Cord Worthmann]

ja, aber so funzt das doch auch auf allen boards u.ä., wo eine automatische identifizierung bzw. authentifizierung über ein auf dem client-pc gespeichertes cookie stattfindet, welches die gehasheden userdaten enthält.
wie sonst sollte das boardscript mich immer wiedererkennen und automatisch einloggen ohne dass ich meine benutzerdaten selber eingeben muss?


grtz
chief

[Jan Krüger]

nuja, das hashen kann man sich fast sparen. es bringt nur einen vorteil - niemand kann sehen, wie das passwort im klartext geheißen hätte. aber jeder, der an die cookies drankommt, kann sie dann trotzdem benutzen, um sich damit zu authentifizieren.

[Cord Worthmann]

eben, so ist es!

daher ist ein cookie immer eine schwachstelle - das beste ist, wenn der user beim ersten login entscheiden kann, ob sein pass (gehashed oder nicht) im cookie gespeichert werden soll.
will er das nicht, so muss er sich zwar jedesmal neu einloggen - hat aber eine wirklich sichere sache.

ich mache das so, dass der user wählen kann.


grtz
chief