
Yummy cookies across domains - Killswitch
https://github.com/blog/1466-yummy-cookies-across-domains
======
ultimoo
This is a great article. It is nice that github is comprehensively explaining
how they are protecting user data to reassure their users.

However, this is one of the rare blog posts that go on to educate the reader
about the technical aspects of something (in this case -- cookie attack
vectors) that they can put to use somewhere in their own projects. Unlike a
high level gloating blog post that is meant to inspire awe in the readers
about how awesome company X is doing thing Y.

------
0x0
Very well written blogpost, but it would be nice if they didn't downplay the
severity of the original blog post:

A PoC of how you could clone private repositories, such as the github.com
source code itself at github.com/github/github (as an assumed example)

~~~
homakov
Until the fix everything was possible.

I think they meant "within this few weeks period you could not fixate CSRF
token"

------
samarudge
Would adding a HMAC string to the cookie value not get around this issue? For
example, Tornado has the set_secure_cookie method
([http://www.tornadoweb.org/en/stable/web.html#tornado.web.Req...](http://www.tornadoweb.org/en/stable/web.html#tornado.web.RequestHandler.set_secure_cookie)),
would this not prevent this sort of attack? Even if a script modified the
cookies, they would never (well, hopefully never) be able to generate the
correct HMAC token so the server could just discard the cookies. You'd still
be able to sign a user out but there wouldn't be a security issue (I think).
Anyone smart able to verify/refute?

~~~
X-Istence
You as the attacker can visit the page and get yourself a session cookie that
is valid and set that on the victim's computer...

~~~
samarudge
Would it increase security to include the user-agent, or part of the user-
agent, in the HMAC secret? So the secret was "abc123Mozilla[etc]", that would
then presumably require identical browsers to work, at the expense of logging
everyone out every time their browser updates. Or include all, or part of the
IP address to restrict the network.

~~~
X-Istence
Using the IP address to restrict it would work, since now the attacker would
need to have the same IP address to get a session that will stick, but this
may cause users to be logged out when their ISP changes their IP, or when they
move from home to a coffee shop for instance.

------
magic_haze
Doesn't this issue affect Tumblr (and Blogspot, and Wordpress) as well? They
all allow arbitrary javascript to be injected by the user in a subdomain, so
how are they tackling it?

~~~
arb99
IIRC only the blog front ends are on the blogspot.com domain. All user
logins/blog admin etc are on the blogger.com domain (and no *.blogger.com
domains).

(not used their services for ages, so there might be more overlap than i
remember)

------
cpeterso
It sounds like Rack should fix these cookie vulnerabilities, so users don't
need to rely on middleware workarounds.

~~~
tanoku
These are not vulnerabilities in Rack (necessarily), but in the way the cookie
spec has been drafted and the way Chrome decides to implement it. There's
nothing that can be "fixed" in Rack: the only definitive fix is a domain
migration.

------
samholmes
What sort of malicious things can be accomplished with a cookie tossing
attack?

