idee für sichere sessions

[BigBen]

hi leute,

klingt vielleicht etwas sehr trivial gedacht, aber muss ja deswegen nicht uneffektiver sein. hab schon viele posts hier durchgeklappert zum thema sichere sessions und da ich momentan selbst ein sicheres script am basteln bin, stoße ich natürlich auch auf die problematik.

meine idee für eine sichere session:
nach dem login wird die id, ip (allerdings md5-verschlüsselt) und das rechtelevel (z.b. admin oder normalregistrierter user) in der session registriert. auf jeder seite wird dann die momentane md5-verschlüsselte ip des benutzers mit der abgespeicherten md5-verschlüsselten ip in der session überprüft. falls die ips sich unterscheiden, wird die session beendet und der benutzer muss sich neu anmelden.

alternativ könnte man dazu auch noch den user_agent (auskunft über browser und betriebssystem) hinzunehmen, also user_ip*useragent, das ganze dann md5 verschlüsselt.

in meiner momentanen logik sehe ich keine sicherheitslücke, da man lediglich auf einem computer mit seiner id und passwort eingeloggt sein kann. sobald eine zweite session von einem anderen computer mit geklauten sessiondaten gestartet wird, bricht die session ab. ausnahmefall wäre bei dieser variante, dass leute, die über gleichen proxy (demnach über gleiche ip) ins netz gehen und eventuell gleichen browser und gleiches betriebssystem nutzen, sich dort einloggen können. aber bei weiteren überlegungen fällt mir keine situation ein, in der es für eine person schlimm sein könnte, wenn dieser sonderfall zutrifft. es sei denn ein kumpel hackt sich bei einer lan da mit den sessiondaten des freundes rein, aber wenn er das geschafft hat, ist er immerhin an die rechteeinschränkungen gebunden, die sein freund auf der hp zugeordnet bekommen hat

was haltet ihr davon? bisher bin ich davon überzeugt und möchte das in der art auch mal angehen. vielleicht seht ihr trotzdem sicherheitslücken und habt änderungsvorschläge. mehrere köpfe kommen eher zu einem ergebnis, also lasst uns unsere seiten sicherer machen

[goth]

Wird ein bißchen lästig für Benutzer die über AOL bzw. T-Online kommen ... die haben 'ne Batterie transparenter Proxy dazwischen ... und dürfen sich dann auf jeder Seite neu anmelden ...

... der md5 hilft dir nur gegen Benutzer die direkten Zugriff auf die Session-Files haben ... und denen dürfte das eh wursch sein ...

[BigBen]

heisst das, dass t-online und aol-kunden ständig die ip wechseln, wenn die online sind? sprich jede minute neue ip oder was? wenn ja, was könnte man weiter nutzen, um den individuelle details eines users auf übereinstimmung zu überprüfen? user_agent schränkt ja schonmal auf betriebssystem, web-browser und sprache ein.

wieso soll md5 unsicher sein? mit md5 verschleier ich zum einen, dass für mich ip und user_agent zur überprüfung einer gültigen session dazugehören, da ja in der sessiondatei nur der 32-stellige code zu sehen ist und zudem ist dieser code nicht entschlüsselbar, da md5 = one-way-codierung. d.h. ich kann sofort mit den systemvariablen überprüfen, ob ich den user mit der ip und dem user_agent auf meiner seite habe oder nicht.

PS: bin selbst t-online-kunde und über router im netz. ich habe meine ip ausgelesen mit einem script und der zeigt mir immer die gleiche ip an... sprich auf t-online-kunden trifft dies wohl nicht zu...

[goth]

Original geschrieben von BigBen
heisst das, dass t-online und aol-kunden ständig die ip wechseln, wenn die online sind? sprich jede minute neue ip oder was? wenn ja, was könnte man weiter nutzen, um den individuelle details eines users auf übereinstimmung zu überprüfen? user_agent schränkt ja schonmal auf betriebssystem, web-browser und sprache ein.

Nicht jede Minute ... aber bei jedem Zugriff ...

Original geschrieben von BigBen
wieso soll md5 unsicher sein? mit md5 verschleier ich zum einen, dass für mich ip und user_agent zur überprüfung einer gültigen session dazugehören, da ja in der sessiondatei nur der 32-stellige code zu sehen ist und zudem ist dieser code nicht entschlüsselbar, da md5 = one-way-codierung. d.h. ich kann sofort mit den systemvariablen überprüfen, ob ich den user mit der ip und dem user_agent auf meiner seite habe oder nicht.

Es geht nicht um sicher oder unsicher ... es geht darum das es bei einer IP die in einer Session gespeichert ist, wo also ein externer Zugriff im Normalfall nicht möglich ist, wurscht ist ob sie md5, md6 oder md7 verschlüsselt ist ... weil sei eh keiner zu sehen bekommt, und wenn er sie zu sehen bekommt ist er bereits auf dem Server und kann machen was er will ... es geht also um überflüssig oder nicht ...

Original geschrieben von BigBen
PS: bin selbst t-online-kunde und über router im netz. ich habe meine ip ausgelesen mit einem script und der zeigt mir immer die gleiche ip an... sprich auf t-online-kunden trifft dies wohl nicht zu...

Mag sein das es nicht bei jedem Einwahlknoten der Fall ist ... bei mir (auch T-Online) und einigen meiner Kunden ist's so ...

[BigBen]

Es geht nicht um sicher oder unsicher ... es geht darum das es bei einer IP die in einer Session gespeichert ist, wo also ein externer Zugriff im Normalfall nicht möglich ist, wurscht ist ob sie md5, md6 oder md7 verschlüsselt ist ... weil sei eh keiner zu sehen bekommt, und wenn er sie zu sehen bekommt ist er bereits auf dem Server und kann machen was er will ... es geht also um überflüssig oder nicht ...

das würde doch heissen, dass ich ohne bedenken passwort, name ect. in einer session registrieren könnte, da letztendlich die sicherheit nur von meinem webspaceanbieter und eventuellen sicherheitslöchern in meinem script (z.b. formulare) abhängt. aber irgendwie möchte ich über diese brücke nicht gehen.


folgendes problem soll möglichst sicher von statten gehen:
- user logged sich ein
- daten werden mit db abgeglichen
- user_id und user_level werden in der session registriert, damit auf anderen seiten darauf zugegriffen werden kann

nach deiner aussage könnte ich einfach session_register(user_id) machen und dann auf alle in der session vorkommenen seiten zugriffen.

was ist eigentlich mit der cockiegeschichte da? hab meinen lokalenapache und php so eingestellt, dass die sessions im tmp-ordner abgespeichert werden. speichert php jetzt automatisch irgendwelche werte, die ich registriere, im cockie des benutzers auf der platte oder ist in dem cockie einfach nur ein verweis auf die session auf meinem server zu finden? wenn dem so ist, könnte man dann mit der information aus dem cockie ohne mein script an die inhalte der sessiondatei kommen?

[mrhappiness]

was spricht denn dagegen, einfach gar nix mit der session selbst zu machen und auch kein userlevel oder name dadrin zu speichern, sondern in der tabelle in der all deine benutzer drinstehen einfach ne neue spalte zu machen und bei eingeollgten usern da die session-id reinzuschreiben?

die ganze sache mit ip speichern, browser speichern, schuhgröße speichern ist suboptimal, weil ich da einige benutzer ausschließe (studenten in der uni, firmen und alles andere was über proxy geht; aol-user definitiv (schau mal hier im forum, da gibt's schon den ein oder anderen thread); was machst du eigentlich mit leuten, die den browser-identifikationsstring nicht mitsenden? )

mit meinem vorschlag kannst du denke ich alles machen und hast keinerlei daten in der session gespeichert, sondern alles bei dir in der datenbank (auf die ja nur du zugriff hast)

der einzige weg, jetzt in die session eines anderen zu kommen wäre imho:

• sein session-cookie klauen, aber dazu müsste er physisch zugriff auf seinen pc haben
• sich von ihm nen link schicken lassen, in dem seine session-id drinsteht, aber dann gehörts ihm auch nicht anders

EDIT:

---

in cokies steht nur, was du da explizit reinschreibst, was php aber macht ist ein session-cookie anzulegen, das (wie der name schon sagt) solange "lebt", wie das browserfenster auf is, also die session läuft und dadrin steht nur die session-id

---

[BigBen]

wo werden denn die variablen abgespeichert, die ich mit session_register() festsetze? ausschließlich auf meinem server oder auch irgendwie in griffnähe für den benutzer?

wenn ich mir z.b. amazon angucke, da geht es um ordentlich kohle und wenn es jemand schafft durch physischen zugriff oder was auch immer an das cookie zu kommen, dann kann der damit ziemlich viel scheiss anstellen... die große frage, wie machen die das denn?

es muss doch eine möglichkeit geben, den user zu identifizieren, egal welchen browser oder bei welchem webdienst die sind.

ich störe mich momentan daran, dass ich einen wert aus dem cookie lese und damit mir schon effektiv zutritt verschaffen kann. die "großen firmen" nutzen doch auch irgendwelche sicheren methoden, so geheim kann das doch nicht sein... oder gibt es nix sichereres und man muss auf die sicherheit der computer des benutzers vertrauen?

[mrhappiness]

solang der böse mensch zugriff auf die cookies hat, hast du ein problem, könntest höchstens mit ssl schaffen

[BigBen]

noch zum thema leute ausgrenzen:

nehmen wir mal an, ein benutzer hat cookies unterdrückt (was sicherlich keine seltenheit ist). das heisst konkret, dass ich die session-id über die url mitgeben muss. jetzt ist der benutzer auch noch nicht sonderlich informiert in sachen sessions ect. nehmen wir mal an, er ist auf einer gesicherten seite, für die man sich normalerweise registrieren und für die es normalerweise sonderrechte seitens des admins eingerichtet worden sein müssten. der benutzer möchte jemandem den link schicken, weil dieser jemand sucht, wo man z.b. auf der seite sein profil einstellen kann. der benutzer kopiert jetzt die komplette url inkl. session-id und schickt diese diesem jemand. dieser jemand muss nur dem link folgen und wird als benutzer erkannt. er kann das profil des benutzers ändern und sonstigen schabernack treiben.

sicherheit = 0, und ich denke sehr wohl, dass es meine aufgabe als webmaster ist, solche uneigennützen aktionen der nutzer meiner seite aufzufangen und gar komplett zu vermeiden.

[Abraxax]

Original geschrieben von BigBen
das heisst konkret, dass ich die session-id über die url mitgeben muss.

das macht der apache/php schon automatisch. da brauchst du dich nicht drum kümmern.

Original geschrieben von BigBen
der benutzer kopiert jetzt die komplette url inkl. session-id und schickt diese diesem jemand. dieser jemand muss nur dem link folgen und wird als benutzer erkannt. er kann das profil des benutzers ändern und sonstigen schabernack treiben.

ich denke schon, dass man einem admin (oder user mit 'sonderrechten') es zutrauen kann, dass er solche links immer ohne SID versendet. oder?

[goth]

Eine Bindung einer Session an einen 2. Identifier (z.B. eine IP) ist ja nur erstmal gar nicht so abwegig ... weil sonst ein Besucher natürlich andere Sessions finden und übernehmen könnte einfach indem er die Session ID's ikrementiert ... allerdings würde den Fall mit einer Spam-Sperre auf Server-Seite unterbinden ... das macht's schon mal schwieriger ...

Allerdings würde ich einfach zusätzlich zur SessionID beim erstellen einer Session einen Cookie beim Besucher setzen der, md5 verschlüsselt , noch mal die SessionID und irgendein Geheimnis enthält. Beim Zugriff kannst Du dann SessionID und Cookie vergleichen ... einfacher (und trotzdem relativ sicher) geht's kaum ...

[Hopka]

Original geschrieben von goth
Allerdings würde ich einfach zusätzlich zur SessionID beim erstellen einer Session einen Cookie beim Besucher setzen der, md5 verschlüsselt , noch mal die SessionID und irgendein Geheimnis enthält. Beim Zugriff kannst Du dann SessionID und Cookie vergleichen ... einfacher (und trotzdem relativ sicher) geht's kaum ...

Und was soll das bringen? Die Session-ID wird standardmäßig eh im Cookie gespeichert. und die dann mit nem geheimnis verbinden, hashen und dazuspeichern ist ne gute Idee, nur wenn der User keine Cookies unterstüzt musste dir was anderes einfallen lassen.

Ich glaube es gibt nicht wirklich einen Weg, Sessions sicher zu machen. Wenn User ohne Cookies die URL weitergeben kann man da nicht viel gegen tun. User-Agent speichern bringt auch nur bedingt was, weil man das a) leicht fälschen kann (siehe z.B. Opera) und b) es doch sehr viele Leute mit IE 6 under Windows XP etc. gibt. Die Ip-Adresse ändert sich bei T-Online alle 24h (spätestens), aber bei AOL wird nach kurzer Zeit (oft unter 3 Minuten) der Proxy, sprich die IP geändert.

Das einzige, was man machen kann, ist es so zu bauen, dass der User z.B. vor dem absenden einer Bestellung (o.Ä.) grundsätzlich nochmal Benutzername und Passwort eingeben muss.

[goth]

So ein Blödsinn ... 97% aller Benutzer im Internet Cookies aktiviert ... warum auch nicht ...

Wenn ich Cookies verwende um Sessions zu speichern, ist das meines erachtens der sicherste Weg, weil die Benutzer schon Ihre Cookie-Dateien austauschen müssten um die Session ID's "ausversehen" weiterzugeben.

Möchte ich jedoch aus irgendeinem Grunde SessionID's via Kommandozeile durchschleifen, so brauche ich, will ich vermeiden das Sessions "übernommen werden" ein Kriterium um den Benutzer/Verwender eindeutig zu identifizieren und das geht letztlich nur via Cookies ... den einzigen Nachteil den ein Benutzer hat der Cookies deaktiviert hat ist, das er sich nicht einloggen kann ... so what ... da kommt ein Hinweis auf die Login-Seite ... Ende ...

[BigBen]

naja, gehe ich mal konkreter auf mein projekt ein. ich möchte keinen shop machen, sondern einen communityseite mit foren ect. d.h. eine übernahme einer session wäre nicht allzu dramatisch, dennoch ärgerlich!

ich bin mich schon etwas am umhören und hab auch schon einen sehr interessanten link gefunden.

wie es aussieht ist die verwendung von cookies definitiv die sichereste variante, muss da goth bei meinen recherchen im internet beipflichten.

demnach könnte man das sicherheitslevel ja dynamisch dem besucher anpassen. z.b. könnte man in dem userprofil diverse loginvarianten anbieten wie das aktivieren der ip-überprüfung (man kann es ja auch anders nennen, man muss die leute ja nicht mit der nase drauf stoßen, dass man u.a. die ip als identifier nutzt).

anwendungsbeispiel:
der user gibt bei der registrierung an, ob er aol-user ist (oder einem anderen dienst mit ständig wechselndem proxy angehört). falls er aol-user ist, wird die ip nicht berücksichtigt und daher auch gleich etwas unsicherer. ansonsten kann man ja die ip zum abgleich mit einer laufenden session bedenkenlos verwenden. user_agent kann man ja generell verwenden. da auch eine "falschinformation" (z.b. kann man sich mit opera ja als ie-user ausgeben) den kreis der authentifizierten user für die momentane session einschränkt.

d.h. generell muss man auf cookies setzen. ich habe gelesen, dass amazon.de wie hopka beschrieben hat, auch grundsätzlich vor abschicken der bestellung mail und pw verlangt. ist natürlich ein aspekt den man mit einfließen lassen kann.

[BigBen]

so what ... da kommt ein Hinweis auf die Login-Seite ... Ende ...

ich glaube diese einstellung steckt mich an. schließlich mache ich die regeln für meine hp und die aktivierung von cookies ist meines erachtens auch nicht zu viel verlangt. wenn der user das nicht möchte, pech, registriert er sich halt nicht und kann die funktionen meiner page nicht nutzen. man muss einen mittelweg zwischen komfort und sicherheit finden. wenn ich dann noch eine weiche programmieren muss, die auf der einen seite zur unsicheren methode führt, zudem komplizierter wird und im gesamten dann im kampf für die sicherheit zur unsicherheit führt, spezialisiere ich mich doch lieber auf eine methode. wie heisst es so schön? die kette ist nur so stark wie sein schwächstes glied. und wenn jeder depp cookies deaktivieren kann, um sich dann einfacher durch meine "unsichere" nicht-cookie variante hacken zu können, lass ich das doch dann lieber weg. weil was bringen dann alle sicheren cookie-zugänge?