8

So for years I have been using various user checks on top of the session token they are issued to maximise security.

I am now looking at developing a session system across separate servers and am wondering whether this is still relevant.

Considering Oauth does not use any of these extra checks and is widely used, can a session token on it's own been thought to be reliable? Google and Facebook would appear to think so.

The extra checks such as IP and user browser information can all be stolen just as easily as cookie if that line of attack exists.

So will it be ok to concentrate on well formed session tokens as opposed to adding the extra measures.

This page lists the typical extra measures used PHP session security

Before I get jumped on, I understand how Oauth works, but ultimately it results in a single session token for validation once the session exists.

7

If you use cookies to store session ID's just make sure it is set in a cookie with the Secure and HttpOnly attribute. Restrict the domain and path attributes as much as possible. Make sure no untrusted web application is hosted on a related domain who could launch a session fixation attack. Set a reasonable expiration time for the session. Serve all your pages over HTTPS since mixed content might leak your session ID. Try to limit the externally loaded JavaScript libraries to minimize the attack surface.

Some application servers like Tomcat allow you to use SSL session ID's instead of session ID's stored in cookies. These SSL session ID's are better protected but you should be able to share the SSL session over multiple servers in your case.

A lot more tips can be found here: Session Management Cheat Sheet

EDIT:

They are no working on binding tokens like session ID's to a client via public-private key and signing. Read the draft here. It will take some time before it will be adopted by the major browser vendors but as far as binding a session ID to a client goes, this seems to solve all the issues. Of course there is some key generation and signing overhead and you require client support for this to work.

  • 1
    Surely you mean HTTPS-Only attribute. – Pavel Nov 24 '15 at 15:43
  • 3
    @PavelPetrman - the option is called HttpOnly and is distinct from the secure flag. I will edit the answer back – paj28 Nov 24 '15 at 16:10
  • Oh, my mistake. Thank you for correcting the spelling, now it's clear what's been meant. – Pavel Nov 24 '15 at 16:14
5

You need to ensure that

  • you have an authentication information - your token for instance
  • this authentication information cannot be guessed - the token must have, among others, a good enough entropy and atomicity (one token is generated independently from others, in other words knowing one token does not help you to know the next one)
  • this authentication information cannot be fiddled with while in transit - use HTTPS

if you want to further restrict who can authenticate, use client side certificates (since you will be using HTTPS anyway) - they are likely to scale better than IP filtering.

As you mention, tokens are good enough for Google and other big players. They are therefore good enough for me as well.

1

Session tokens are only useful when transmitted over a secure protocol (like https://). Session tokens without a secure protocol can indeed be stolen easily.

  • Additionally a MITM attacker could inject a request to http://example.com:443 (where example.com is your site) and then steal the cookie, even though your site never transmits it over plain HTTP. This is why the Secure flag is useful. – SilverlightFox Nov 24 '15 at 14:34
0

This too long for a comment to Silvers answer, but it uses information from the link he posted and answers my question quite specifically.

Binding the Session ID to Other User Properties

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

This highlights what is kind of a mixed message. On one hand it is suggested that user information is stored and cross-checked to flag up clear hacking attempts, yet it is admitted a skilled attacker can spoof this information.

So you'd have to conclude if you want to protect against skilled hackers and who doesn't that these cross-checks while making you feel better wont actually offer any more protection.

  • " However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network" This is not possible for every attacker. This assumes that the attacker is, or is able to, use the same network as the client. Binding IP address will in fact enhance security, even against a skilled attacker. The attacker should have control of a machine inside the same network as the client and I believe that session hijacking is a small problem when an attacker has such capabilities. – Silver Nov 26 '15 at 21:26
  • It is possible to obtain a victims IP then the attacker spoof that IP isn't it? – Imag1ne Nov 27 '15 at 11:07
  • Can you spoof an IP? I would assume your ISP will not allow you to. – Silver Nov 27 '15 at 11:08
  • Google IP spoofing there is plenty of information about this. – Imag1ne Nov 27 '15 at 11:12
  • I know it's possible but I doubt it being possible when your on the other side of the internet being connected through an ISP. In your local network this is definitely possible. An attacker on the same network as the server might be able to spoof his IP. I would just assume that an ISP would not allow packets with an IP address that differs from the IP it gave you. But correct me if I'm wrong. – Silver Nov 27 '15 at 11:15

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.