Am I correct that it is still safe to have compression enabled for static files? Assuming you're not sending secrets inside CSS or JS files?
http://wiki.nginx.org/HttpGzipModule says that the gzip on directive can be set in location. On Tuesday, 6 August 2013 17:58:42 UTC+1, Donald Stufft wrote: > > > On Aug 6, 2013, at 12:45 PM, Rob Yates <[email protected] <javascript:>> > wrote: > > This is a fascinating attack. I scanned all of the information that I > could find and it wasn't clear how this could be used to breach CSRF > protection. Is there more detail somewhere on that specific attack vector? > > > > > Essentially if you have a string "abcd" which represents your CSRF token > in the body, compression will make it so that if you add the string "fghe" > to the output the size of the response will be larger than if you added the > string "abcd" to the output (because of compression). It's somewhat harder > to attack than that because it also requires an "anchor". In terms of CSRF > this likely requires an XSS as well (if your csrf token always has > csrf_token=" in front of it you can use that as your anchor, but html > escaping would escape it). > > Anchoring is a lot simpler for other secrets which are displayed to the > user, for instance if you're trying to steal a credit card number which > appears on the site as "Credit Card: 1234", then "Credit Card: " could be > your anchor, so you'd just need a way to influence the output of the page > so that you can add "Credit Card: NNNN" to try various combinations until > you find one that doesn't increase the size of the response. > > > -Rob > > On Tuesday, August 6, 2013 10:42:01 AM UTC-4, Jacob Kaplan-Moss wrote: >> >> Hi folks -- >> >> At last week's Black Hat conference, researchers announced the BREACH >> attack (http://breachattack.com/), a new attack on web apps that can >> recover data even when secured with SSL connections. Given what we know so >> far, we believe that BREACH may be used to compromise Django's CSRF >> protection. Thus, we're issuing a security advisory so that our users can >> defend themselves. >> >> You can read more details, including how the steps you can take to >> prevent yourself against this attack, on our blog: >> >> https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/ >> >> We plan to take steps to address BREACH in Django itself, but in the >> meantime we recommend that all users of Django understand this >> vulnerability and take action if appropriate. >> >> Jacob >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected]<javascript:> > . > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
