50

Given the appropriate XSS vulnerability, an attacker can hijack somebody's session with the data that's passed to and from the server.

Why aren't sessions always exclusive to the IP they were started on? i.e., when would a website/service need to persist an authenticated session across multiple IP addresses? I'm not sure why sessions permit this, thus I don't understand how this is ever a feasible route for an attacker.

grochmal
  • 5,677
  • 2
  • 19
  • 30
  • 32
    An IP address is not a reliable way to identify a user. – Michael Hampton Oct 17 '16 at 13:19
  • 2
    Some people like to use TOR _and_ have sessions supported... – recursion.ninja Oct 17 '16 at 13:48
  • 75
    So if I'm on my phone and get out of my house (losing wifi but connecting to 4G) I should lose all my sessions? – N.I. Oct 17 '16 at 14:08
  • 8
    @NajibIdrissi Not just phones, but laptops also. Take your laptop someplace else, lose sessions on all website? No thanks. – marcelm Oct 17 '16 at 14:53
  • 2
    Sounds like what you're looking for is [channel-bound cookies](http://www.browserauth.net/channel-bound-cookies). (A much more practical and secure implementation of what you're proposing.) – Ajedi32 Oct 17 '16 at 16:06
  • 1
    Possible duplicate of [Are PHP Sessions based on cookies or a cookie-IP pair?](http://security.stackexchange.com/questions/6569/are-php-sessions-based-on-cookies-or-a-cookie-ip-pair) – one Oct 17 '16 at 17:24
  • 15
    XSS attacks inject code into the user's browser, and thus even forged requests originate from the same IP as the user. – jpaugh Oct 17 '16 at 18:03
  • 1
    Note that some scammy ISPs deliberately change your IP address every so often. – André Borie Oct 17 '16 at 20:12
  • http://security.stackexchange.com/q/112819/971, http://security.stackexchange.com/q/6569/971, http://security.stackexchange.com/q/13009/971, – D.W. Oct 17 '16 at 21:40
  • There are web sites that do so. Comodo is an example. I learned it when trying to get an SSL certificate from Comodo using Tor. – v7d8dpo4 Oct 18 '16 at 02:57
  • If this was the case, you'd have to log in more often, which open new doors in terms of vulnerability. – whirlwin Oct 18 '16 at 13:30
  • 3
    @AndréBorie Not 'scammy' behavior in the slightest- the proper term is *dynamic IP addressing* and changes when the lease expires (often when the router is rebooted). Dynamic IP addressing is far cheaper than using static IPs, and are mostly used for residential broadband packages; if you want a static address, you must ask the ISP or move to a business package. – AStopher Oct 18 '16 at 14:56
  • 3
    @cybermonkey In this day and age when everyone is connected anyway I don't see why dynamic IPs would be cheaper. In any case one subscriber would equal one IP. I still support that dynamic IPs in 2016 are just scammy excuse to sell premium "business" packages which include a static IP. – André Borie Oct 18 '16 at 15:29
  • @AndréBorie Dynamic IPs are cheaper for the ISP as not all customers will be connected to the exchange (the ISP's servers) at the same time. That means that unused IPs can be circulated and are available for use, whereas static IPs are assigned to a single customer and are not cycled. – AStopher Oct 18 '16 at 20:32
  • @cybermonkey unless we're talking about dial-up or edge cases like mobile/wireless/satellite, everyone is connected 24/7 anyway so your argument doesn't hold up. – André Borie Oct 18 '16 at 21:13
  • @AndréBorie In the U.S perhaps, but this mostly is not the case. – AStopher Oct 19 '16 at 07:03
  • @cybermonkey actually I am in Europe, and DSL is pretty much available everywhere and is kept always on, so every customer always uses their IP address. Cable and fiber are being rolled out as well and they are also kept always on. Again, besides dial-up, satellite or similar connectoins where the customer doesn't always maintain the link, dynamic IPs are just a scam, often perpetrated by ISPs where they have little to no competition. If you see any legitimate use case for dynamic IPs in 2016 please enlighten me, but again, besides dial-up or transient wireless connections I don't see any. – André Borie Oct 19 '16 at 13:30
  • In America, 3G data tends to work like a VPN... you can move from tower to tower without having your public IP address change. In contrast, 4G/LTE data tends to work like a wi-fi access point with "hard" hand-offs... every time your phone connects to a different tower, it might be assigned a new IP address (possibly from a different subnet than the previous one). This is a HUGE problem if you're using it in a moving vehicle, like a train or a car on a freeway... every 45-180 seconds, your IP address can change. This causes HUGE problems for users of some corporate VPNs & banking apps. – Bitbang3r Oct 19 '16 at 17:25

4 Answers4

82

First, linking a session to an IP address will not make it secure since the server could see many different users as using the same IP address for various reasons (all types of proxy servers, for instance: client, reverse proxy, CDN, etc.).

Second, the same user could very well use different IP addresses for the same session. For instance, someone could be switching between networks from the same device.

So, since it's not effective and it causes usability and scalability issues, that is not an feature that is usually enabled.

Peter Mortensen
  • 877
  • 5
  • 10
Stephane
  • 18,557
  • 3
  • 61
  • 70
  • Brilliant answer, I hadn't considered that scenario when I was trying to work out why one session may span multiple IPs. –  Oct 17 '16 at 09:10
  • 4
    I do agree with you, but some servers implement IP session stickyness. I can confirm that I loose my session on stackexchange network each time I change proxy... – Serge Ballesta Oct 17 '16 at 09:15
  • 9
    @SergeBallesta That is weird: I don't see that. – Stephane Oct 17 '16 at 09:23
  • 1
    @Stephane bugzilla.mozilla.org can do that too - there's a checkbox at login to restrict the session to the current IP – Bob Oct 17 '16 at 12:50
  • @Bob I haven't said it isn't possible or that it isn't used on some deployment, I just explained the usual reasons why it is disabled. – Stephane Oct 17 '16 at 12:51
  • 2
    Just providing a live example. Not refuting your reasoning. – Bob Oct 17 '16 at 12:52
  • 1
    A user on a mobile device, using their mobile network, could conceivably change IPs within a session. I think most providers now try to "attach" a single public IP to a device through routing voodoo and whatnot, but it's far from certain. – Doktor J Oct 17 '16 at 14:35
  • 5
    @SergeBallesta: I can't speak to StackExchange, but I maintain a site which uses sessions heavily. The session itself isn't tied to IP address, but the servers live behind a load balancer which uses "sticky sessions" - your IP address will go to the same server for ... ever. But, session state isn't shared between the servers, so if your IP address changes, you get a new session. – minnmass Oct 17 '16 at 17:36
  • 4
    Also users may naturally switch networks. Someone walking around with a mobile phone may switch between different WiFis and the mobile network a lot. – viraptor Oct 17 '16 at 23:02
  • 1
    With IPv6, this is also a problem, SLAAC + privacy extensions means the ip address changes every X minutes, Google Chrome handles this already incorrectly and gives random ERR_NETWORK_CHANGED – Ferrybig Oct 18 '16 at 12:16
  • @minnmass: that seems unfortunate. I'm sure it could be fixed with some improved caching behind the load balancer. The load balancer is about system performance, not security. – Craig Tullis Oct 18 '16 at 14:39
  • 1
    @Craig It depends on the protocol. WIth HTTP the LB can use a cookie to make a session sticky to a particular server. But with SSL it only works if the LB performs the decryption rather than passing the SSL session through. – Barmar Oct 18 '16 at 19:55
  • Right, of course. But my point is that's a side-effect of using a LB in the first place, which you do to enable scalability, not for any security reasons. So the session stickiness with HTTPS connections isn't a feature so much as it's a side effect. They also make SSL/TLS accelerators to help with this issue. It all makes life more interesting if you're combining it with PCI requirements, huh? ;-) – Craig Tullis Oct 18 '16 at 20:01
15

Back in the day, AOL was notorious for aggressively load-balancing traffic between its internal network and the Internet across all its exit proxies. This meant that a request for a single web page and its content would come from many different IP addresses: if you pinned a session to a single IP address, the session would break before the "login successful" page finished loading.

This sort of load balancing is less common, but can still happen if someone is using a "web accelerator" proxy or a less-technically-inclined ISP. Slower shifts are more common, such as if someone is using a wireless ISP and gets a new address every time they change base stations.

Pinning a session to a single IP address can make session-stealing attacks harder, but it comes at the cost of preventing some people from using your service entirely, and giving others a degraded experience.

Mark
  • 34,390
  • 9
  • 85
  • 134
10

An attacker can connect to the server from the same address. For example an attacker and the victim are using the same WiFi.
Also, it can cause problems to the user if he/she has multiple routes to the server and the user's IP undergoes Network Address Transition.

one
  • 1,781
  • 3
  • 18
  • 45
  • 3
    WiFi as a vector doesn't preclude using IPs for security, since it would *still* severely limit the effectiveness of a single attacker (limited to several WIFI networks/1 geographic area, e.g.); however, IPs don't protect against XSS attacks at all, because the attacker always uses the same browser as the user to forge requests. – jpaugh Oct 17 '16 at 18:06
  • 1
    @jpaugh XSS could also result in data leaks, such as giving the attacker the session ID to be used elsewhere. Of course, this is largely solved by the use of `httponly` cookies. – Bob Oct 17 '16 at 22:51
  • 1
    I wouldn't say that the statement "An attacker can always connect to the server from the same address" is likely to be true, it *may* be the case but definitely not all the time. – Rory McCune Oct 19 '16 at 15:12
  • @RоryMcCune , yes you are absolutely right. I meant it in a way to show that the likelihood of this happening is not rare. I have edited it though now. – one Oct 20 '16 at 06:31
7

Another reason against binding sessions to a specific IP address is a thing called "Happy eyeballs" (yes, really!).

It is basically a mechanism which tries to detect the best way of establishing a connection when using a Dual-Stack connection (IPv4 and IPv6 supported).

Some OSes do this very aggressivly, OS X for example will even (for example) try to load the webpage it self via IPv6 and then load some images via IPv4 to get a benchmark of which works better.

And of course, as IPv4 and IPv6 use completly different addresses which you can't correlate, really strange things would happen, when you'd bind IP addresses to sessions.

More information: https://en.wikipedia.org/wiki/Happy_Eyeballs

Tobias Mädel
  • 171
  • 3