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 <ryat...@gmail.com <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 django-develop...@googlegroups.com <javascript:>. > To post to this group, send email to django-d...@googlegroups.com<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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
