Core flaw of Cookies

http://homakov.blogspot.com.es/2013/07/core-flaw-of-cookies.html

by homakov • 13 years ago

36 22 13 years ago

homakov.blogspot.com.es

Jackim• 13 years ago

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

kenton• 13 years 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

amitamb• 13 years 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.

homakov8• 13 years ago

Furthermore they will be sent to https but where set on http hacked page. Most of website don't implement protection from forcing

derefr3• 13 years ago

The "port" thing. This is not a solved problem yet. If someone owned a ToDo-App at https://site.com:4567 he will get all the cookies for 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.

homakov8• 13 years 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

derefr3• 13 years 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, you need to keep mutually-untrustworthy services on separate domains anyway.

ef42• 13 years ago

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

homakov8• 13 years ago

Not true, two pretty different techniques. Forcing is about dropping HTTP cookies to https using mitm Fixation is session riding

ef42• 13 years 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.

dlitz• 13 years 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/, which includes blogspot.com and *.uk, but not github.com.

toast0• 13 years 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.

homakov8• 13 years 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• 13 years ago

»Obviously, cookies is the only adequate way to authenticate users.«

What's wrong with HTTP Authentication?

CiaranMcNulty• 13 years 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.

homakov8• 13 years ago

UI is not flexible

Core flaw of Cookies

Related Stories