Core flaw of Cookies(homakov.blogspot.com.es)
homakov.blogspot.com.es
Core flaw of Cookies
http://homakov.blogspot.com.es/2013/07/core-flaw-of-cookies.html
24 comments
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
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
> 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, you need to keep mutually-untrustworthy services on separate domains anyway.
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, you need to keep mutually-untrustworthy services on separate domains anyway.
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.
What I'm really saying is, without SSL, site B can MITM site A, and then ports don't matter, because it looks like you're talking to port 80 or whatever the attacker wanted anyway. With SSL, ports don't matter, because you can't run mutually-untrustworthy services on the same domain using SSL. So, with or without SSL, ports don't matter.
Here, let me show my work:
1. All these cross-origin protections the browser uses are basically entirely meaningless without SSL, because you're talking to an unathenticated counterparty. So you've got to assume site A is using SSL+HSTS before a conversation about cross-origin protection even becomes coherent. You've also got to assume that, since site A is using HSTS, site B has to attack it by running SSL as well.
2. Now, with SSL, you can't have two separate sites on the same domain unless they're mutually-trusting, because they would need to share the same cert--and thus both have copies of the private key used to generate that cert. (Unless a CA screwed up and double-issued a cert, that is.) So you have to assume the attacker is now on a separate domain (or using a self-signed cert) for the conversation about cross-origin protection to retain coherency.
3. Disallow connections to sites with self-signed certs. (Browsers already do this.)
4. Do all the cross-origin protection stuff--like not sending cookies--when the domain is different. (Browsers already do this.)
5. You're done, because the previous assumptions simplified the problem.
Your browser's SSL logic, combined with CAs' certificate-signing policies, have effectively protected you from talking to anything running on the same domain as site A, which doesn't also use the cert site A uses. Everything left is either mutually-trustworthy (that is, has access to site A's SSL private key), or has managed to break your SSL stack somewhere--in which case, we're back to the "you're screwed because you're talking to an unauthenticated counterparty" problem.
Here, let me show my work:
1. All these cross-origin protections the browser uses are basically entirely meaningless without SSL, because you're talking to an unathenticated counterparty. So you've got to assume site A is using SSL+HSTS before a conversation about cross-origin protection even becomes coherent. You've also got to assume that, since site A is using HSTS, site B has to attack it by running SSL as well.
2. Now, with SSL, you can't have two separate sites on the same domain unless they're mutually-trusting, because they would need to share the same cert--and thus both have copies of the private key used to generate that cert. (Unless a CA screwed up and double-issued a cert, that is.) So you have to assume the attacker is now on a separate domain (or using a self-signed cert) for the conversation about cross-origin protection to retain coherency.
3. Disallow connections to sites with self-signed certs. (Browsers already do this.)
4. Do all the cross-origin protection stuff--like not sending cookies--when the domain is different. (Browsers already do this.)
5. You're done, because the previous assumptions simplified the problem.
Your browser's SSL logic, combined with CAs' certificate-signing policies, have effectively protected you from talking to anything running on the same domain as site A, which doesn't also use the cert site A uses. Everything left is either mutually-trustworthy (that is, has access to site A's SSL private key), or has managed to break your SSL stack somewhere--in which case, we're back to the "you're screwed because you're talking to an unauthenticated counterparty" problem.
MITM attacks are only possible if you have a privileged location in the network: "the middle". Further, it is easily possible that neither the people operating Site A nor the people operating Site B have access to the SSL certificate for this domain name, as they might be behind a proxy or load balancer operated by the people holding the domain's SSL certificate. You can't just randomly MITM someone else's traffic: you need all the pieces together.
Your assumptions about what is possible in certain hypothetical situations should not cause all security opportunities to be eroded. I mean, seriously: the logical conclusion to your argument is that all non-SSL websites should just share a global pool of insecure cookies, because it isn't like any of it can be considered secure anyway. The people you are protecting yourself from matters: these attacks are different threat models, and are secured separately.
Your assumptions about what is possible in certain hypothetical situations should not cause all security opportunities to be eroded. I mean, seriously: the logical conclusion to your argument is that all non-SSL websites should just share a global pool of insecure cookies, because it isn't like any of it can be considered secure anyway. The people you are protecting yourself from matters: these attacks are different threat models, and are secured separately.
Thanks! This is what I'm talking about
SSL interactions and localStorage - which one looks closer to what cookies do? Ok we can reconsider problem without SSL part. There are two http apps under different ports. If second is hacked it can get httponly cookies of first. Very simple threat.
SSL design is more high level, of course they can not use origins. But it doesn't prove that cookies are ok
SSL design is more high level, of course they can not use origins. But it doesn't prove that cookies are ok
"Cookie forcing" is more commonly called "session fixation". You'll find far more about it if you search under that name.
Not true, two pretty different techniques. Forcing is about dropping HTTP cookies to https using mitm
Fixation is session riding
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/, which includes blogspot.com and *.uk, but not github.com.
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/, which includes blogspot.com and *.uk, but not github.com.
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)
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)
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.
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
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.
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.
Furthermore they will be sent to https but where set on http hacked page. Most of website don't implement protection from forcing
»Obviously, cookies is the only adequate way to authenticate users.«
What's wrong with HTTP Authentication?
What's wrong with HTTP Authentication?
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.
If browsers handled HTTP logout nicely, by displaying a prominent logout button somewhere, then developers' jobs would be far easier.
UI is not flexible
I won't lie, I was hoping this would be an analytical look at a flaw in cookies, the tasty treat.
[deleted]
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.