I'm logged in to security.stackexchange and I'm not using https to browse the site.
Does this mean that the site is vulnerable to session hijacking? I assume that it's not, but I don't get how session is protected if connection is not secure.
-
1As the FAQ says, "What background should I give in my question? Security is a very contextual topic: threats that are deemed important in your environment may be inconsequential in somebody else's, and vice versa. [...]" It is helpful to list what kinds of attacks you are thinking about, and what threat model you have in mind (an on-path eavesdropper? an off-path attacker trying to find a XSS exploit? something else).– D.W.Jan 18, 2016 at 20:41
Add a comment
|
3 Answers
The session cookies (or at least, what looks like session cookies to me) acct and sgt are both served with the HTTPOnly flag. This means that client side Javascript can't access them, making it hard to session hijack using things like XSS vulnerabilities or similar.
This does not protect against at attacker who can intercept your traffic, but in that case, it is possible to access the site with HTTPS enabled - just go to https://security.stackexchange.com
I don't know why it doesn't default to the secure version, but there is relatively little sensitive data being transferred after the initial sign in (almost everything is publicly available, after all), so it may be that the cache advantages of not encrypting outweigh the security benefits.
-
7So my flatmate could potentially steal my session and post some random nonsense question that could get me a ton of negative votes for the sake of cache? Jan 18, 2016 at 15:24
-
14@EpicVendetta If you don't trust your flatmate, I suspect there are far worse things they could do - ever left your wallet somewhere they can get to? Received post? I would guess that stealing your SE token and messing your karma levels would be far too much effort for very little gain...– MatthewJan 18, 2016 at 15:43
-
2@Matthew Pranking and stuff it's what I fear. Not really I was just presenting a possible scenario. Yet connecting to SO on library's wifi seems to be a concern too then Jan 18, 2016 at 15:47
-
14The problem with MITM is that someone might ask "Is my homemade crypto safe" on security.SE and the attacker could replace Matthew's answer with "Sure, looks like you did a great job!". Jan 18, 2016 at 18:06
-
1@WhiteWinterWolf It's disappointing that they still haven't made it work. I had to remove stackexchange from HTTPSeverywhere over a year ago; although it looks like details of the failure mode might've changed. Jan 18, 2016 at 19:03
-
11@EpicVendetta: How do we know it's not the flatmate asking the original question? ::mindblown::– loneboatJan 18, 2016 at 20:06
-
1@loneboat How do we know it is you making that comment? Or me making this one? Wait a minute...– user82913Jan 19, 2016 at 0:41
-
3Remember, even if accessing it over HTTPS, unless the cookie is marked as Secure it can still be leaked by a MITM attacker over HTTP. Jan 20, 2016 at 13:47
-
@dotancohen as opposed to asking on SO, where he would get that answer anyway...– AviD ModJan 22, 2016 at 11:03
-
"there is relatively little sensitive data being transferred after the initial sign in" oh yeah, only your session cookie. No trouble there. ... What a terrible way to think about security in context of this site.– LucJan 23, 2016 at 1:15
-
1@SilverlightFox, Even though SE has hundreds of staff, there isn't even one pentest/security team.– PacerierJan 28, 2016 at 12:09
-
@Matthew, HTTPS still isn't on meta yet: https://meta.security.stackexchange.com.– PacerierJan 28, 2016 at 12:10
-
@dotancohen Your attacker would also need to duplicate the enthusiasm of high tech companies and the NSA, all of whom would be interested in this new crypto technology.– corsiKaJan 29, 2016 at 17:30
Yes, it is vulnerable. Anyone can grab your session cookie.
Why? Ignorance and denial as far as I can tell. Very slowly StackExchange developers have been moving towards enabling https, but after a short spurt of development it seems to have stopped again. I still don't use this site on higher-than-average risk networks (public wifi; security conferences), or I turn on VPN first if I really want to use this site. StackExchange is the only site I frequent that does not support https.
If you type https in the address bar manually, it seems to accept that now. I hadn't noticed this yet, in the past it'd redirect you back to insecure http unless you were on the login page, and right now it still has mixed content issues. Ugh. It really isn't that difficult.
Typing https manually works if you're logged in (if not, after logging in it will kick you back to http so there goes your session, no matter what you do), but the DNS lookups reveal which site you're using and someone could easily inject a request in your browser (when you use, say, a news website over plain http) to the insecure version to grab your session cookie.
TL;DR: ignorance from the developers regarding session cookies over http. I guess they're waiting for a high-profile case to happen. I've had this happen around 2009 on a different site to my admin account, so that was the lesson for me.
Session hijacking is not related to HTTPS/SSL directly. SSL prevents the transmitted data from being altered, which cloud be a session among many things. Often sessions are bound to an network address so they are only accepted by the backend on specific connections.
If you ask why the boards are not tunneled securely by default then post a similar question on meta.
-
3Which could* be a session. It also allows the session ID to be intercepted and copied, not just altered. In practice, it's fairly unlikely (except on open wireless networks), but not impossible. Jan 18, 2016 at 20:12
-
1"Often sessions are bound to an network address so they are only accepted by the backend on specific connections." False and false. I'll dissect it: "often" sessions are bound to [an IP] this is not true. How annoying is it when you take your laptop home and you have to re-login on every site because your IP changed? This rarely happens unless it's your bank. Secondly: so they are only accepted [from this IP] you can spoof an IP address by brute forcing the ack number which is only 32 bits.– LucJan 23, 2016 at 1:18