0

Just out of curiosity and security test, i copied my own browser's cookies to another pc on same browser and surprisingly i managed to open facebook and google accounts with existing sessions even after public ip changed!!

Imo, it would be more secure if websites was clever enough to detect you r accessing an existing session from same platform/agent but from a combination of different ip/mac/machine model/unique id etc. in this case even if sessions stolen, only combination of same platform/agent/ip/user/any unique id that is related to actual user would be able to continue existing session. wouldnt it be good protection againts session hijackings? cheers

  • Some do respond to changes in the user agent. But generally the effort is put into protecting the session identifiers or limiting the damage caused if they were breached (ie short lived sessions). Filtering on IP isn’t very practical since many users will change IPs for the same computer throughout the day. – nbering Feb 18 at 2:35
  • Of the things you mentioned: IP is likely to be the same for your two machines, if you were in the same building - you're likely being NATted when you go out the door. Which may also be done by your ISP as well. Note that residential IPs tend to change frequently, so this might cause you to log in every day. MAC address will not be visible to the server. Machine model isn't visible to the server, if it even exists (what is it for a home-built machine?). Any competent attacker can spoof any provided value, except for possibly the IP. – Clockwork-Muse Feb 18 at 4:30
  • web sessions are stateless meaning is somebody gets your sessions id cookie, they can sign in as you, Most sessions in web programming languages work this way. It's the programmers job to "lock" down a session id to a IP/useragent combination. – Raymond Nijland Feb 18 at 14:53
3

There is always a balance between usability and security. There are some changes which might be perfectly normal, like visiting the same site from a totally different IP address (mobile users), with a slightly different User-Agent (might be caused by browser update), from a slightly different operating system fingerprint (might be caused by OS update or changes on hardware or restoring system from backup) etc. Getting cookies invalidated in these cases would be more secure but would also be annoying for the user.

But binding sessions to specific environments is also done in practice in cases where the sessions are short-lived so that the environment could be treated as kind of constant or where the data are very sensitive and it is acceptable to login again on any changes to the environment.

On the other hand: what you did is to explicitly copy the cookie from the browser into another browser. This is not what an attacker could do if the site is properly protected (HTTPS, http-only cookies) and the attacker has no physical access to your system. Insofar binding a cookie to an environment should be more seen as an additional protection layer in case the other layers somehow fail (which they hopefully don't) and not as the single layer which protects against session theft.

  • "This is not what an attacker could do if the site is properly protected (HTTPS" What do you say here? https does not protect against code vulnerabilities ever, https only encrypts the data between server and client to prevent man in the middle attacks and eavesdrops, If client requests a SQL injection, uses Cross Side Scripting or tryes to fix the session id and the application is vulnerable the application will still execute with the vulnerability – Raymond Nijland Feb 18 at 15:00
  • 3
    @RaymondNijland : I did not claim that https protects against application vulnerabilities nor did the context of the question were application vulnerabilities. https protects against stealing the session by sniffing the network. http-only cookies instead help against session stealing misuing application vulnerabilities. – Steffen Ullrich Feb 18 at 15:38
  • When i readed "This is not what an attacker could do if the site is properly protected (HTTPS, http-only cookies) and the attacker has no physical access to your system" it did look like that is what you meant that https protected against every application vulnerabilities . "https protects though against session stealing by sniffing the network." That statement is very true. "http-only cookies instead help against session stealing misuing application vulnerabilities. " Yes but only if the browser supports it. – Raymond Nijland Feb 18 at 15:41
  • 3
    @RaymondNijland: all relevant browsers support http-only cookies for ages. Any browser which is that old or special to not support these is likely a security risk by itself. – Steffen Ullrich Feb 18 at 15:50
  • "all relevant browsers support http-only cookies for ages. Any browser which is that old or special to not support these is likely a security risk by itself" sounds more or less security by obscurity into trusting that every internet user is using the modern browsers which support http only cookies.. it's not enough you should also regenerate your session id atleast at login level (or every request might be even better but more resource hungery but can cause trouble with AJAX requests) so session id fixing and session hijacking are not possible.. – Raymond Nijland Feb 18 at 16:03
0

Because its very inconvenient for very little gain. Being able to copy the session cookies from your computer would be a very difficult attack that is on a similar level to being able to log your password as you type it. Its a safe enough assumption to say that it is the users responsibility to keep this cookie safe like it is the users responsibility to keep the password safe. If someone was able to steal your cookie they could likely also work out what your user agent was and copy that as well.

On the inconvenience part, many users regularly change ip address, phones change address regularly as well as sharing the same address with many other users at the same time. Also switching from wifi to mobile data. Even most home internet connections change address daily so by invalidating a session based on IP address you will likely be logging out your users multiple times per day for next to no gain. Also some privacy focused users may have their user agent set to change semi regularly.

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.