Question about session hijacking
Moderator: General Moderators
They absolutely can and do for AOL members. The proxies they go through can often change mid-*page* even, from one coast's proxies to the other. IP addresses are completely, totally, absolutely unreliable as a user identifier. Do not use them as such.dbevfat wrote:In case of IP switching between single requests in a session, I don't believe that the IP's highest two octets are gonna change. But even if they do - if you take only the first IP number, you're still protected from me, for example.
It doesn't really matter to the discussion. Users can modify them (falsify them) so they are unreliable as user identifiers regardless of IE's behavior.dbevfat wrote:Forgot to mention; not sure, but I believe IE changes the ACCEPT headers.
Well, here where I live there are currently no providers that do that. And since my projects are (for now) local, I can rely on a user having the same IP within the session. Luckily, I've heard about IP changing, so I have two options ready; half-ip address matching and without ip. When trouble comes, I'll switch to lesser security mechanism.Roja wrote:They absolutely can and do for AOL members. The proxies they go through can often change mid-*page* even, from one coast's proxies to the other. IP addresses are completely, totally, absolutely unreliable as a user identifier. Do not use them as such.
You have to rely on something, don't you? Everything that users send can be spoofed, but ordinary users will not change their USER_AGENT in the midst of the session. And hackers will hopefully _not_ find out which USER_AGENT the victim is using. Some sort of security by obscurity.Roja wrote:It doesn't really matter to the discussion. Users can modify them (falsify them) so they are unreliable as user identifiers regardless of IE's behavior.
To be honest, I'm afraid to rely on anything other than User-Agent for consistency. My research has shown that many headers are inconsistent, particularly with Internet Explorer.bsdguru wrote:Chris, what are your recommendations for variables to include in a "vistor fingerprint"?
If reliability is more important to you than security (and there's nothing wrong with that), it's best to abandon the idea of a browser fingerprint altogether and generate a unique token for the user that you then propagate just as you would a fingerprint.
I completely agree.timvw wrote:REMOTE_ADDR is something i don't consider as an option.
AOL is always the poster child for why this is a bad idea, but in truth, there are many large ISPs that use HTTP proxy clusters with completely different IP ranges. As ISPs continue to merge, the problems with relying on TCP/IP information are going to grow rather than diminish. It's a poor practice that's worth abandoning immediately.
You probably read it from me. I'd like to claim that my research revealed this, but in fact, I relied upon Accept consistency in a production application and discovered this the hard way. Luckily, I had very good intrusion detection and reporting mechanisms that helped me track down the problem, and it was rare enough to not be catastrophic.dbevfat wrote:I believe IE changes the ACCEPT headers. I've read it somewhere a while ago.
You can try it for yourself, but what I found was that Internet Explorer changes the value of Accept depending upon whether the user reloads the page. When a user reloads, the value of Accept was more "accepting" than it would otherwise be. So, users who reloaded were always prompted for their password. Luckily, I make it a point not to overreact to suspicious activity, so the unnecessary password prompt was the only bug.
It does matter. If someone changes their headers, I don't feel sorry for them having to enter their password again. :-)Roja wrote:It doesn't really matter to the discussion. Users can modify them (falsify them) so they are unreliable as user identifiers regardless of IE's behavior.
These techniques being discussed are absolutely not a substitute for keeping the session identifier a secret. These are Defense in Depth mechanisms - extra safeguards that might "save the day" should the session identifier be captured by an attacker.
The idea is simple - you have nothing more than HTTP requests to work with. In order to help strengthen the identity of the session identifier, you can try to check for consistency between requests. Requests coming from your legitimate users will have some consistent behavior. When you observe inconsistencies, you prompt for the password as an extra layer of protection against session hijacking.
In fact, in order to add more reliability to consistency checks of things like User-Agent, you can record the consistency history. For example, if a user's last 100 requests had a consistent User-Agent, I feel more confident that a future inconsistency is reason for suspicion. This requires a bit more work, but it's a pretty strong and reliable approach.
Yep, and despite the "no security through obscurity" mantra, obscurity does have some value as a Defense in Depth mechanism. Also, obscurity is pretty hard to define - by strict definition, the session identifier itself can be considered obscurity, because it could (in theory) be guessed. Of course, the predictability of a session identifier is extremely low - low enough to be negligible in practice.dbevfat wrote:Some sort of security by obscurity.
No, actually, and thats really what I was getting at.dbevfat wrote:You have to rely on something, don't you?
First and foremost, everyone's needs are different. There is a balance between security and risk in every environment, and you attempt to balance it correctly. (The old joke about an unplugged computer in a locked room is a great example of security gone too far).
For web-based games (my personal area of enjoyment), you want it to be secure enough to deter most attackers. The attackers are generally savvy, but not highly motivated, because the potential reward is low.
So, implementing a reasonable set of protections (Solid login sequence using hashed passwords, db-driven encrypted sessions, etc) goes a long way towards meeting those requirements.
But even if my focus was on a highly-secure site, I would focus more on reauthentication, use of ssl, and limited session lengths than I would on building a fingerprint. I wouldn't have 'remember me' functionality, I'd have limited session lengths, one-time pads for logins, and reauthentications on key functions (including a session regeneration).
Unfortunately, I've found that not to be true. Especially for Opera users, they have a habit of changing it when they think something isn't working correctly.dbevfat wrote: Everything that users send can be spoofed, but ordinary users will not change their USER_AGENT in the midst of the session.
The inconsistencies in all of these fingerprint methods are exactly why I don't embrace them. I accept the shortcomings as they are, and don't make excuses (local users, users that use opera) that ignore the issues that do exist.
Quoting the original poster:
I focus instead on making the rest of the links as strong as possible, and by doing so, accept a balance between security and risk that does entail some risk: At the benefit of ensuring that Opera users, IE users, AOL users, and Proxy users won't come and complain about my poor choices in security.Swede78 wrote: I use sessions for much more than storing log-in information. I have a lot of multi-page forms that rely on sessions. I would be quite annoyed if I had to re-login and start over after filling out multiple pages of information for 15 minutes. I wouldn't want even 1% of my users to experience that.
Your mileage may vary.
Re: Question about session hijacking
I have a question for this old thread. Many of the responses here say never rely on IPs, but what if you can detect Proxy IPs. Wouldn't adding a non Proxy IP to one's fingerprint add extra security?
I read this thread:
http://forums.digitalpoint.com/showthread.php?t=58964
And, I found this code, which is supposed to detect proxy IPs, although, I have no clue how reliable it is:
if (
$_SERVER['HTTP_X_FORWARDED_FOR']
|| $_SERVER['HTTP_X_FORWARDED']
|| $_SERVER['HTTP_FORWARDED_FOR']
|| $_SERVER['HTTP_CLIENT_IP']
|| $_SERVER['HTTP_VIA']
|| in_array($_SERVER['REMOTE_PORT'], array(8080,80,6588,8000,3128,553,554))
|| @fsockopen($_SERVER['REMOTE_ADDR'], 80, $errno, $errstr, 30))
{
exit('Proxy detected');
}
I read this thread:
http://forums.digitalpoint.com/showthread.php?t=58964
And, I found this code, which is supposed to detect proxy IPs, although, I have no clue how reliable it is:
if (
$_SERVER['HTTP_X_FORWARDED_FOR']
|| $_SERVER['HTTP_X_FORWARDED']
|| $_SERVER['HTTP_FORWARDED_FOR']
|| $_SERVER['HTTP_CLIENT_IP']
|| $_SERVER['HTTP_VIA']
|| in_array($_SERVER['REMOTE_PORT'], array(8080,80,6588,8000,3128,553,554))
|| @fsockopen($_SERVER['REMOTE_ADDR'], 80, $errno, $errstr, 30))
{
exit('Proxy detected');
}
Re: Question about session hijacking
Hmm, I read this in regard to proxy headers:
"Highly anonymous proxies don’t add the abovementioned headers and can’t be detected with this technique."
http://w-shadow.com/blog/2007/11/23/det ... a-a-proxy/
"Highly anonymous proxies don’t add the abovementioned headers and can’t be detected with this technique."
http://w-shadow.com/blog/2007/11/23/det ... a-a-proxy/