So, I'm thinking a plausible session id could be made by hashing their identification (to make it useful to the rightful owner only) with a private key (to make it hard to get and guess). I think the identification could be their IP, user agent, and maybe one or two more constant headers. The private key, of course, could be anything unguessable and kept secure.
This leads me to one more question - would it be better to pass this by PUTing it in the URL or generating it at the start of each page. Passing is pretty simple, but I think generating it has the added benefit of the end user being unable to forge it because it never leaves the server or comes from the client. Does this seem reasonable and worthwhile? (I have a habit of overcomplicating things like this :-))
Thanks again,
Matt
Chris Shiflett wrote:
--- "Matthew A. Blasinski" <[EMAIL PROTECTED]> wrote:
My question - what is the best way to "know" the session id between pages? Posting it in the URL and using $_GET["PHPSESSID"] is one solution, but this seems like a hassle and is also open to attack if someone could "guess" a valid session ID.
As a side note, you should probably use a word like "put" to describe placing data in the URL like that, because "post" refers to a different method altogether. :-)
As for session IDs, there are basically three ways you can have the client send that to you:
1. In a Cookie header 2. In the URL 3. In the content section (POST)
These are all quite open to attack, especially over non-SSL connections (which is the more popular case). In your case, cookies are probably not an option if you are dealing with multiple domains. At the very least, they can only help to track a session on one domain, and you'll have to develop a way to transfer the session across domains anyway. POST is sort of a hassle, because you have to make sure every request from your users is a POST. So, sending data in the URL is probably your best choice.
Try to focus on two tasks as you try to secure this data transfer:
1. Try to make the session ID hard to get and hard to guess. 2. Try to make a stolen session ID useless to anyone but the rightful owner.
Too often, developers try to focus on (and depend on) task 1. While trying to keep session IDs secret is good, task 2 is at least equally as important.
How do you achieve this? Consider an HTTP request from your legitimate user:
GET /blah.php?session_id=1234 HTTP/1.1 Host: example.org User-Agent: Mozilla (Gecko) Linux 2.4.1.2.3.4
There are usually many more headers, but this example will suffice. Now, depending on specific HTTP headers is never a good plan (you might notice people warning against depending on the Referer header), but this is only if you do this for every user. The headers that the *same* user sends are going to be much more consistent. In the above example, you can be pretty certain that, regardless of HTTP proxies or anything else, the user is going to send the same User-Agent header in each request. So, why not store this in the session (on the server), and check to make sure it matches every time? This approach shouldn't adversely affect your users, but it should complicate impersonation.
And that is how you play the game of security - try to make things easy for the good guys and hard for the bad guys. By adding this simple User-Agent check, a bad guy can't just use a stolen session ID to impersonate someone. The bad guy has to also send the same User-Agent header. Can this be done? Sure, and it's not too hard, but it is something, and everything helps.
Hopefully this can get your creative juices flowing.
Chris
===== Become a better Web developer with the HTTP Developer's Handbook http://httphandbook.org/
-- Matt Blasinski (mbv) Internet Infrastructure Applications Technology Division of Information Technology 3121 Computer Science and Statistics 1210 West Dayton Street Madison WI 53706 Work (608) 262-2286 Cell (608) 206-4098
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
