CSRF protection bypass due to Google analytics and weird server cookie parsing

[saurik]

It might be interesting to some people that the "peculiarity" noted in some web servers is actually requested by the standard. It is noted in both the grammar and in the text (where it is described as for "future compatibility").

> cookie = "Cookie:" cookie-version 1*((";" | ",") cookie-value)

> Note: For backward compatibility, the separator in the Cookie header is semi-colon (;) everywhere. A server should also accept comma (,) as the separator between cookie-values for future compatibility.

https://www.ietf.org/rfc/rfc2109.txt

(I believe part of the issue was that MIME of headers describes how to deal with multiple headers with the same name, which is by concatenating them with commas, and that spec was the basis for the definition of HTTP headers.)

[ademarre]

If I understand it correctly, the CSRF protection bypass is just an interesting consequence of the real culprit, which is an injection vulnerability in the data serialization format of the GA __utmz cookie.

[Syrup-tan]

I wonder which party should pay the bounty in this case. He seems to have reported it to Twitter, however wouldn't it be Google's responsibility to fix this?

Seeing as how it's a combination of an issue in the web server parsing cookies, and the client setting malicious cookies, I'm not sure which party should be responsible for the bounty.

[brlewis]

They should both pay a bounty. But if you had to assign blame only one place it would be ECMAscript. Setting the value of an unintended cookie should not be so easy to do by accident.

[BlackFan]

Hi, i am the author of this report.

I sent information about this vulnerability to: 1) Google (2 fix in Google Analytics) 2) Django / Python (https://hg.python.org/cpython/rev/270f61ec1157) 3) Twitter (changed CSRF protection) 4) Instagram [Facebook] (sent me to Django)

[nosir33]

You are visiting this page because we detected an unsupported browser. Your browser does not support security features that we require. We highly recommend that you update your browser. If you believe you have arrived here in error, please contact us. Be sure to include your browser version.

[userbinator]

I encounter those types of messages a lot due to my unusual and changing user-agent. My usual response is to click the back button since I can usually find the information on another site.

[Buge]

What browser are you using?

[Osiris]

This vulnerability would appear to be mitigated by using a CSRF secret in a server-side session rather than solely cookie based.

For example, Cookie: SHA1(salt + secret), then CSRF-TOKEN header/value is taken, the salt extracted, hashed against the server-side secret and compared.

[amenghra]

Solely cookie based CSRF is the only way to do logged-out csrf. Once you are logged-in, you want to do session based to prevent a MITM-over-http from doing a CSRF on the https connection.

HSTS partially prevents the MITM-over-http, but not 100% the person doing the MITM potentially controls the clock (NTP is unauthenticated). Unless you do HSTS by whitelisting the domain in the browser.

Security is hard :(

[xrstf]

What's the advantage of still having the cookie with some value in it when we use a random token as a hidden form value plus this token being stored on the server? Your suggestion seems overly complex to me, so maybe I'm missing an attack vector that can be mitigated by throwing salts, hashing and a cookie at the issue.

[welder]

The comments mention this is also a problem with Django's CSRF cookie when using GA?

[marcosdumay]

The default Django CSRF protection is based on a hidden field, not cookies. Thus, the default mechanism does not have this flaw.

One can always replace it with something that is vulnerable, so there are probably Django sites out there with this problem. But if you never thought deeply about it, your site is fine... What's a feature that I really love about Django, you'll see that same same phrase "if you never thought deeply about it, your site is fine" for lots and lots of security problems.

What I don't get is how is it possible to do CSRF with cookies? Aren't cookies always shared between simultaneous browsers sessions? Isn't the entire point of CSRF to avoid that?

[3pt14159]

So if I understand this correctly, people that use ad blockers that include the blocking of Google Analytics have been safe from this attack vector for months, while others have not, correct?

[towelguy]

And people who use NoScript are safe from of any kind of javascript attack vectors.

[brlewis]

This is hard to exploit if the CSRF token is a few characters from the cookie that identifies the user. Setting a new value for the cookie would log the user out.

[Animats]

Due to a security risk, until further notice all corporate firewalls should be blocking Google Analytics.

[Someone1234]

A lot of sites break if Google Analytics is blocked (on purpose).

[lfottaviano]

Interesting point of view