PHP Sessions - Seite 2

hurt · 11.11.2004, 22:52

da wird es zB auch nicht anders gemacht

http://www.tutorials.de/tutorials9684.html

ich benutze sessions das erste mal und weiß nicht wie sicher das ist, aber wenn ichs schon in vielen tutorials gelesen hab dass es so geht?

ruprecht69 · 12.11.2004, 01:02

Zitat:

Original geschrieben von Potassium
ajo und ne eigentschaft von sessions ist, dass wenn du den browser zu machst, die session ungültig wird.

das glaube ich nicht tim ...

kommt immer auf die Einstellung (in dem Fall php.ini) an. Sessions können Jahre aktiv sein (schon mal 'remember me' irgendwo angeklickt und nach dem nächsten reboot warst du immer noch eingeloggt?)).

jak · 12.11.2004, 01:16

Die remember me Sachen gehen über Cookies.

Jak

Potassium · 12.11.2004, 08:16

Zitat:

Original geschrieben von ruprecht69
das glaube ich nicht tim ...

kommt immer auf die Einstellung (in dem Fall php.ini) an. Sessions können Jahre aktiv sein (schon mal 'remember me' irgendwo angeklickt und nach dem nächsten reboot warst du immer noch eingeloggt?)).

ad1: siehe jak
ad2: anklicken tu ich gar nix. weil fürn apache gibts unter windows afaik kein grapisches konfig-menu.

cg32 · 12.11.2004, 12:11

Die Sessions sind aber serverseitig noch aktiv (wie soll der Server auch mitkriegen, dass du deinen Browser geschlossen hast).

Deswegen ist auch Session Hijacking etc. möglich.

Normale PHP Sessions sind sehr unsicher.

Je nachdem wie sicher man es haben möchte sollten folgende Dinge selbst implementiert werden:

- Timeout der Session (zB mittels Session Storing in DB)
- Gegenstelle prüfen (zB mittels IP o. Agent oä. - kann probleme geben zB bei AOL Proxy, der über mehrere IPs geht - besser mittels eines "Fingerprints" der zB aus Timestamp, Agent, Referrer etc. besteht und auf jeder Seite neu generiert wird)
- Transaction IDs
- IMMER bestimmte Variablen prüfen, auf jeder Seite - zB Password als MD5 Hash mit der DB vergleichen. Sonst reicht mir die SessionID um die Session zu hijacken.

oä.

hurt · 18.11.2004, 09:16

"- IMMER bestimmte Variablen prüfen, auf jeder Seite - zB Password als MD5 Hash mit der DB vergleichen. Sonst reicht mir die SessionID um die Session zu hijacken."

meinst du ich soll das password als md5() als session-variable und in der datenbank speichern?

oder soll ich einfach mit einem php script das passwort immer zur naechsten seite weitergeben mit $_GET, dort mit dem datenbankeintrag vergleichen und wenns stimmt erst mit der session weitermachen?

Pulse-Seeker · 18.11.2004, 10:06

wenn dann gibs mit $_POST weiter da bei $_GET die daten an die url angehängt werden, bei $_POST nicht!

cg32 · 18.11.2004, 13:21

Zitat:

Original geschrieben von hurt
"
meinst du ich soll das password als md5() als session-variable und in der datenbank speichern?

Genau - in der DB steht der MD5 Hash des Passworts und mittels Sessionvariable wird er ebenfalls übergeben.
Diese beiden Werte bei jedem Aufruf gegenchecken.

Potassium · 18.11.2004, 15:18

Zitat:

Original geschrieben von hurt
"

meinst du ich soll das password als md5() als session-variable und in der datenbank speichern?

genau das

FordPrefect · 18.11.2004, 18:30

Zitat:

Original geschrieben von Pulse-Seeker
wenn dann gibs mit $_POST weiter da bei $_GET die daten an die url angehängt werden, bei $_POST nicht!

Gibt es eine Möglichkeit Variablen über $_POST mittels eines Links weiterzugeben?
mfg
Peter

11.11.2004, 22:52	#11
hurt Veteran Registriert seit: 02.12.2000 Alter: 44 Beiträge: 298	da wird es zB auch nicht anders gemacht http://www.tutorials.de/tutorials9684.html ich benutze sessions das erste mal und weiß nicht wie sicher das ist, aber wenn ichs schon in vielen tutorials gelesen hab dass es so geht? ____________________________________ ...::: www.nineinchnails.at - Perfect Little Dream :::...

12.11.2004, 01:16	#13
jak Inventar Registriert seit: 13.06.2001 Beiträge: 1.830	Die remember me Sachen gehen über Cookies. Jak ____________________________________ Join the DNRC \| Godwin\'s Law (thx@stona) Documentation is like sex: If it\'s good, it\'s very, very good. If it\'s bad, it\'s better than nothing. \"In theory, theory and practice are the same. In practice, they are not\" (Lawrence Berra)

18.11.2004, 09:16	#16
hurt Veteran Registriert seit: 02.12.2000 Alter: 44 Beiträge: 298	"- IMMER bestimmte Variablen prüfen, auf jeder Seite - zB Password als MD5 Hash mit der DB vergleichen. Sonst reicht mir die SessionID um die Session zu hijacken." meinst du ich soll das password als md5() als session-variable und in der datenbank speichern? oder soll ich einfach mit einem php script das passwort immer zur naechsten seite weitergeben mit $_GET, dort mit dem datenbankeintrag vergleichen und wenns stimmt erst mit der session weitermachen? ____________________________________ ...::: www.nineinchnails.at - Perfect Little Dream :::...

18.11.2004, 10:06	#17
Pulse-Seeker Inventar Registriert seit: 17.11.2002 Alter: 47 Beiträge: 2.027 Mein Computer	wenn dann gibs mit $_POST weiter da bei $_GET die daten an die url angehängt werden, bei $_POST nicht! ____________________________________ Amiga is back!!! amigaemuboard.net - Amiga still alive !!!

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

12.11.2004, 12:11	#15
cg32 Jr. Member Registriert seit: 10.06.2000 Beiträge: 84	Die Sessions sind aber serverseitig noch aktiv (wie soll der Server auch mitkriegen, dass du deinen Browser geschlossen hast). Deswegen ist auch Session Hijacking etc. möglich. Normale PHP Sessions sind sehr unsicher. Je nachdem wie sicher man es haben möchte sollten folgende Dinge selbst implementiert werden: - Timeout der Session (zB mittels Session Storing in DB) - Gegenstelle prüfen (zB mittels IP o. Agent oä. - kann probleme geben zB bei AOL Proxy, der über mehrere IPs geht - besser mittels eines "Fingerprints" der zB aus Timestamp, Agent, Referrer etc. besteht und auf jeder Seite neu generiert wird) - Transaction IDs - IMMER bestimmte Variablen prüfen, auf jeder Seite - zB Password als MD5 Hash mit der DB vergleichen. Sonst reicht mir die SessionID um die Session zu hijacken. oä.

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)