3

I have recently come across some logs in my application where I have seen the user's browser agent info being switched. Even if the user is using the same browser, the agent info has been modified for consecutive requests.

For example, a request from the user came from

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0)

But the user hasn't changed his/her browser, and the browser info was:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/7.0)

If I cannot even rely on the browser agent info, what is the ideal way to confirm that the browser agent has/hasn't been changed?

Problem I am trying to solve

Session fixation problem - I am trying to detect when a user does the following:

1) Grabs request headers belonging to an authenticated session. 2) Goes to another computer in a different location (e.g. different computer/browser). 3) Fires a new request with the same headers from the authenticated session and receives a successful response with resources (e.g. file/page with private data).

I originally tried to solve it with IP address and Browser agent checks - but I realised that due to NAT switching IP address check is totally impractical. Now it looks like browser-agent check is also not good.

ha9u63ar
  • 151
  • 6

3 Answers3

3

Don't use the user agent for security purposes.

  • It's not reliable and easy to change. As others noted, every browser can set the user agent to an arbitrary value. It's just an information header that you may decide to send.
  • It's not private and easily predictable. There are lists of the most common user agents. So an attacker can either make educated guesses or lure the victim on an own site to log the user agent string and use the obtained value.

The problem you describe is also not a session fixation vulnerability. It's acceptable behavior that the same authenticated request works from different locations. For example, when logged in on Github you could extract the user_session cookie from one browser and simply use it on another machine. Since an attacker doesn't easily get access to your browser's cookie jar, this is not a general security problem.

Arminius
  • 43,922
  • 13
  • 140
  • 136
0

As you know, the user agent can be changed, tampered, etc on client side. So, you can try to store ips, user agents and do some kind of checking... but you need a third factor here: time. In how many time are you going to accept a connection coming from same ip with different user-agent? Is not easy to differentiate the "natural-legal" connections from the "spoffing-trying-to-hack-you-requests" connections. I think there is not 100% method to do this.

OscarAkaElvis
  • 5,185
  • 3
  • 17
  • 48
  • I am not sure the "Frequency/time" is even valid - the attacker requires only 1 frequency to work and if it works first time - damage is done. Additionally, this log information will keep growing exponentially high and require substantial maintenance effort. I do think your answer is quite reasonable, but that "One" time successful attack also needs to be "Zero" time. – ha9u63ar Dec 13 '16 at 12:20
  • Yes... I'm not talking about this is valid. I said "there is no 100% method to do this". I know that if the attacker success once, it's done. So that's the reason because I never use this kind of validation... I only trying to advise to you :) – OscarAkaElvis Dec 13 '16 at 12:25
  • How about checking "Which server you have been authenticated with"? - For majority of applications, a nest of servers are available via load balancer to optimise network time and performance. But that does not mean that an authenticated session will make requests to a different server other than the authenticating one. So if try and add this check (server IP address), shouldn't it prevent the issue to some extent? – ha9u63ar Dec 20 '16 at 13:19
0

Since the user agent is easily changed and is contained in the headers you worry about in your problem statement, the method you propose to address the problem is invalid.

Your problem statement describes session hijacking, not session fixation.

Lots of people have tried to come up with solutions to the problem; none of them are robust. Such solutions usually break when the user opens a new window, or use the back button - if you can live with this, and there really is a net benefit then have a look at CSRF tokens.

The most important preventative measures to protect against replay / session hijacking are:

  • always use TLS
  • make sure you are setting the httponly and secure flags on session cookies
  • provide the clear and explicit LOGOUT facility
  • enforce session timeouts
symcbean
  • 18,278
  • 39
  • 73