[PHP] Login-System in PHP programmieren

[Foickert]

Hey Leute,

ich möchte einen Account-Bereich (Login-System) mit PHP programmieren.
Bisher habe ich das immer so gelöst:

session_start();
if (!session_is_registered('benutzername')) {
session_register('benutzername');
$sessname = session_name();
$sessid = session_id();

Um innerhalb des "geschützten Bereichs" zu bleiben, musste ich an alle Links (URLs) jedoch die Variablen &$sessname=$sessid anhängen, also zB.

https://www.beispiel.de/goto.php?id=fotos&$sessname=$sessid

Lässt sich das ganze auch anders (eleganter) lösen, dass eben nicht mehr diese Variablen an jeden Link angehängt werden müssen?

Wenn ich mir andere Webseiten ansehe, dann finde ich innerhalb des Login-System teilweise ausschließlich Links, die ohne das Anhängen jeglicher Variablen auskommen. Ich denke, da steuert der Browser automatisch die Session..

Wäre dankbar, wenn mir jemand nen guten Vorschlag für nen Login-System machen kann!

PS: Sonderlich sicher muss das System übrigens nicht unbedingt sein!

Bye, Markus

 

[PatrickB]

Probiers doch mal mit Cookies

 

[Foickert]

Ach ne du, wir wissen doch alle was für Probleme Cookies bereiten können!

 

[PatrickB]

Ach ne du, wir wissen doch alle was für Probleme Cookies bereiten können!

hö?

 

[scriper]

Ach ne du, wir wissen doch alle was für Probleme Cookies bereiten können!

tun sie das?

 

[ice-breaker]

Ach ne du, wir wissen doch alle was für Probleme Cookies bereiten können!

neija, komisch, dass dann alle Cookies benutzen. Muss wohl so wie mit dem IE sein

Edit: ich würde mal eher sagen, dass Sessions nur Probleme machen: Session-Hijacking, Session-Lifetime etc

 

[artemissays]

neija, komisch, dass dann alle Cookies benutzen. Muss wohl so wie mit dem IE sein

Edit: ich würde mal eher sagen, dass Sessions nur Probleme machen: Session-Hijacking, Session-Lifetime etc

Wenn ich mich nicht ganz stark irren setzt dein Script auch schon einen Cookie, und zwar nur einen wo die sid drin ist, andernfalls wuerde man bei jeder Seitenaktualisierung `ne neue SessionID bekommen.

Sessions sind nicht das Beste, aber Cookies sind auch nicht das beste, also wenn wir jetzt ueber gespeicherte Passwoerter oder sonstwas reden. Sessions kann man overtaken und Cookies kann man ausem Browser auslesen und dann selbst praeperieren, wobei man das Ganze auch sicherer machen kann durch diverse Sachen, sollte man halt nur beachten. Sessions haben da den Vorteil der maximalen Lebenslaenge, dass sie sozusagen selbst irgendwann zerstoert werden, oder wie in nem anderen Kiddie Thread hier irgendwo "Sobald der Browser geschlossen ist", *hust*, also dann wenn der Browser alle Cookies mit abgelaufener Lebenszeit killt. Wobei ich mich da wiederum frage ob er das beim Starten, also dem Initialisierungsprozess macht oder beim Beenden. Ich denke eher mal beim Starten ...
Musst halt sehen was auch bequemer ist, ich persoenlich hasse es mich bei jedem Besuch in normalen Foren oder so einzuloggen, ausser es ist was wichtiges. Online Banking und automatisches einloggen via Cookies wuerde beispielsweise rocken ...

Solong,
artemis

 

[Samy]

Um innerhalb des "geschützten Bereichs" zu bleiben, musste ich an alle Links (URLs) jedoch die Variablen &$sessname=$sessid anhängen, also zB.

macht doch eigntlich apache bzw php mit dem session_start() ?!?.
es gibt ja 2 möglichkeiten mit cookie oder via link das kommt drauf an ob der andere cookies aktzeptiert oder nicht.

 

[Ballamann]

um noch mal auf deine frage zurück zu kommen...
es gibt das superglobale array $__SESSION['Variable']!
Das funzt wie Post beim Formular...

 

[LasMiranda]

...es gibt das superglobale array $__SESSION['Variable']!...

$_SESSION

 

[Ballamann]

ja sry, da bin ich wohl einmal zu oft auf die taste gekommen... auf jeden fall kannste das benutzen und musst dich nihc mit noch mehr cookies rumschlagen...

 

[ice-breaker]

Wenn ich mich nicht ganz stark irren setzt dein Script auch schon einen Cookie, und zwar nur einen wo die sid drin ist, andernfalls wuerde man bei jeder Seitenaktualisierung `ne neue SessionID bekommen.

Ich glaube nicht, dass du eines meiner Scripte kennst.

Sessions kann man overtaken und Cookies kann man ausem Browser auslesen und dann selbst praeperieren, wobei man das Ganze auch sicherer machen kann durch diverse Sachen, sollte man halt nur beachten.

cookies kann man manuell setzen und auch manipulieren ja, aber nach dem Motto "Never trust the input" ist mir das relativ wayne, da man eh die daten validieren muss.
und falls du darauf anspielst mit javascript cookies auslesen zu können, dann gibt es auch die möglichkeit das cookies als "httponly" zu deklarieren und dann kann javascript das nicht mal sehen

Sessions haben da den Vorteil der maximalen Lebenslaenge, dass sie sozusagen selbst irgendwann zerstoert werden, oder wie in nem anderen Kiddie Thread hier irgendwo "Sobald der Browser geschlossen ist", *hust*, also dann wenn der Browser alle Cookies mit abgelaufener Lebenszeit killt. Wobei ich mich da wiederum frage ob er das beim Starten, also dem Initialisierungsprozess macht oder beim Beenden. Ich denke eher mal beim Starten ...

öhm *hust* cookies besitzen ebenfalls eine lifetime, nur mal so zur info.

Musst halt sehen was auch bequemer ist, ich persoenlich hasse es mich bei jedem Besuch in normalen Foren oder so einzuloggen, ausser es ist was wichtiges. Online Banking und automatisches einloggen via Cookies wuerde beispielsweise rocken ...

wie du selbst fest stellst, haben cookies vor allem positive aspekte, wo man sie nun einsetzt und auch einsetzen darf, ist ein anderes thema

 

[artemissays]

Ich glaube nicht, dass du eines meiner Scripte kennst.

Ja man kann auch ohne Arbeiten, man kann sich halt auch seinen eigenen SessionHandler bauen ... man kann auch .... und ...

cookies kann man manuell setzen und auch manipulieren ja, aber nach dem Motto "Never trust the input" ist mir das relativ wayne, da man eh die daten validieren muss.

Klar musste das eh alles validieren. Man kann sich auf den einfachsten Wegen relativ gut gegen gefakte Cookies schuetzen, beispielsweise einfach md5(ip.passwordhash) in den Cookie reinwerfen, und halt auch immer mit der IP validieren, so kann man wenigstens nicht den Cookie mit einer andern IP benutzen, ausser man kennt das Passwort (Salt, wenn vorhanden, je nach eingesetzter Technik) etc, dann kann man das natuerlich neu bauen aber dann kann man auch die normale Einlog-Routine benutzen. Das war jetzt alles nur ein Beispiel aber so vonner Theorie ...

und falls du darauf anspielst mit javascript cookies auslesen zu können, dann gibt es auch die möglichkeit das cookies als "httponly" zu deklarieren und dann kann javascript das nicht mal sehen

Wenn du jetzt wiederum von Cross Site Scripting Attacken sprichst sollten wir jetzt mal davon ausgehen dass die Anwendung einfach mal in diesem Punkto abgesichert ist, ansonsten siehe meinen Text weiter oben womit dass einen dann auch nicht mehr kratzt.

öhm *hust* cookies besitzen ebenfalls eine lifetime, nur mal so zur info.

Ne, die leben ewig, *hust*, kommt halt aufs definierte Expiredate an ...

wie du selbst fest stellst, haben cookies vor allem positive aspekte, wo man sie nun einsetzt und auch einsetzen darf, ist ein anderes thema

Ja es ist ein anderes Thema, aber im Grunde kann Cookies, wenn man sie denn dann auch mit etwas Paranoia einsetzt bei eigentlich fast allen Sachen einsetzen.

Gruesse,
artemis

 

[Johnson]

Wenn du jetzt wiederum von Cross Site Scripting Attacken sprichst sollten wir jetzt mal davon ausgehen dass die Anwendung einfach mal in diesem Punkto abgesichert ist, ansonsten siehe meinen Text weiter oben womit dass einen dann auch nicht mehr kratzt.

Von was hast du denn geredet ? Es bleibt doch eigentl. nur XSS als mehr oder weniger sinnvolle Möglichkeit Cookies "einfach so" auszulesen ...

Gruß

 

[ice-breaker]

Ne, die leben ewig, *hust*, kommt halt aufs definierte Expiredate an ...

man kann sie aber festlegen, von daher gilt mein argument ob man sie nun aus anderen gründen weglässt ist doch egal

 

[ZeroCCC]

Klar musste das eh alles validieren. Man kann sich auf den einfachsten Wegen relativ gut gegen gefakte Cookies schuetzen, beispielsweise einfach md5(ip.passwordhash) in den Cookie reinwerfen, und halt auch immer mit der IP validieren, so kann man wenigstens nicht den Cookie mit einer andern IP benutzen[...]

und was ist wenn der angreifer die selbe ip hat? oder was machst du wenn der nutzer ne ständig ändernde ip hat (bei jedem request)? nach ip validieren ist nen schuss in den offen...

 

[artemissays]

man kann sie aber festlegen, von daher gilt mein argument ob man sie nun aus anderen gründen weglässt ist doch egal

Ich hatte dir ja auch nicht widersprochen

und was ist wenn der angreifer die selbe ip hat? oder was machst du wenn der nutzer ne ständig ändernde ip hat (bei jedem request)? nach ip validieren ist nen schuss in den offen...

Naja wenn der Nutzer ne staendig aendernde Ip hat dann brauchste dir ueber Sicherheit eh keine Gedanken machen, weil wer seinen Traffic gerne ueber Proxies leitet ...

Ich frag mich dann auch mal wie du das machst auf sicherem Wege. Also validieren ueber IP geht ja dann schonmal nicht. Cookies sind ja dann wahrscheinlich auch boese, normale Sessions kann man ja auch nicht benutzen weil die entweder in nem Cookie von PHP gespeichert werden oder halt an die URL gehaengt werden, da muss man dann aber auch wieder an SessionFixation denken, also man kann das Spielchen gerne weiter drehen ...

Man muss mal alles im Context sehen, und nicht davon sprechen: Was waere wenn der Angreifer physikalischen Zugriff auf den Rechner hat. Zu diesem Context gehoert unter anderem auch, wie das Zielpublikum aussieht. Es gibt Unterschiede zwischen einem Tierfreunde Community und einen Coder Forum.

 

[ice-breaker]

öhm, welches prob habt ihr denn mit validierung des cookies per IP?
ein cookie macht in dem falle ganz primitiv ja nicht viel mehr als sich bei jedem seitenaufruf neu einzuloggen, bzw. eben die daten des cookies gegen die datenbank zu überprüfen, da brauch keine ip-validierung.
man sollte dann im cookies aber auch nen andres pw (oder mit nem salt) speichern, als man normal auf der seite verwendet

 

[bartman]

meiner Meinung nach ist eine Usersession nur solange sicher, bis jemand anders an die Sessionid kommt. Username/Password im Cookie speichern und jedes mal einloggen etc laeuft aufs selbe hinaus, reduziert bleibt nur noch die SID, die es zu sichern gilt.

Damit die sicher zum Klienten kommt, bietet sich TLS an.

Um die Sicherheit zusaetzlich zu erhoehen, sollte die SID nicht leicht erratbar sein - Zufallsfaktoren einbauen, bei jeder Uebertragung neue SID generieren.

Alles andere, Browser ueberpruefen, IP, ... sind nur Spielerei, die man leicht faken kann, wenn man es drauf anlegt - TLS knackt man jedoch nicht so leicht (wenn es richtig verwendet wird).

 

[artemissays]

Alles andere, Browser ueberpruefen, IP, ... sind nur Spielerei, die man leicht faken kann, wenn man es drauf anlegt - TLS knackt man jedoch nicht so leicht (wenn es richtig verwendet wird).

Ich frage mich gerade wie du eine IP faken willst , ausser du benutzt den gleichen Anschluss oder hackst das WLAN des Betreffenden

TLS kann man auch ueber die MitM-Methode knacken, kommt wiederum auf die Schluessellaenge an wie lange das Spielchen dauert.