3

I'm teaching myself a touch of the most basic information security while toying with web dev, so that I can get a better understanding of the whole picture.

Let's assume my website has user accounts that have nonzero personal information stored in them.

Is it ever appropriate to store session IDs associated with this connection over HTTP?

I ask beacuse I was looking through my own cookies and I see some of the ones under "google.com" are marked as "send over any connection"-- am I correct in assuming that these session IDs are not in any way linked to personal information that an attacker / sniffer could obtain or abuse?

2

In this question regarding Google's cookies and the HTTPonly flag:

[Google] store the important stuff (for example, HSID, NID and SSID) as HTTPonly

Additionally, the SSIDcookie is marked with the Secure flag. This means that it won't be sent by the browser over a plain HTTP connection.

So to answer your question, if your Session ID allows access to personal information, you should set the Secure flag to ensure it is never leaked over plain HTTP. If not, an attacker could force a leak if their victim is browsing their website by including a plain HTTP reference in the page (e.g. <img src="http://example.com/foo" />) and then MITM the connection.

However, it may be acceptable for Session IDs that do not allow access to sensitive information. For example, you may set a cookie so you can let a user add items to their basket and then when they proceed to checkout the contents of the insecure session is transferred to the secure session which is over HTTPS only. An attacker can only intercept the insecure session and possibly add or change basket items, although as the site asks the user to confirm their order once contents have been transferred they cannot force the user to order something. Additionally, all personal details are protected as baskets are considered anonymous until the HTTPS checkout is reached.

I believe Google use non secure and non-http only cookies for items in a similar way. The SSID appears to be the important session identifier and this is protected by both flags.

1

If the cookie is meant to be kept private such as a session cookie, definitely not. Google may think that they don't need to specify that the cookie is sent over a secure connection because they already default to https for all secure aspects of the site. The most likely reason is probably because Google is set to be automatically redirected to https by the browser because of HSTS. Therefore, the cookie would most likely not be at risk of being sent over an insecure connection. However, it couldn't hurt.

It would be best to never send it over an unencrypted connection because there is a greater chance that an attacker will be able to read the cookie and access the user's account.

4
  • Thanks, I understand everything but "However, the application should, theoretically, be secure enough that even if an attacker got the cookie(s), he would have a difficult time using it to his advantage." Wouldn't having the cookie (and therefore session ID) be enough to impersonate an individual? Since we can't rely on recording IPs or geolocation as they may on occasion be inaccurate. Feb 19 '15 at 3:07
  • True, I was thinking of somewhat using the IP. For example, doubtfully, a user will switch from being in Alaska to India, but that would probably be irrelevant in this case anyway since the two users would probably be accessing the same router.
    – Anonymous
    Feb 19 '15 at 3:12
  • Yeah, my reasoning for not relying on IP was that people use their phones in their car often enough to not be able to reject based off of IP. One of my local cell tower often gets geolocated to ~100 miles north of where I live. Are there any other ways to protect from session hijacking, assuming an attacker has access to the session ID? Feb 19 '15 at 3:15
  • The browser can be detected, but that's trivial to spoof. The best thing to do is assure that such an event never happens, which can be controlled slightly more.
    – Anonymous
    Feb 19 '15 at 3:18

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.