
- You are not logged in. | Login
February 19, 2007 8:00 am
- admin
- Administrator


Discuss article: "True about Sessions"
You can leave your comments here
Discussed article: "True about Sessions"
March 29, 2007 9:23 am
- IBdaMac
- Member


Re: Discuss article: "True about Sessions"
It would be very strange not to mention IP-validation...
Last edited by IBdaMac (March 29, 2007 9:23 am)
March 29, 2007 9:32 am
- sam43inwood
- Member


Re: Discuss article: "True about Sessions"
You can also use client’s IP-address along with X-Forwarded-For header which is added by proxy servers to HTTP- query as ‘finger prints’.
This information can be forged by a hacker as well but unlike User-Agent and Accept it doesn’t depend on browser.
March 29, 2007 9:55 am
- n00bphp
- Member


Re: Discuss article: "True about Sessions"
This looks like paranoia… How much possible PHPSESSID values can exist? Lots of them… And I don’t know any other way to find it out except for selection method (by the condition that viewing folder /tmp. is impossible). Selection takes a lot of time. Session’s lifetime is much shorter. I don’t think ‘finger prints’ are necessary.
At this really dangerous method of impersonation which involves hostler’s faults (and there are LOTS of such hostlers; they are even more common than the others) isn’t discussed in this article. All the users’ sessions are saved into the /tmp folder on the most hostings. This folder is COMMON for all of them. I.e. if you have a hosting on this server and find other site that is hosted there and some freely distributed script (forum, CMS) on it, you will be able to get admin’s rights. You are simply to register the session containing authorization’s identifier and then place its ID into a GET-query from the other site.
You can be protected from it saving sessions in the base or in your personal /tmp folder.
March 29, 2007 10:15 am
- PilgrimFarAway
- Member


Re: Discuss article: "True about Sessions"
No one will get an idea to still sessions from sites like John Smith and for site of on-line auction on some exchange you are to use HTTPS. For intermediate level it’s quite possible to get by with standard SESSIONID and REMOTE_ADDR.
March 29, 2007 10:33 am
- steven9x
- Member


Re: Discuss article: "True about Sessions"
IBdaMac, the author of the article explains why he doesn’t include IP-address into validation: “different users can use the same IP-addresses”.
PilgrimFarAway, I completely agree with your first sentence. As to the second one, it causes some doubts…
March 29, 2007 1:26 pm
- yendii
- Member


Re: Discuss article: "True about Sessions"
n00bphp
And I don’t know any other way to find it out except for selection method
You are to enter forum/target guest book and leave message with image. Image (which is masked script in fact) shows up another picture, leads log and presumably accomplishes actions for which sake session intercept has been started. Any user is going to give your script his session within referrer when viewing topic. To evade being present in the net for days you are to code it for accomplishing necessary action by obtaining session. For example, ExBB gives password’s md5 in cookies if there is a query with right session. And then you enter this cookie and at any moment access is yours even if the session is over. I.e. your script gets referrer, gives image, outgoing connect, head, gets cookie and records into log. Provoke admin a bit in order not to let him keep silence and you will get his session with password hash. Generally each forum enabling images insertions is vulnerable (except for cases when sessions are realized with cookies only).
March 29, 2007 2:31 pm
- bobbee
- Member


Re: Discuss article: "True about Sessions"
All the modern symmetric cryptography is based on the fact that a hacker doesn’t have any information about the key which he could use (most modern symmetric cryptography algorithms work with 32bytes keys – they are of the same size as sessions’ IDs). As applied to sessions the role of key performs session’s identifier which length is quite enough for secure work during the whole period of session existence.


