2

I would like to reduce the likelihood of session hijacking by implementing a cookie based token solution.

The idea is to generate a SHA256 hash based on client related information such as:

PHP

$_SERVER['HTTP_USER_AGENT']

JavaScript:

function gatherUserData(){
    return ["time_zone", (new Date()).getTimezoneOffset()/60, "history_length", history.length, "browser_name",
        navigator.appName, "browser_engine", navigator.product, "browser_language", navigator.language,
        "screen_width", screen.width, "screen_height", screen.height];
}

Whenever the client requests a page, I challenge his/her token by recalculating it.

I believe that it is very unlikely that a hacker would have all this information, and, even if he/she has it, would make it a bit harder.

Would it help preventing session hijacking?
Do you recommend any other techniques?

6

This would be effective against session hijacking. It would also log out users when they resize their browser window, or when they update their browser.

The best way to prevent session hijacking is to bind sessions to IP addresses. Furthermore, you should take action when you detect a hijacked session, so when two IP addresses are using the same session identifier.

In the future, you can prevent session hijacking by binding cookies to TLS connections using Token Binding over HTTP.

Edit: see Why aren't sessions exclusive to an IP address? for some disadvantages of binding sessions to IP addresses.

2

So in looking at this problem, you have to consider session stealing as an attack in the context of your application.

Usually session stealing attacks are targeted rather than generic as once the session's been stolen the attacker has to do something with it, so protections that are partially client-side aren't too great as the attacker can likely reverse engineer what you're up to and bypass the protection.

In general the best way to reduce the risk of session hijacking is to reduce the attacker's ability to get access to the session cookie that's used by the site.

so things like

  • Reviewing for XSS
  • Setting cookie flags like HTTPOnly and secure
  • Limiting the time the token is valid for
  • Ensuring that the application logout terminates the session properly
  • Ensuring good SSL configuration to reduce the risks of traffic sniffing

are useful in reducing the risks. Also as @sjoerd says, you can tie the token to a source IP address but that can be a bit risky if the clients are behind load balanced proxy servers where their requests could come from different IP addresses during a single session.

The suggestion in your question is likely a bit brittle and if an attacker can get access to the user's browser (which they likely need to, to steal their session token in the first place) they can get access to all the information you're using to create the token in the first place and pass that to you, bypassing the protection.

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.