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.
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...), 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?
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.
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.
No, that's not useful. Cookie tossing attacks need not generate their own cookies -- it's just as effective, if not more so, to toss cookies for a session that was generated for another user.
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?
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)
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.
It looks like the fixes they have are messy (sending a header for each element in the path * each cookie key) and even then don't work in all browsers. Better to just not use subdomains for arbitrary hosting.
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.