Re: [PHP] Best way to transfer session IDs
Chris Shiflett wrote: --- "Matthew A. Blasinski" <[EMAIL PROTECTED]> wrote: 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. A few comments... This session ID doesn't have to be generated from any user data. It can be a completely random and unique string that you generate for any user who arrives at your site without an active session. Even though it is probably very difficult to reverse or guess a valid ID from your method above, the extra risk isn't necessary. Also, the IP address isn't a very good piece of data to use, because it is not necessarily consistent. So, while it might make things harder for the bad guys (to spoof the good guy's IP), it could also can make things hard for the good guys (they are AOL users, lose their modem connection, etc.). Thanks for everyone's responses. I was thinking the IP would be usable for tracking users, and a lot of people have pointed out that's not the case. So, I'll probably go with passing it in the URL. Thanks again, -- 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
Re: [PHP] Best way to transfer session IDs
--- "Matthew A. Blasinski" <[EMAIL PROTECTED]> wrote: > 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. A few comments... This session ID doesn't have to be generated from any user data. It can be a completely random and unique string that you generate for any user who arrives at your site without an active session. Even though it is probably very difficult to reverse or guess a valid ID from your method above, the extra risk isn't necessary. Also, the IP address isn't a very good piece of data to use, because it is not necessarily consistent. So, while it might make things harder for the bad guys (to spoof the good guy's IP), it could also can make things hard for the good guys (they are AOL users, lose their modem connection, etc.). So doesn't this contradict everything I mentioned previously? No, the data I mentioned keeping (User-Agent is my favorite example) is data that you can keep on the server within the session, such as: $_SESSION['user_agent'] = $_SERVER['USER_AGENT']; That would be the first tme, of course. Since session variables aren't sent to/from the client (unless you output one, of course), they are safer than things transmitted across the public Internet. So, the session ID doesn't have to have any data within it that makes it useless to anyone but the rightful owner - the session that it is associated with on the server can instead. This might make things simpler for you. > 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. You lost me with that bit. While it is good that you want to eliminate any unnecessary transmission of data across the Internet, the session ID is the one thing the client *must* send you in order for you to maintain session. It is how you identify who it is. Maybe you can rephrase what you're asking? Hope that helps. Chris = Become a better Web developer with the HTTP Developer's Handbook http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best way to transfer session IDs
* Thus wrote Matthew A. Blasinski ([EMAIL PROTECTED]): > Thanks for the response Chris, that's just the type of thing I was > looking for! > > 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. Using the IP of the user may force things to break on the client easily. There are a number of users who are behind proxies that change per request (ie aol users.) thus their session would become obsolete on their next request. Another issue would be inactivity for the session. You could also keep keep track of an internal last_requested variable that would expire after a certain amount of time. > > 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 :-)) I suppose it would depend on how secure you want your session to be from SID hijaking. A generation of key hash per request would be perhaps a little over kill if you are just keeping track of a last page the person was on. Handling sensitive information, however is a different story (ie cc numbers). Curt -- "I used to think I was indecisive, but now I'm not so sure." -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best way to transfer session IDs
Matthew A. Blasinski wrote: I'm trying to track session data and merge several related services through a common server-side session (using Apache). One condition is that it won't use cookies to store the user data OR the session ID. Another is that the services we're merging use different languages, including PHP and Perl (Apache::Session module) so whatever I use needs to be supported by both of these. 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. Or, would it better to avoid transferring session ids altogether and generate unique "names" on each page? What works well for generating the name? I'm thinking something like a hash of their IP plus a private key, but maybe someone knows problems with this or has a better/easier solution. If you don't want to use cookies, then you need to pass a session ID through the URL. That's your only answer. Or use POST forms everywhere to "hide" the session id. I don't understand what you mean by "unique names on each page" but I don't think that's any way to maintain state. -- ---John Holmes... Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/ PHP|Architect: A magazine for PHP Professionals – www.phparch.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best way to transfer session IDs
Thanks for the response Chris, that's just the type of thing I was looking for! 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
Re: [PHP] Best way to transfer session IDs
--- "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/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Best way to transfer session IDs
Hi, I'm trying to track session data and merge several related services through a common server-side session (using Apache). One condition is that it won't use cookies to store the user data OR the session ID. Another is that the services we're merging use different languages, including PHP and Perl (Apache::Session module) so whatever I use needs to be supported by both of these. 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. Or, would it better to avoid transferring session ids altogether and generate unique "names" on each page? What works well for generating the name? I'm thinking something like a hash of their IP plus a private key, but maybe someone knows problems with this or has a better/easier solution. Also, outside of changing session.use_cookies to false and session.save_path to a PHP- and Perl- happy location, are there any other php.ini or Apache settings I should be changing? Any comments or thoughts are greatly appreciated! -- 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
