Question about session hijacking

[timvw]

HTTP_ACCEPT_CHARSET isn't a good idea to use...

[Stryks]

I'm a bit confused by that last reply timvw.

You say that HTTP_ACCEPT_CHARSET isnt good to use, but it's from your own fingerprint function?

Or maybe it's just late.

[timvw]

After i read that HTTP_ACCEPT_CHARSET can change, i don't think it's a good idea to use. I admit that the code i wrote needs an update.

[dbevfat]

I use USER_AGENT and REMOTE_ADDR. If there is possibility that users will have different IP addresses during 1 session, I only use the first half of the address -> [104.54].234.99.
Maybe they change ip, but certainly not continent or state . So it's still partially locked to IP.

[timvw]

REMOTE_ADDR is something i don't consider as an option. For example my ISP has ips in the 81.aaa.bbb.ccc and the 213.ddd.eee.ffff range. And it's unpredictable to know which one you our going to get..

I'm probably going to use HTTP_USER_AGENT, HTTP_ACCEPT and HTTP_ACCEPT_LANGUAGE.

[dbevfat]

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.

[dbevfat]

Forgot to mention; not sure, but I believe IE changes the ACCEPT headers. I've read it somewhere a while ago. Something about adjusting these headers to the document type in question or something, don't remember really. Be sure to check it out.

[Roja]

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.

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.

Forgot to mention; not sure, but I believe IE changes the ACCEPT headers.

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.

[timvw]

Most browsers also allow to change the UserAgent string etc..

It's a matter of choosing those variables you expect that are not going to change while they are using your webapplication. If a user decides to change his UserAgent string in a session anyway, he will need to login again...

[dbevfat]

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.

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.

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.

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.

[shiflett]

Chris, what are your recommendations for variables to include in a "vistor fingerprint"?

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.

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.

REMOTE_ADDR is something i don't consider as an option.

I completely agree.

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.

I believe IE changes the ACCEPT headers. I've read it somewhere a while ago.

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.

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 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.

It does matter. If someone changes their headers, I don't feel sorry for them having to enter their password again. :-)

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.

Some sort of security by obscurity.

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.

[Roja]

You have to rely on something, don't you?

No, actually, and thats really what I was getting at.

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).

Everything that users send can be spoofed, but ordinary users will not change their USER_AGENT in the midst of the session.

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.

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 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.

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.

Your mileage may vary.

[vspin]

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');
}

[vspin]

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/