Waraxe IT Security Portal

Heintz · Valuable expert

sessions part: http://phpsec.org/projects/guide/4.html

i think their advice about sessions is not talked fully and may lead to
pitfalls (many people dont bother to think self). sessions are a difficult subject since there are many attack vectors. session ids must be real unique (random).. since with "online users" lists it may be possible to get a ammount of time which sessions ids might have been generated (refer to phpbb 2.0.15 changelog, for a bug same as this - which by fate was discovered by me) and secondly, in my opinion securing the session tokens from getting stolen should be priority.
thirdly a pitfall that i almost fell reading phpsec.org was that users should not
be able to create sessions for themselves. i mean - if there isnt a valid session - create it within script, dont create sessions with user submitted token. i made the test with their script locally. when i
made the custom sessions handler with mysql like theirs (http://phpsec.org/projects/guide/5.html).
i couldnt help noticing that when i go to page.php?PHPSESSID=customsession then i get a entry like that in DB.
but now when i say to admin that: "hey login and check PM i send ya" at
www.example.com?PHPSESSID=mysess , when admin has logged in then all i have to do is visit page using same session id myself.

[edit]
and setting a cookie to other domains are allowed for firefox, so this action
could be done much less obious
[/edit]

just read, think and practice everything before you put something to use.

Smile

LINUX · Moderator

very interesting Cool

Heintz · Valuable expert

yes, i was missing a thing there that this "cross site session hijacking"
is only possible when upon authendication a new session id is *not* generated.

heres the case:
victim visits a malicious site, which sets a cookie to him. cookie contains a session id that has been generated before by attacker. (attacker can generate a valid session id by visiting the site self for example).
when the user has the cookie then by visiting the original site he hijacks
attackers session without self knowing it. when victim is in attacers session
then he logins - and when login doesnt generate a new session id then attacker can use the same session id. now when phpbb developers would have listened phpsec.org and used only User-Agent as "fixer" then they would have been vulnearable to this (only with difference that attacker has to know what browser and maybe computer admin is using). Cool

[edit]
i sent a mail to phpsec.org about it
[/edit]

more new info:
the phpsec.org-s authors book covers this topic perfectly, but why is it left out from from html paper? Sad

edit3:

my bad i didnt read tutorial carefully
this topic is covered, but still it is an interesting type of vulnearability