More PHP session fun
Moderator: General Moderators
More PHP session fun
I've spent hours of quality time with Google regarding securing PHP sessions, etc. and still haven't found a feasible solution for my needs. As such, I figured I'd ask here:
Basically, what is a good method for securing PHP sessions?
I've listed below 5 method's that I've considered in the past, as well as described why they won't work. Does anybody have any ideas (or use anything) that's not listed below? I'm hoping to generate some conversation about non-conventional methods to secure PHP sessions, etc.
Method 1: store username and password in session variables
Why it won't work: This is obviously not secure at all; if a user were to hijack the sessionid, s/he would have access to all of the session information.
Method 2: create a cookie containing a hash of username and IP address
Why it won't work: For example, let's say 10 people share a proxy server. All 10 would register as having come from the same IP Address. If someone were to temporarily configure their browser through the same proxy, and then hijack the cookie, I would have no way to know. Or, if my server has a reverse proxy, then ALL traffic will have the same IP address. Furthermore, a few ISPs (eg AOL in some places) uses a rotating proxy, so the valid user request could come from one of a few IP addresses....
Method 3: Generate a cookie with a new, unique ID for EVERY page.
Why it won't work: If a user clicks twice really fast, or if I have a page that makes several AJAX calls very quickly (I have many pages like this), then the problem exists that the old, invalid ID gets passed for each AJAX call. The user hasn't received the new ID yet, and the server has already invalidated the old ID (thereby restricting access).
I could set up a "grace period" of, say, 20-ish seconds where the old ID would still be valid during that time. Even if I do this, there are still problems. For example, if someone were to hijack the cookie and call a webpage before the actual user makes another click, the hijacker would be granted the new ID and the validated user would be operating on the old, invalid ID (thereby logging him out).
Method 4: Generate a cookie with a hash of the username, user-agent string, and first two numbers of IP. For example, user "someuser", with user-agent string "some-web-browser", and ip of "aaa.bbb.ccc.ddd" would receive a cookie of value sha1("someuser"."some-web-browser"."aaa.bbb").
Why it won't work: This is, IMHO, the best so far. But the problem is that some poorly-configured proxy servers will modify the user-agent string, so validating with the http-user-agent string could prove troublesome for a select few users. Removing it brings us back to Method #2.
Method 5: force transmission via SSL
Why it won't work: well, okay, this WOULD work fairly well, but there is something to be said about the overhead of encrypting everything. I would like to avoid the use of https at least for conversation's sake (if for nothing else).
Basically, what is a good method for securing PHP sessions?
I've listed below 5 method's that I've considered in the past, as well as described why they won't work. Does anybody have any ideas (or use anything) that's not listed below? I'm hoping to generate some conversation about non-conventional methods to secure PHP sessions, etc.
Method 1: store username and password in session variables
Why it won't work: This is obviously not secure at all; if a user were to hijack the sessionid, s/he would have access to all of the session information.
Method 2: create a cookie containing a hash of username and IP address
Why it won't work: For example, let's say 10 people share a proxy server. All 10 would register as having come from the same IP Address. If someone were to temporarily configure their browser through the same proxy, and then hijack the cookie, I would have no way to know. Or, if my server has a reverse proxy, then ALL traffic will have the same IP address. Furthermore, a few ISPs (eg AOL in some places) uses a rotating proxy, so the valid user request could come from one of a few IP addresses....
Method 3: Generate a cookie with a new, unique ID for EVERY page.
Why it won't work: If a user clicks twice really fast, or if I have a page that makes several AJAX calls very quickly (I have many pages like this), then the problem exists that the old, invalid ID gets passed for each AJAX call. The user hasn't received the new ID yet, and the server has already invalidated the old ID (thereby restricting access).
I could set up a "grace period" of, say, 20-ish seconds where the old ID would still be valid during that time. Even if I do this, there are still problems. For example, if someone were to hijack the cookie and call a webpage before the actual user makes another click, the hijacker would be granted the new ID and the validated user would be operating on the old, invalid ID (thereby logging him out).
Method 4: Generate a cookie with a hash of the username, user-agent string, and first two numbers of IP. For example, user "someuser", with user-agent string "some-web-browser", and ip of "aaa.bbb.ccc.ddd" would receive a cookie of value sha1("someuser"."some-web-browser"."aaa.bbb").
Why it won't work: This is, IMHO, the best so far. But the problem is that some poorly-configured proxy servers will modify the user-agent string, so validating with the http-user-agent string could prove troublesome for a select few users. Removing it brings us back to Method #2.
Method 5: force transmission via SSL
Why it won't work: well, okay, this WOULD work fairly well, but there is something to be said about the overhead of encrypting everything. I would like to avoid the use of https at least for conversation's sake (if for nothing else).
Re: More PHP session fun
Why would you store password to session?rburgens wrote: Method 1: store username and password in session variables
Why it won't work: This is obviously not secure at all; if a user were to hijack the sessionid, s/he would have access to all of the session information.
How would someone have access to all the session information if it is not displayed anywhere?
Re: More PHP session fun
The point of storing the password in the session would be to validate it against the database on every page.
And in retrospect that wasn't phrased too well; they wouldn't have access to the session data per se, but the hijacker could access any page the original user could, potentially displaying confidential information. You are right: if the session data is not displayed anywhere, they could not see it. But having illegitimate access to a website could be just as harmful....
And in retrospect that wasn't phrased too well; they wouldn't have access to the session data per se, but the hijacker could access any page the original user could, potentially displaying confidential information. You are right: if the session data is not displayed anywhere, they could not see it. But having illegitimate access to a website could be just as harmful....
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: More PHP session fun
The user has already authenticated, so, there is zero need for storing passwords or usernames in the session. If you need to store some information about the user, etc, use his real name or nick name, but not the username.rburgens wrote:Method 1: store username and password in session variables
This is basically just a worse revision of Sessions.rburgens wrote:Method 2: create a cookie containing a hash of username and IP address
Why it won't work: For example, let's say 10 people share a proxy server. All 10 would register as having come from the same IP Address. If someone were to temporarily configure their browser through the same proxy, and then hijack the cookie, I would have no way to know. Or, if my server has a reverse proxy, then ALL traffic will have the same IP address. Furthermore, a few ISPs (eg AOL in some places) uses a rotating proxy, so the valid user request could come from one of a few IP addresses....
In other words, you are thinking about regenerating the session identifier. That's quite irrelevant here, because you can build a strong session system whether you regenerate identifiers actively or not.rburgens wrote:Method 3: Generate a cookie with a new, unique ID for EVERY page.
Why it won't work: If a user clicks twice really fast, or if I have a page that makes several AJAX calls very quickly (I have many pages like this), then the problem exists that the old, invalid ID gets passed for each AJAX call. The user hasn't received the new ID yet, and the server has already invalidated the old ID (thereby restricting access).
I could set up a "grace period" of, say, 20-ish seconds where the old ID would still be valid during that time. Even if I do this, there are still problems. For example, if someone were to hijack the cookie and call a webpage before the actual user makes another click, the hijacker would be granted the new ID and the validated user would be operating on the old, invalid ID (thereby logging him out).
Same as the second method.rburgens wrote:Method 4: Generate a cookie with a hash of the username...
HTTPS is not a replacement for sessions. In fact, ultimately you need to use it if you want to stay safe.rburgens wrote:Method 5: force transmission via SSL
Why it won't work: well, okay, this WOULD work fairly well, but there is something to be said about the overhead of encrypting everything. I would like to avoid the use of https at least for conversation's sake (if for nothing else).
Which achieves nothing really. The correct password is placed within the session at the point the actual user logged in and when the session is hijacked, the password still remains there and helps nothing.rburgens wrote:The point of storing the password in the session would be to validate it against the database on every page.
In terms of session hijacking, the intruder is authenticated as the victim, so, she sees what he sees.rburgens wrote:You are right: if the session data is not displayed anywhere, they could not see it.
I'm not really sure what you are trying to do, but I'd like to know what's wrong with the typical session construct that you are trying to avoid?
Re: More PHP session fun
kaisellgren: good points!
The problem with the typical session construct is that anyone monitoring network traffic can easily hijack the user's sessionid cookie (usually PHPSESSID). If they gain access to the PHPSESSID cookie, then they can use the cookie to have illegitimate, but valid, access to my site.
What I am trying to do is find a system/method/etc. that can verify that the user is who s/he says s/he is, and is not really a hacker who obtained a hijacked sessionid. I don't see how I can get around this simply by using the typical session construct.
So a thought would be to store the user's IP Address when s/he first logs in, and then validate the user's IP on every page. Thus, if a sessionid is hijacked, the attempted illegitimate access would not work, because the hijacker's IP address would be different. Unless, of course, the hijacker and valid user both use the same proxy. Or, if an AOL user logs in and is on a system with rotating proxies, then the valid user's IP will change, but my system would reject it, thinking it is someone different....
And the wheels on the bus go round and round....
The problem with the typical session construct is that anyone monitoring network traffic can easily hijack the user's sessionid cookie (usually PHPSESSID). If they gain access to the PHPSESSID cookie, then they can use the cookie to have illegitimate, but valid, access to my site.
What I am trying to do is find a system/method/etc. that can verify that the user is who s/he says s/he is, and is not really a hacker who obtained a hijacked sessionid. I don't see how I can get around this simply by using the typical session construct.
So a thought would be to store the user's IP Address when s/he first logs in, and then validate the user's IP on every page. Thus, if a sessionid is hijacked, the attempted illegitimate access would not work, because the hijacker's IP address would be different. Unless, of course, the hijacker and valid user both use the same proxy. Or, if an AOL user logs in and is on a system with rotating proxies, then the valid user's IP will change, but my system would reject it, thinking it is someone different....
And the wheels on the bus go round and round....
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: More PHP session fun
The problem lies on the transport layer and not on the web application layer. Using SSL/TLS, which works on the low-level application layer, will stop eavesdroppers and man-in-the-middle attacks.rburgens wrote:The problem with the typical session construct is that anyone monitoring network traffic can easily hijack the user's sessionid cookie (usually PHPSESSID).
There's always going to be something (the key) that gives the intruder an access. For example, in the case of RSA, if you know the d, you can decrypt the encrypted message, but it's incredibly hard to know the missing component.rburgens wrote:What I am trying to do is find a system/method/etc. that can verify that the user is who s/he says s/he is, and is not really a hacker who obtained a hijacked sessionid.
This does help, because it operates on the transport layer (and the IP is brought to your application layer). The approach is good as long as you don't limit your users too much.rburgens wrote:So a thought would be to store the user's IP Address when s/he first logs in, and then validate the user's IP on every page.
-
HavokDelta6
- Forum Newbie
- Posts: 16
- Joined: Mon Sep 28, 2009 4:11 pm
Re: More PHP session fun
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Last edited by HavokDelta6 on Tue Mar 20, 2012 6:02 am, edited 1 time in total.
Re: More PHP session fun
HavokDelta6,
That's not a bad idea. I wrote something similar to that. But I ran into a couple problems: (1) if the user has a transparent proxy server, then EVERYONE on that network will show up as having the same IP address, which means ANYONE on that network could hijack the cookie and get their access. And (2) some users use a rotating proxy server, so their IP address will change, and they will suddenly appear to be illegitimate. Hence the session is closed and the user gets ticked off because they had only been browsing for 5 minutes when they got kicked off....
Other than that, checking the IP works perfectly....
Ideas?
That's not a bad idea. I wrote something similar to that. But I ran into a couple problems: (1) if the user has a transparent proxy server, then EVERYONE on that network will show up as having the same IP address, which means ANYONE on that network could hijack the cookie and get their access. And (2) some users use a rotating proxy server, so their IP address will change, and they will suddenly appear to be illegitimate. Hence the session is closed and the user gets ticked off because they had only been browsing for 5 minutes when they got kicked off....
Other than that, checking the IP works perfectly....
Ideas?
Re: More PHP session fun
If they are monitoring network traffic then it would be far easier to just get the plain text username/password that the user logged on with and go till their hearts content. No need to hijack anything else or am I missing something?rburgens wrote:kaisellgren: good points!
The problem with the typical session construct is that anyone monitoring network traffic can easily hijack the user's sessionid cookie (usually PHPSESSID). If they gain access to the PHPSESSID cookie, then they can use the cookie to have illegitimate, but valid, access to my site.
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: More PHP session fun
Probably. However, the login procedure happens once whereas the session identifier is sent with every request. Also, I've seen different kinds of JavaScript encryption on the login page that makes the reading of the original password from hard to impossible. Some developers also use SSL/TLS on the login page, but nowhere else.veldthui wrote:If they are monitoring network traffic then it would be far easier to just get the plain text username/password that the user logged on with and go till their hearts content. No need to hijack anything else or am I missing something?
-
HavokDelta6
- Forum Newbie
- Posts: 16
- Joined: Mon Sep 28, 2009 4:11 pm
Re: More PHP session fun
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa