5 ms·

Core flaw of Cookies

36 points by homakov 13y ago

Jackim 13y ago
I won't lie, I was hoping this would be an analytical look at a flaw in cookies, the tasty treat.
- deleted 13y ago
  [deleted]
kenton 13y ago
Not quite seeing the problem when you can use the secure flag to enable it on only https http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly
- amitamb 13y ago
  I haven't tested it fully but what if https is running on different port i.e. 443 (It is possible.) I believe marking cookie secure will only save you from MITM attack, not from attacks where ports are shared in a domain. i.e. cookies will be sent over https only but to a compromised port.
  - homakov 13y ago
    Furthermore they will be sent to https but where set on http hacked page. Most of website don't implement protection from forcing
derefr 13y ago
> The "port" thing. This is not a solved problem yet. If someone owned a ToDo-App at https://site.com:4567 https://site.com:4567 he will get all the cookies for https://site.com https://site.com with every request. Yes, "httpOnly;". Yes, "Secure;" too. Cookies just don't care about ports. Notionally, the domain is supposed to identify the extent of a security sandbox. This is why CAs sign an SSL/TLS cert for a domain. The port and protocol, on the other hand, are just supposed to indicate services provided by programs running within that security sandbox.[1] Since they're within the same sandbox, they can likely talk to (or more importantly, exploit) one-another. So there's no reason to send your cookie to example.com:80 but not example.com:8080. Presuming standard old-school UNIX SysV daemons running on the same machine (which is, of course, what the W3C and IETF assumed when they dreampt all this up), if one daemon can grab your cookie and stuff it in a session database, then another daemon can just read it back out of that same database. The fact that within the last 20 years we've switched to protecting processes from one-another by creating separate users for each service -- and within the last 10, with things like OpenVZ containers [or now LXC, or earlier BSD jails] -- doesn't change the fact that "ports on the same domain" still translate semantically to "services running within the same security sandbox, and thus presumed mutually trustworthy." If you have services that should be thought of as mutually-untrustworthy running on the same machine (even if it's done in a perfectly safe way!) you should route them through load-balancers or somesuch to translate the different ports into different domains/subdomains. Think the subdomains hanging off of Heroku's ".herokuapp.com" domain. On their dyno-node servers, they likely just expose each uploaded user-service on one intranet-public port--but since you see it through a load-balancer, you see a separate domain (and thus a separate security sandbox!), not a separate port. --- [1] Reminds me a lot of the security sandbox of a single Erlang node/VM. Every service running within a single node can send messages to, or kill, any other service--so they'd better all be mutually-trustworthy. It seems that UNIX was conceived with a similar architecture (at least for daemons providing public services; user-started programs are a separate matter), but with a physical machine being the quantum of sandboxing.
- homakov 13y ago
  You just made a really long excuse why domain is a security sandbox and domain+port is not. ALL other wb interactions are relying on Origins. Cookies rely on domains solely, trying to fix http/https shadowing cookies with flags. Instead of treating them as different origins
  - derefr 13y ago
    > ALL other wb interactions are relying on Origins. No; the very first line of my reply was the most important. SSL/TLS rely on domain, not domain+port. If two mutually-untrustworthy services both need to be carried over SSL/TLS, you need to put them on separate domains, full-stop. If your services aren't using SSL/TLS, that should be your first concern, not cookie origins; it doesn't matter what ports your service is running on if someone has MITMed your machine and put Mark's Malevolent Service on Alice's Allocated Port. Once both services are using SSL/TLS, they literally won't work any more (because you need two separate CA-signed certs) until you move one to a separate domain. Once you've done that, the "port" part of cookie origin is again irrelevant. In short: security boils down to the weakest link in the system. In a web stack, that's SSL/TLS origin identification. It doesn't matter if you "fix" cookies; as long as CAs keep signing certs for example.com instead of for https://example.com:443 https://example.com:443, you need to keep mutually-untrustworthy services on separate domains anyway.
    - saurik 13y ago
      I could totally be wrong here, this is not my space of expertise (I generally do security work at much lower levels), but it is my understand that these "two mutually-untrustworthy services" that are hypothetically on the same SSL domain are only going to be able to share information via cookies, so cookies are the real problem. For all other purposes, they will be considered separate "origins": they will not be able to share local storage, they won't be able to make HTTP requests via JavaScript to each other, they won't be able to view the contents of each other's iframes or images, they won't have access to each other's message ports... in essence, these are totally different websites for every interaction that the browser even considers enforcing a security boundary for... except cookies, where apparently the port doesn't matter? That seems to be the core problem here, and I don't see how your comments about SSL are addressing actual security boundaries.
toodlestech 13y ago
I agree, local storage shouldn't be used but not because it's accessible by the client, because all cookies are accessible client side too. The problems he brings up already have flags that solve them (ie: "http only", "ssl only", etc.). Is the writer just misinformed or am I missing something?
ef4 13y ago
"Cookie forcing" is more commonly called "session fixation". You'll find far more about it if you search under that name.
- homakov 13y ago
  Not true, two pretty different techniques. Forcing is about dropping HTTP cookies to https using mitm Fixation is session riding
  - ef4 13y ago
    I disagree. The point in either case is to get a cookie of the attacker's choosing accepted as the session identifier for the privileged domain. But even if we consider them separate techniques, the mitigation strategy is identical anyway.
    - homakov 13y ago
      Yes mitigation is identical
dlitz 13y ago
That's nothing. Ever wonder why GitHub Pages were moved from username.github.com to username.github.io, citing security concerns, but username.blogspot.com continues to be available? Ever wonder why www.example.co.uk can set cookies on example.co.uk, but not on co.uk? The answer is that browsers ship something called the Public Suffix List: http://publicsuffix.org/list/ http://publicsuffix.org/list/, which includes blogspot.com and *.uk, but not github.com.
- toast0 13y ago
  Blogger blogs are published under blogspot.com, and managed under blogger.com; I'm sure being in the public suffix list may help protect against some abuse, but Blogger (Google) is doing the right thing by keeping user content and administration in different domains.
- homakov 13y ago
  Yeah kinda heard about pages thing. And the other thing is nothing new to me. If you mean how cookies can be set on subdomains while Origins are completely different you are right. One more badly described in standards feature (sorts by path making cookie tossing very easy)
ygra 13y ago
»Obviously, cookies is the only adequate way to authenticate users.« What's wrong with HTTP Authentication?
- CiaranMcNulty 13y ago
  Nothing aside from the UI, really. Well, as long as you're not using Basic auth). If browsers handled HTTP logout nicely, by displaying a prominent logout button somewhere, then developers' jobs would be far easier.
  - homakov 13y ago
    UI is not flexible

36 points by homakov 13y ago

Jackim 13y ago

I won't lie, I was hoping this would be an analytical look at a flaw in cookies, the tasty treat.

deleted 13y ago
[deleted]

kenton 13y ago

Not quite seeing the problem when you can use the secure flag to enable it on only https http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly

amitamb 13y ago
I haven't tested it fully but what if https is running on different port i.e. 443 (It is possible.) I believe marking cookie secure will only save you from MITM attack, not from attacks where ports are shared in a domain. i.e. cookies will be sent over https only but to a compromised port.
- homakov 13y ago
  Furthermore they will be sent to https but where set on http hacked page. Most of website don't implement protection from forcing

derefr 13y ago

> The "port" thing. This is not a solved problem yet. If someone owned a ToDo-App at https://site.com:4567 https://site.com:4567 he will get all the cookies for https://site.com https://site.com with every request. Yes, "httpOnly;". Yes, "Secure;" too. Cookies just don't care about ports. Notionally, the domain is supposed to identify the extent of a security sandbox. This is why CAs sign an SSL/TLS cert for a domain. The port and protocol, on the other hand, are just supposed to indicate services provided by programs running within that security sandbox.[1] Since they're within the same sandbox, they can likely talk to (or more importantly, exploit) one-another. So there's no reason to send your cookie to example.com:80 but not example.com:8080. Presuming standard old-school UNIX SysV daemons running on the same machine (which is, of course, what the W3C and IETF assumed when they dreampt all this up), if one daemon can grab your cookie and stuff it in a session database, then another daemon can just read it back out of that same database. The fact that within the last 20 years we've switched to protecting processes from one-another by creating separate users for each service -- and within the last 10, with things like OpenVZ containers [or now LXC, or earlier BSD jails] -- doesn't change the fact that "ports on the same domain" still translate semantically to "services running within the same security sandbox, and thus presumed mutually trustworthy." If you have services that should be thought of as mutually-untrustworthy running on the same machine (even if it's done in a perfectly safe way!) you should route them through load-balancers or somesuch to translate the different ports into different domains/subdomains. Think the subdomains hanging off of Heroku's ".herokuapp.com" domain. On their dyno-node servers, they likely just expose each uploaded user-service on one intranet-public port--but since you see it through a load-balancer, you see a separate domain (and thus a separate security sandbox!), not a separate port. --- [1] Reminds me a lot of the security sandbox of a single Erlang node/VM. Every service running within a single node can send messages to, or kill, any other service--so they'd better all be mutually-trustworthy. It seems that UNIX was conceived with a similar architecture (at least for daemons providing public services; user-started programs are a separate matter), but with a physical machine being the quantum of sandboxing.

homakov 13y ago
You just made a really long excuse why domain is a security sandbox and domain+port is not. ALL other wb interactions are relying on Origins. Cookies rely on domains solely, trying to fix http/https shadowing cookies with flags. Instead of treating them as different origins
- derefr 13y ago
  > ALL other wb interactions are relying on Origins. No; the very first line of my reply was the most important. SSL/TLS rely on domain, not domain+port. If two mutually-untrustworthy services both need to be carried over SSL/TLS, you need to put them on separate domains, full-stop. If your services aren't using SSL/TLS, that should be your first concern, not cookie origins; it doesn't matter what ports your service is running on if someone has MITMed your machine and put Mark's Malevolent Service on Alice's Allocated Port. Once both services are using SSL/TLS, they literally won't work any more (because you need two separate CA-signed certs) until you move one to a separate domain. Once you've done that, the "port" part of cookie origin is again irrelevant. In short: security boils down to the weakest link in the system. In a web stack, that's SSL/TLS origin identification. It doesn't matter if you "fix" cookies; as long as CAs keep signing certs for example.com instead of for https://example.com:443 https://example.com:443, you need to keep mutually-untrustworthy services on separate domains anyway.
  - saurik 13y ago
    I could totally be wrong here, this is not my space of expertise (I generally do security work at much lower levels), but it is my understand that these "two mutually-untrustworthy services" that are hypothetically on the same SSL domain are only going to be able to share information via cookies, so cookies are the real problem. For all other purposes, they will be considered separate "origins": they will not be able to share local storage, they won't be able to make HTTP requests via JavaScript to each other, they won't be able to view the contents of each other's iframes or images, they won't have access to each other's message ports... in essence, these are totally different websites for every interaction that the browser even considers enforcing a security boundary for... except cookies, where apparently the port doesn't matter? That seems to be the core problem here, and I don't see how your comments about SSL are addressing actual security boundaries.

toodlestech 13y ago

I agree, local storage shouldn't be used but not because it's accessible by the client, because all cookies are accessible client side too. The problems he brings up already have flags that solve them (ie: "http only", "ssl only", etc.). Is the writer just misinformed or am I missing something?

ef4 13y ago

"Cookie forcing" is more commonly called "session fixation". You'll find far more about it if you search under that name.

homakov 13y ago
Not true, two pretty different techniques. Forcing is about dropping HTTP cookies to https using mitm Fixation is session riding
- ef4 13y ago
  I disagree. The point in either case is to get a cookie of the attacker's choosing accepted as the session identifier for the privileged domain. But even if we consider them separate techniques, the mitigation strategy is identical anyway.
  - homakov 13y ago
    Yes mitigation is identical

dlitz 13y ago

That's nothing. Ever wonder why GitHub Pages were moved from username.github.com to username.github.io, citing security concerns, but username.blogspot.com continues to be available? Ever wonder why www.example.co.uk can set cookies on example.co.uk, but not on co.uk? The answer is that browsers ship something called the Public Suffix List: http://publicsuffix.org/list/ http://publicsuffix.org/list/, which includes blogspot.com and *.uk, but not github.com.

toast0 13y ago
Blogger blogs are published under blogspot.com, and managed under blogger.com; I'm sure being in the public suffix list may help protect against some abuse, but Blogger (Google) is doing the right thing by keeping user content and administration in different domains.
homakov 13y ago
Yeah kinda heard about pages thing. And the other thing is nothing new to me. If you mean how cookies can be set on subdomains while Origins are completely different you are right. One more badly described in standards feature (sorts by path making cookie tossing very easy)

ygra 13y ago

»Obviously, cookies is the only adequate way to authenticate users.« What's wrong with HTTP Authentication?

CiaranMcNulty 13y ago
Nothing aside from the UI, really. Well, as long as you're not using Basic auth). If browsers handled HTTP logout nicely, by displaying a prominent logout button somewhere, then developers' jobs would be far easier.
- homakov 13y ago
  UI is not flexible