

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

======
derefr
> 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
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
> 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
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.

~~~
derefr
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.

~~~
saurik
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.

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

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

~~~
ef4
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
Yes mitigation is identical

------
dlitz
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.

~~~
homakov
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)

------
kenton
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
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
Furthermore they will be sent to https but where set on http hacked page. Most
of website don't implement protection from forcing

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

What's wrong with HTTP Authentication?

~~~
CiaranMcNulty
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
UI is not flexible

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

