Sicherheit von Session-Variablen

[Tobi]

Hi,
ich habe schon in dem Forum gesuchen, jedoch keinen passenden Thread gefunden. Die Frage die mich bewegt ist, ob man vorrausgesetzt man hat die SessionID, die ja praktisch jeder User hab, die serverseitig gespeicherten Informationen der Variablen, also kurz der Session-Variablen manipulieren kann.
Freue mich schon auf Antworten.

MfG
Tobi

 

[Johnson]

Hi,

Session-Daten lagern aufm dem Server standardmäsig im session_save_path und können von außen nicht direkt manipuliert werden.

Gruß

 

[tleilax]

Nuja, wenn man die Session-ID hat, kann man sich der Nutzer authentifizieren, dem die Session eigentlich zugewiesen wurde und kann somit alle Änderungen im System vornehmen, die der User in seinem Account auch vornehmen kann. Direkten Zugriff auf die Daten erhält man nicht (ausser man hat auch Zugriff auf den Server und könnte somit die Sessiondaten mittels der Session-ID identifizieren und direkt manipulieren).

 

[ABC]

Nuja, wenn man die Session-ID hat, kann man sich der Nutzer authentifizieren, dem die Session eigentlich zugewiesen wurde und kann somit alle Änderungen im System vornehmen, die der User in seinem Account auch vornehmen kann. Direkten Zugriff auf die Daten erhält man nicht (ausser man hat auch Zugriff auf den Server und könnte somit die Sessiondaten mittels der Session-ID identifizieren und direkt manipulieren).

Richtig!

Eine duch die (zwingend -> IP) unverschlüsselte SessionsID an sich ist noch schlimmer wie ein Cookie mit Passwort, zuweils die SessionsID noch locker über den HTTP Refferer beispielwiese bei Besuchercountern ausgelesen werden kann. Wer an den Schlüssel kommt, kommt auch an die Session.

So ein Sessions bedingtes Login hast du in 5 Sekunden gehackt. Man braucht nur danach zu Googeln. Dann findet man Listen, (Refferer Listen) "wo kommen meine Besucher her" als Bespiel. So und dann warte bis ein Besucher drauf kommt, der eine Session im Refferer hat.

Beispiel hier im Screen habe ich ca.30 Sekunden gewartet. Was meinst du, was passiert, wenn ich auf den Link klicke?

Damit kein Kiddi auf dumme Gedanken kommt, habe ich das Screen auf der Rechen Seite abgeschnitten!



Das zum Thema Sicherheit. So einfach kann es gehen. Um Cookies auszulesen bedarf es schon mehr an Aufwand. Ein extrerner Code müstte schon eingepflanzt werden. Beispielweise per Sponsoren Script. Oder aber man ist mit einem Trojaner auf der HDD des Users.

Das sicherste ist ja immernoch die htaccess Sicherung. Geht halt nur beim Apache.

Die Variablen selbst sind hingegen, soweit keine Sicherheits riskante Programmierung, (Bugs, Fahlässigkeit, Unwissenheit) eigentlich total sicher!

 

[ZeroCCC]

Eine duch die (zwingend -> IP) unverschlüsselte SessionsID an sich ist noch schlimmer wie ein Cookie mit Passwort, zuweils die SessionsID noch locker über den HTTP Refferer beispielwiese bei Besuchercountern ausgelesen werden kann. Wer an den Schlüssel kommt, kommt auch an die Session.

So ein Sessions bedingtes Login hast du in 5 Sekunden gehackt. Man braucht nur danach zu Googeln. Dann findet man Listen, (Refferer Listen) "wo kommen meine Besucher her" als Bespiel. So und dann warte bis ein Besucher drauf kommt, der eine Session im Refferer hat.

Das ist so nur die halbe wahrheit. Wenn man keine ahnung hat bekommt man selbst mit echo Sicherheitslücken hin. Prinzipiell trit das von dir geschilderte Problem nur auf wenn man die Session IDs an die Links hängt oder hängen lässt. Standardmässig wird die Session ID von PHP nur per Cookie gehandelt was derartige Probleme ausschließt.

 

[Tobi]

Eine duch die (zwingend -> IP) unverschlüsselte SessionsID an sich ist noch schlimmer wie ein Cookie mit Passwort, zuweils die SessionsID noch locker über den HTTP Refferer beispielwiese bei Besuchercountern ausgelesen werden kann. Wer an den Schlüssel kommt, kommt auch an die Session.

Sehe ich die Sache richtig, dass die SessionID normalerweise über einen Cookie weitergegeben wird und nur in den Fällen, in denen Cookies clientseitig oder serverseitig nicht zugelassen werden, die SessionID über die URL übertragen wird. Außerdem glaube ich irgendwo gelesen zu haben, dass man zusätzlich noch einstellen kann, dass die Session nur in Cookies gespeichert werden soll. Ist das korrekt, oder habe ich mich da geirrt?
Edit: Merk grad dass die Frage in der Zeit, in der ich geschrieben habe schon so gut wie beantwortet wurde.

Die Variablen selbst sind hingegen, soweit keine Sicherheits riskante Programmierung, (Bugs, Fahlässigkeit, Unwissenheit) eigentlich total sicher!

Ich wär dir sehr verbunden, wenn du mir u.U. die Dinge, die man falsch machen kannt einmal erläutern könntest, oder falls du irgendwo einen Link rumliegen hast den posten könntest, da mir momentan die Vorstellungskraft fehlt, mir solche Bugs ect. vorzustellen.

@All: Vielen dank für die Erklärungen.

MfG
Tobi

 

[ABC]

Standardmässig wird die Session ID von PHP nur per Cookie gehandelt was derartige Probleme ausschließt.

Was interessiert das den Client? Wenn sein Browser das Cookie nicht verarbeit, oder er gar keins möchte, hat der Client ein echtes Problem. Weil du als Progger überhaupt kein Einfluss hast was letzt endlich sein Browser verarbeitet. Die Entschuldigung, das Standardmässig PHP die SessionsID ist ein Cookie speichert, entschuldigt nicht das Verhalten, wenn der Weg per Cookie Clientseitig nicht funktionieren wird, und PHP in Folge vom Cookie absehen wird.

Was ich damit sagen will, letzt endlich entscheidet PHP und nicht der Programmierer. Standard ist 2 Wege und nicht nur das Cookie. Und genau das ist ja das Problem.

Wenn der Browser des Clients eine SessionsID an das Script (und sei es aus Dumm Grund 27) übergibt, dann kannst du dich noch so viel entschuldigen, dass du auf Cookies speicherst. Nur das wird den Browser des Clients einen feuchten jucken. Und dein PHP Script noch so wenig.

Der Browser wird hier automatisch dem Refferer die SessionsID anhängen, auch wenn diese nicht im Script (Quellcode) selbst steht. Da gibt es ganz andere Gründe.

Also um Klartext zu machen. Auch wenn in deinem Script kein feuchtes:

<A href="test.session.php?<?php=SID?>"> stehen hast,

kann dies der Client selbst daraus erzeugen, und die Sid von allein über die URL übergeben. Dazu hat er gute Gründe. Z.b. das verbieten von Cookies unter anderem. Du hast 0 Einfluss was im Refferer steht.

Der Refferer wird vom Browser übergeben. Ich verstehe so nicht, was das mit dem Cookie zu tun haben soll.

 

[ZeroCCC]

[...]

Da liegst du einen trugschluß auf. Ja wenn der Browser des Besuchers das Session Cookie nicht akzeptiert wird das definitiv Probleme bereiten, aber dass sind nicht meine Probleme Ich kann schließlich auch gewisse ansprüche an den User stellen und da mach ich mir auch keine Waffel wenn mal einner von x tausend Besuchern in die röhre schaut. Der Fehler bei deinen gedanken gang leigt aber darin dass die Session Id nicht vom Browser sondern von PHP angefügt wird. Und das verhalten von PHP ist in der php.ini (oder ähnliches) hinterlegt und standardmässig steht das Session-Handling auf Only-Cookies... was schonmal eine menge Sicherheitsprobleme umgeht und bei weitem performance freundlicher ist als das automatische einfügen von Session Ids.

 

[veers]

Was ich damit sagen will, letzt endlich entscheidet PHP und nicht der Programmierer. Standard ist 2 Wege und nicht nur das Cookie. Und genau das ist ja das Problem.

Ich mag PHP ja auch nicht, aber das ist schlicht und einfach nicht so. Du kannst ziemlich genau einstellen wie das mit der Session läuft. Sollte dir das nicht reichen kannst du auch deinen

Wenn der Browser des Clients eine SessionsID an das Script (und sei es aus Dumm Grund 27) übergibt, dann kannst du dich noch so viel entschuldigen, dass du auf Cookies speicherst. Nur das wird den Browser des Clients einen feuchten jucken. Und dein PHP Script noch so wenig.

Der Browser wird hier automatisch dem Refferer die SessionsID anhängen, auch wenn diese nicht im Script (Quellcode) selbst steht. Da gibt es ganz andere Gründe.

Falsch. Nenne mir einen Browser welcher den Wert eines Cookies automatisch an die URL hängt.

kann dies der Client selbst daraus erzeugen, und die Sid von allein über die URL übergeben. Dazu hat er gute Gründe. Z.b. das verbieten von Cookies unter anderem. Du hast 0 Einfluss was im Refferer steht.

Beweisen

 

[ABC]

Da liegst du einen trugschluß auf. Ja wenn der Browser des Besuchers das Session Cookie nicht akzeptiert wird das definitiv Probleme bereiten, aber dass sind nicht meine Probleme Ich kann schließlich auch gewisse ansprüche an den User stellen und da mach ich mir auch keine Waffel wenn mal einner von x tausend Besuchern in die röhre schaut. Der Fehler bei deinen gedanken gang leigt aber darin dass die Session Id nicht vom Browser sondern von PHP angefügt wird. Und das verhalten von PHP ist in der php.ini (oder ähnliches) hinterlegt und standardmässig steht das Session-Handling auf Only-Cookies... was schonmal eine menge Sicherheitsprobleme umgeht und bei weitem performance freundlicher ist als das automatische einfügen von Session Ids.

Nochmal! Du gehst hier aus 3 Standpunkten aus.

- Erstens die des Programmierers , der in der Regel keinen Zugriff auf die ini haben muss.

- Zweitens die des Hosters, der die notwendigen Sicherheitsmaßnahmen in der ini Anpassen kann, was aber jedoch das Problem nur einschränken und nicht beheben kann.

- Drittens die des Clienten, der dich garnicht interessiert.

Das was mir daran nicht gefällt. Das kann nicht das Ziel sein nur an seine Seite zu denken. Letzt endlich ist es dein User, und letzt endlich ist es dein Script. Und wenn der User Y den auf sein Space zieht, wo zu 99% ohne eigenen Server nicht an der ini gefummelt werden kann, muss das auch funktionieren.

Also du kannst eine Session, die nicht durch deine eigene IP verschlüsselt wurde, für eine "Hier ist nichts interessantes" Seite annehmen. Für Seiten die Beispielweise Zahlungsverkehr abwickeln, oder wertvolles vorliegt, ist das zu knicken.

Du kannst ja nicht ernsthaft dem Kunden vermitteln: Tut mir leid, dass ihr Guthaben in Höhe von 1.045 Euro fehlt. Aber ich bin nicht für ihren Browser verantwortlich. Das bist du auch wirklich nicht. Nur du siehst keinen Kunden mehr.

Bei einer IP verschlüsselten Session hingegen kannst du prüfen, ob die Verschlüsselung zu IP passt. Wenn dies nicht der Fall ist, kannst du sie terminieren. Nachteil der Sache ist, die Session ist wertlos, wenn der Client seine IP wechselt.

Letzt endlich, geht dich das Problem schon an, was der Browser macht. Den der Kunden hat davon keinen blassen Schimmer. Dazu gibt es Leute wie dich, und dazu wird man gebraucht. (Der 0815 Kunde geht davon aus, dass Computer sicher sind, und so lange keiner sein Passwort kennt, schon nicht passieren kann). Das Problem ist nur, dass du die SessionID an den Clienten abmüllst. Es ist nicht dem Kunden sein Passwort was ausspioniert wurde, sondern ein Key deines Servers. Letzt endlich wird mit deinem Bockmist gehackt, und nicht auf die des Kunden.

Und naja ich kenne keinen Browser der anders reagiert. IE Fifo alles gängige arbeitet so.

Ich kenne viele Leute, die so schlau waren das ändern eines Passwortes nur mit der alten Passwort zu ermöglichen. Das ist wunderbar. Nur das Passwort kann man sich zusenden lassen. Und die E-Mail konnte man ohne Passwort ändern. Solche Scripte kann man einem andrehen, der irgend was betreibt, was keine Wertdaten darstellt. Da kann sich dann ein Kiddi freuen, dass er es auch mal geschafft hat, irgend ein Forum zu hacken, oder ein Gästebuch zu administrieren. Davon kaufen kann er sich nichts.

Letzt endlich ist das so, und schon ein uraltes Problem. Unverschlüsselte PHP Sessionsids sind nun Mal für den Arsch.

P.s. Ein richtig erfahrerner Phisher macht mit einer Sessionsid in 5 Sekunden (und das meine ich ernst) kurzen Prozess.

Man kann sich auch unverschlüsselt schützen!

Beispiel: zur Sessionsid einen weiteren Key genereieren, der per Cookie übergeben wird. Wenn das Cookie nicht angenommen wird. Muss dem Clienten der Zutritt verweigert werden! In diesem Cookie hat kein Passwort sondern ein weiterer Key was zu suchen. Der hat wiederum in der DB die dazugehörige SessionsID stehen. So wenn die SessionID übergeben wird, wir diese vor session_start() abgefangen. Es wird das Cookie angefordert, und beide Keys ausgelesen.

Nun kann der Phiser mit dem Session Hash nichts mehr anfagen, denn er hat das Cookie nicht. Wenn man das ganze jetzt nur noch durch die IP verschlüsselt, kann man sehr sicher gehen.

Eine andere alternative wäre, Transaktionen nochmals per Passwort zu schützen. Also vor jeder Transaktion erneut Passwort abfragen.

- Passwörter nicht ändern lassen!
- E-Mailänderungen nur mit Passwort!
- Die Erste E-Mailadresse bleibt immer im System auch wenn sie gewechselt wird. (Verschleirungsversuche)
- Beim ändern der Mailadresse muss die neue Ziealdresse bestätigt werden, eher die Adresse angenommen wird.
- Bei fehlerhaften Login Versuchen den Account zeitweise sprren und den User benachrichtigen.
- Keine Sicherheitsrelevanten Änderungen ohne Passworteingabe Auch wenn man eingeloggt ist! (auch hier die Fehlerversuche nicht vergessen)!
- SessionID reicht nicht aus
- Im Cookie hat das Passwort nichts verloren!

Das sind so Kleinigkeiten, die eine Seite erst richtig sicherer machen.

Man kann Seite Webseite sicherheitstechnisch ganz einfach hinterfragen:

Man frägt sich, was ist wenn ich als Cracker in meine Seite an

- SessionsID komme
- DasCookie ausspähe
- Versuche das Passwort zu Cracken
- Über eine SQL Injection versuche

Nur wenn man sich Gedanken macht, was in solchen Fällen sein kann, dann ist man relativ sicher.

Dazu gehört aber auch dem User zu sagen, verigss das 4Stellige Passwort ohne Sonderzeichen. Das kannst du bei Tante Emma verwenden. Usw...

Es mangelt an Aufklärung und nicht an Bugs. Denn wirklichen Mängel in Sachen Sicherheit, entstehen nicht durch Programmierfehler selbst, sondern durch Mangel an Aufklärung wie es geht, und wie was funktioniert.

Ich kann nur dann ein realtiv sicheres Schloss in meine Haustür einbauen, wenn ich mich über die Vorgehensweisen von Einbrechern informiere. Und nur so kann ich einen realtiv sichereren Weg finden. Sicher ist leider garnichts, und Aufklärung gehört dazu.

Ich lache immer wenn ich lese:

Jetzt sicher einzahlen blabla SSL..... "Sicher einloggen..."
Alles wird als "Sicher verkauft"
man glaubt sich alles sicher.

Aber die SessionID von PHP ist alles andere als das!

 

[ZeroCCC]

Ach gott...

Das was mir daran nicht gefällt. Das kann nicht das Ziel sein nur an seine Seite zu denken. Letzt endlich ist es dein User, und letzt endlich ist es dein Script. Und wenn der User Y den auf sein Space zieht, wo zu 99% ohne eigenen Server nicht an der ini gefummelt werden kann, muss das auch funktionieren.

Doch das Ziel ist immer nur an das Projekt zu denken, dazu zählen aber zwangsläufig auch die User. Ein Projekt hat meistens eine definierte Zielgruppe und an Zielgruppen kann ich gewisse anforderungen stellen. Ich brauch nicht ein Projekt dahin auslegen das es auch ein Japaner am Südpol mit nem Wap Handy nutzen kann. Wenn ers nutzen kann schön und gut, dass ist aber für mich nicht von interesse. Natürlich wenn ich eine Community für Japaner die aufm Südpol leben erstellen soll, dann ist das wiederum durchaus interessant für mich. Sprich, wer sich in sinnlose unwessentlichen details verrent macht was falsch...

Und zum Thema Server wechseln, es ist genau das selbe. Ist das eine geforderte/gewünschte eigenschaft dann werde ich das berücksichtigen und mich auf einen vernüftigen nenner einigen. Ist das nicht gefordert dann nutze ich die mir zurverfügung stehende funktionalität aus, und es interessiert mich nicht ob das Script nur auf einem Server läuft der entsprechend eingerichtet werden muss. Es ist nur immer eine frage von Kosten/Nutzen. Wieso sollte ich auch ein Projekt dahin auslegen dass es auch ja noch auf einen Server mit PHP4 und Mysql3 läuft obwohl ich genau weiß dass ich selbst bestimmen kann was der Server unterstützen soll. Da kann ich auch wenns mir mehr bringt python und postgre nutzen.

Ich hab selbst Projekte die Firefox vorraussetzen... und warum? Weil ich weiß dass die Zielgruppe zwangsläufig Firefox nutzen. Von daher kann ich mir die Arbeit ersparen das ganze in anderen Browsern zu testen und eventuell anzupassen.

Du kannst ja nicht ernsthaft dem Kunden vermitteln: Tut mir leid, dass ihr Guthaben in Höhe von 1.045 Euro fehlt. Aber ich bin nicht für ihren Browser verantwortlich. Das bist du auch wirklich nicht. Nur du siehst keinen Kunden mehr.

Das ist aber so. Ich kann nur sichterstellen das keine Sicherheitslücken meinerseits existieren, gegen kompromitierte Cleintsysteme kann ich nix machen, wenn sie nicht unter meiner obhut sind. Ich kann schleißlich nicht die User zwingen ihr System prüfen zu lassen und ein wenig Sicherheitsbewusstsein zu entwickeln/haben.

PS: mach dich mal schlau wie die PHP-Sessions genau funktionieren. Solang die Session Id nur im Cookie abgelegt wird, kann man sich sämtlichen Aufwand ersparen den du beschrieben hast... und wie gesagt der Entwickler entscheidet wie und was wenns nicht anders gefordert ist. Und in meinen Augen sind Session Ids in Urls nicht sinnvoll, angefangen bei den von dir zum teil beschreibenen Sicherheitsproblemen (es gibt noch mehr), über performance einbußen, bis hin zu seo.

 

[ABC]

Es ist nur immer eine frage von Kosten/Nutzen. Wieso sollte ich auch ein Projekt dahin auslegen dass es auch ja noch auf einen Server mit PHP4 und Mysql3 läuft obwohl ich genau weiß dass ich selbst bestimmen kann was der Server unterstützen soll.

Das sicherlich!

Ich kann nur sichterstellen das keine Sicherheitslücken meinerseits existieren, gegen kompromitierte Cleintsysteme kann ich nix machen, wenn sie nicht unter meiner obhut sind. Ich kann schleißlich nicht die User zwingen ihr System prüfen zu lassen und ein wenig Sicherheitsbewusstsein zu entwickeln/haben.

Das soll ja auch kein Übergriff an dich selbst sein. Es soll nur zeigen, das selbst erfahrene Leute nicht alles bedenken können. Das spiegelt natürlich deine Antwort wieder. Man kann nicht alles berücksichtigen. Allerdings ist es für mich immer noch fraglich, obwohl jeder weis, wie unsicher es ist, wird es dennoch benutzt, weil es einfach bequem ist.

Ich kann dir nur ein Beispiel machen. Das VB Forum hier hat ein Session Login. Wenn du aber bei VB eine Lizenz bei VB erwibst, kommst du an ein htacess Login? Merkst was? - Immer im nutzen, für sich das beste, für dumper das einfachste.