Comments on: How can you protect yourself from CRIME, BEAST’s successor?

By: Thrawn

Thrawn — Tue, 25 Sep 2012 00:24:06 +0000

There’s a 10-year-old Firefox RFE that could go a long way toward fixing the JavaScript security model:

https://bugzilla.mozilla.org/show_bug.cgi?id=38933

The gist of it is: any time a cross-site request is going to be sent to a site where you have cookies and/or HTTP AUTH, you get a warning dialog, and can choose to strip the cookies/auth from the request, or block it altogether, and remember your decision for next time.

By: Frank Breedijk (Seccubus)

Frank Breedijk (Seccubus) — Fri, 21 Sep 2012 08:46:53 +0000

If you fear the POST request cannot be done, this will also work via a GET request:

GET /fake.jpg?sessionid=abcd HTTP/1.1 etc...

Trigger by: On a malicous site

And you can use javascript on the malicous site to

By: David-Sarah Hopwood

David-Sarah Hopwood — Tue, 11 Sep 2012 20:47:38 +0000

I’m not certain, but I think that SPDY over TLS (http://en.wikipedia.org/wiki/SPDY) may be vulnerable to this attack, even if TLS compression is disabled. SPDY does header compression, and I don’t think it’s necessary to the attack that the compression be at the TLS level. I have not studied the details of how SPDY uses compression contexts, though.

By: Caleb

Caleb — Tue, 11 Sep 2012 10:54:20 +0000

Way to roll Security.SE folks! Great info both on the specifics of current issues but clearly explained in a way that is useful to keep in mind for other scenarios as well.

By: CodesInChaos

CodesInChaos — Tue, 11 Sep 2012 08:59:24 +0000

The annoying thing about this attack is that it's not limited to TLS. It applies in many situations where content from mixed sources is compressed together. So pretty much any protocol that allows chosen plaintext attacks with compression needs to be reviewed.

HTTP compression with XSRF tokens, as bobince already noticed
Possibly SPDY header compression
SSH probably has similar issues

By: Krzysztof Kotowicz

Krzysztof Kotowicz — Tue, 11 Sep 2012 08:35:32 +0000

@xorninja – I improved the algorithm and now it sort of works. Results vary, but usually at least the first 8 characters are detected.

https://gist.github.com/3696912

By: albino

albino — Tue, 11 Sep 2012 07:24:13 +0000

Cross domain posts are perfectly possible.

By: roryalsop

roryalsop — Tue, 11 Sep 2012 07:16:03 +0000

It looks like this assumption is correct – Chromium disabled TLS compression on August 3rd: https://chromiumcodereview.appspot.com/10825183

Also Firefox, Chrome and Safari send ClientHello without advertising compression support – they silently removed it one month ago

Looks like Thomas is spot on with this one!

By: xorninja

xorninja — Tue, 11 Sep 2012 06:34:32 +0000

Hmm I tried this idea, but it didn’t work very well. Some code for those who want to play: http://pastebin.com/qZdNYgfr

Still a nice idea, though!

By: D.W.

D.W. — Tue, 11 Sep 2012 05:11:17 +0000

Can you explain why you expect the POST request cannot be done in real life?

I presume you’re familiar with the fact that any page can trigger a POST (even to some other domain entirely), and have a great deal of control over the contents of the POST body. See, e.g., http://security.stackexchange.com/q/8099/971 and http://security.stackexchange.com/q/19330/971

Therefore, I don’t immediately see anything that would prevent this attack. But maybe you’ve spotted something I’m missing?