4 Answers
4

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.

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.

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.

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.
– SilverlightFoxNov 24 '15 at 14:34

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.
– SilverNov 26 '15 at 21:26

It is possible to obtain a victims IP then the attacker spoof that IP isn't it?
– Imag1neNov 27 '15 at 11:07

Can you spoof an IP? I would assume your ISP will not allow you to.
– SilverNov 27 '15 at 11:08

Google IP spoofing there is plenty of information about this.
– Imag1neNov 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.
– SilverNov 27 '15 at 11:15