Gathering of Tweakers

Verwijderd

Verwijderd — Thu, 03 Mar 2005 18:22:46 GMT

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.

momania

momania — Thu, 03 Mar 2005 16:24:51 GMT

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

LuCarD

LuCarD — Thu, 03 Mar 2005 16:15:48 GMT

- 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?

Madcat

Madcat — Thu, 03 Mar 2005 16:11:42 GMT

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.

Eskimootje

Eskimootje — Thu, 03 Mar 2005 16:06:08 GMT

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.

eborn

eborn — Thu, 03 Mar 2005 16:05:49 GMT

- Never mind -

Scott

Scott — Thu, 03 Mar 2005 16:03:28 GMT

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 ?

Erkens

Erkens — Thu, 03 Mar 2005 16:01:38 GMT

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.

Verwijderd

Verwijderd — Thu, 03 Mar 2005 16:00:40 GMT

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

Erkens — Thu, 03 Mar 2005 16:00:26 GMT

Dutchmega schreef op donderdag 03 maart 2005 @ 16:57:
PHP:
1
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!

Dutchmega

Dutchmega — Thu, 03 Mar 2005 15:57:18 GMT

PHP:

1	session_regenerate_id();

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

momania

momania — Thu, 03 Mar 2005 15:50:56 GMT

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

Dutchmega — Thu, 03 Mar 2005 15:49:48 GMT

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

momania

momania — Thu, 03 Mar 2005 15:32:36 GMT

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.

Erkens

Erkens — Thu, 03 Mar 2005 15:27:54 GMT

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

igmar

igmar — Thu, 03 Mar 2005 15:25:17 GMT

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.

Verwijderd

Verwijderd — Thu, 03 Mar 2005 15:23:22 GMT

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

Eskimootje

Eskimootje — Thu, 03 Mar 2005 14:40:47 GMT

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

Verwijderd — Thu, 03 Mar 2005 14:38:27 GMT

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