3

On a phpBB forum I manage a user has requested that we turn off the "Validate browser" setting which invalidates user sessions if they change user-agent, because they use a mod which randomises their browser's user-agent.

Does tracking and requiring the user-agent to match give an actual benefit to security?

  • They made their request saying they do this to mitigate fingerprinting and tracking - and the cynic in me thinks it's working exactly as intended. But if this phpBB feature doesn't give any real benefit I guess we should disable it. – curiousdannii Jun 2 '18 at 12:48
  • As a (late) side note for future people that stumble over this question: My company has been running a Magento online shop for a while and we had problems with lost sessions, because Magento checks the user agent by default. We eventually found out that some mobile phones toggle between two user agent strings for unknown reasons without the users knowledge. One request has one string, next request has a slightly different string, then back to the first string, second string,... That meant we were unintentionally blocking some customers, so we ended up disabling that feature. Too unreliable. – Morfildur Nov 27 '18 at 14:24
5

Including the user-agent in the session provides some rudimentary protection against session hijacking. This means if the attacker somehow got access to the session cookie he cannot just simply use the cookie in some random browser but must use the same browser, version, subversion etc as the original user - or at least know what the original user-agent value was and make the own browser use this.

If the session id is stolen by sniffing (unprotected) traffic then the user-agent is easily available too within the sniffed data so it can be perfectly faked. If the session cookie is instead stolen by XSS or similar (i.e. cookie was not set to httponly) the exact user-agent is not immediately known but can be retrieved with some tricks too (see comment from @multithr3at3d on this answer).

Thus, including the user-agent into the session cookie will not provide relevant additional protection if your site is HTTPS only (or at least the cookie, i.e. has the secure flag) and the cookie cannot read by XSS (i.e. httponly flag), which are both things you should do anyway.

  • 1
    So if the site is HTTPS only and the cookie is httponly then the risk is reduced? – curiousdannii Jun 2 '18 at 13:27
  • @curiousdannii: correct. – Steffen Ullrich Jun 2 '18 at 13:36
  • 5
    If you have code execution via XSS, it would be trivial to retrieve the user agent by making a request to a server you control, and viewing the access logs. – multithr3at3d Jun 2 '18 at 16:39
  • @multithr3at3d: thanks for the idea. I've adapted the answer accordingly. – Steffen Ullrich Jun 2 '18 at 17:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.