Question about session hijacking

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

HTTP_ACCEPT_CHARSET isn't a good idea to use...
User avatar
Stryks
Forum Regular
Posts: 746
Joined: Wed Jan 14, 2004 5:06 pm

Post by 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. 8O
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by 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.
User avatar
dbevfat
Forum Contributor
Posts: 126
Joined: Tue Jun 28, 2005 2:47 pm
Location: Ljubljana, Slovenia

Post by 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 :D. So it's still partially locked to IP.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by 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.
User avatar
dbevfat
Forum Contributor
Posts: 126
Joined: Tue Jun 28, 2005 2:47 pm
Location: Ljubljana, Slovenia

Post by 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.
User avatar
dbevfat
Forum Contributor
Posts: 126
Joined: Tue Jun 28, 2005 2:47 pm
Location: Ljubljana, Slovenia

Post by 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
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

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.
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: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
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by 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...
User avatar
dbevfat
Forum Contributor
Posts: 126
Joined: Tue Jun 28, 2005 2:47 pm
Location: Ljubljana, Slovenia

Post by dbevfat »

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.
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: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.
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

bsdguru wrote: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.
timvw wrote: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.
dbevfat wrote: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.
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.
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.
dbevfat wrote: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
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

dbevfat wrote: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).
dbevfat wrote: 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:
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.
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
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Question about session hijacking

Post by 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
Forum Commoner
Posts: 33
Joined: Tue Apr 29, 2008 6:31 pm

Re: Question about session hijacking

Post by 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/
Post Reply