PHP sessie overnemen voorkomen

[Verwijderd]

Hoi allemaal

PHP slaat zoals jullie weten de standaard sessies ($_SESSION) op in een cookie of in de url.
Het probleem is als de sessie in een url staat.
Hoe verkom ik dat dat men door de url (met sessie) door te sturen naar een collega (zelfde ip, zelfde browser), dat deze collega ingelogd word.

Cookies is uitgesloten omdat deze niet mogen worden gebruikt.

alvast bedankt

[Eskimootje]

Referer checken als die wel bestaat bij het inloggen maar daarna een keer verdwijnt bij het browsen heb je een verkeerde persoon te pakken. Soms krijg je verkeerde referer links tegen, daarom moet je controleren dat deze hetzelfde gedrag blijft vertonen.

[Verwijderd]

Maar geeft een browser wel altijd de referer meen.
Ik heb ooit gelezen dat het niet zo was.

[igmar]

Verwijderd schreef op donderdag 03 maart 2005 @ 15:38:
PHP slaat zoals jullie weten de standaard sessies ($_SESSION) op in een cookie of in de url.
Het probleem is als de sessie in een url staat.
Hoe verkom ik dat dat men door de url (met sessie) door te sturen naar een collega (zelfde ip, zelfde browser), dat deze collega ingelogd word.

Niet. De sessie is juist de bescherming hier tegen. Het is gewoonweg een sleutel, en een ieder die de sleutel heeft kan binnenkomen.

[Erkens]

Verwijderd schreef op donderdag 03 maart 2005 @ 16:23:
Maar geeft een browser wel altijd de referer meen.
Ik heb ooit gelezen dat het niet zo was.

klopt, sommige mensen schakelen dat uit ivm privacy oid
ik denk dat hij vrij lastig gaat worden.
Want je doelt er zeker op dat een URL gekopieerd wordt en naar een collega gestuurd?
zeker als het ook nog eens dezelfde browser is (desondanks ook dat checken samen met IP )
Veel proxyservers geven vaak ook het originele IP mee, misschien kan je daar wat mee

[momania]

Je moet het zoeken in de url rewriting van je web/app server.

Als je dat niet toelaat, dan heeft het toevoegen van een session id aan de url geen effect

[edit]

Zie http://www.php.net/session

The session module cannot guarantee that the information you store in a session is only viewed by the user who created the session. You need to take additional measures to actively protect the integrity of the session, depending on the value associated with it.

Assess the importance of the data carried by your sessions and deploy additional protections -- this usually comes at a price, reduced convenience for the user. For example, if you want to protect users from simple social engineering tactics, you need to enable session.use_only_cookies. In that case, cookies must be enabled unconditionally on the user side, or sessions will not work.

session.use_only_cookies specifies whether the module will only use cookies to store the session id on the client side. Defaults to 0 (disabled, for backward compatibility). Enabling this setting prevents attacks involved passing session ids in URLs. This setting was added in PHP 4.3.0.

[ Voor 87% gewijzigd door momania op 03-03-2005 16:39 ]

[Dutchmega]

Sessieid in cookies zijn ook niet veilig.. Je kan ook cookies hijacken..

[momania]

Dutchmega schreef op donderdag 03 maart 2005 @ 16:49:
Sessieid in cookies zijn ook niet veilig.. Je kan ook cookies hijacken..

Uhu, maar probleem van de url rewriting is dan wel opgelost.
Als je je ook nog wil beschermen tegen cookies hijacken, zal je SSL moeten gaan gebruiken.

[Dutchmega]

PHP:

session_regenerate_id();

Op elke pagina? De hijacker heeft dan niet veel tijd om van de session gebruik te maken.

[Erkens]

Dutchmega schreef op donderdag 03 maart 2005 @ 16:57:

PHP:

session_regenerate_id();

Op elke pagina? De hijacker heeft dan niet veel tijd om van de session gebruik te maken.

true, maar op het moment dat die collega dan toch net iets eerder is, dan is de originele user buitengesloten, je moet hier erg voor oppassen!

[Verwijderd]

Misschien denk ik te simpel, maar als je nou gewoon in de sessie het IP-adres opslaat van de bezoeker, dan kun je op elk gewenst moment kijken of het opgeslagen IP overeenkomt met dat van de bezoeker.

[Erkens]

Verwijderd schreef op donderdag 03 maart 2005 @ 17:00:
Misschien denk ik te simpel, maar als je nou gewoon in de sessie het IP-adres opslaat van de bezoeker, dan kun je op elk gewenst moment kijken of het opgeslagen IP overeenkomt met dat van de bezoeker.

ja, je denkt te simpel, wat niet had gehoeven als je gewoon had gelezen

Hoe verkom ik dat dat men door de url (met sessie) door te sturen naar een collega (zelfde ip, zelfde browser), dat deze collega ingelogd word.

[Scott]

Dutchmega schreef op donderdag 03 maart 2005 @ 16:49:
Sessieid in cookies zijn ook niet veilig.. Je kan ook cookies hijacken..

Heb je gelijk in, alleen dat is nu niet interessant, want het gaat volgens de topicstarter om het kopieëren van de URL en die aan een collega geven, dat is een "fout" van degene die de link kopieërt. Hij kan er niks aan doen dat zijn cookies worden gehijacked...

Of zit ik fout ?

[ Voor 4% gewijzigd door Scott op 03-03-2005 17:04 ]

[eborn]

- Never mind -

[ Voor 95% gewijzigd door eborn op 03-03-2005 17:06 ]

[Eskimootje]

Erkens schreef op donderdag 03 maart 2005 @ 16:27:
[...]

klopt, sommige mensen schakelen dat uit ivm privacy oid
ik denk dat hij vrij lastig gaat worden.
Want je doelt er zeker op dat een URL gekopieerd wordt en naar een collega gestuurd?
zeker als het ook nog eens dezelfde browser is (desondanks ook dat checken samen met IP )
Veel proxyservers geven vaak ook het originele IP mee, misschien kan je daar wat mee

Het zal vaak genoeg wel goed gaan om het in ieder geval als extra beveiliging te gebruiken, dus ook alleen gebruiken als je van de sessie weet dat het wel verstuurd word en daarna plotseling niet of via een verkeerde referer aankomt. Als er bijvoorbeeld geen referer mee word gestuurd en dan plots wel is het ook vreemd gedrag.

[Madcat]

waarom sla je de session id dan ook op in de url, daar zijn cookies handig voor.
in het koekje een hash van het password opslaan eventueel gecombineerd met iets anders zoals session id en tijd ofzo. en eventueel het koekje en sessie limiteren voor een dag ofzo.
zodat het koekje niet gejat kan worden.

session id in het URL is gewoon niet slim en je zou beter voor een andere aanpak kunnen kiezen..

just my 2 cent.

[LuCarD]

- Client Side SSL certificates, dat is volgens mij de beste optie. Alleen op grote schaal moeilijk toepasbaar.
- ActiveX/Java component die een niet stateless verbinding houd met de server?

[momania]

een_madcat schreef op donderdag 03 maart 2005 @ 17:11:
session id in het URL is gewoon niet slim en je zou beter voor een andere aanpak kunnen kiezen..

Session id in de url is gewoon standaard zodra een client cookies weigert

[Verwijderd]

momania schreef op donderdag 03 maart 2005 @ 17:24:
[...]

Session id in de url is gewoon standaard zodra een client cookies weigert

De opdrachtgever heeft nogal wat klanten die cookies blokkeren.
Vandaar
Ik kan er dus vrij weinig tegen doen.
Behalve in een frameset laden zodat de sessie url in de frame staat.