Re: Security Advisory: BREACH and Django

On 2013-08-08 09:59, Collin Anderson wrote: >> I am doing something a little different with my CSRF tokens, and >> I believe it guards against BREACH. > > Instead of sending the token in the HTTP response, I am using > javascript to read (and generate if needed) the CSRF token cookie. > The

Re: Security Advisory: BREACH and Django

> > I am doing something a little different with my CSRF tokens, and I believe it guards against BREACH. Instead of sending the token in the HTTP response, I am using javascript to read (and generate if needed) the CSRF token cookie. The javascript reads the token from the cookie and adds it

Re: Security Advisory: BREACH and Django

Could you explain why? And why it matters if the user is registered or not? Alternatively, if the token is present and wrong and it's not a POST, reset the token. Thanks On Thu, Aug 8, 2013 at 11:24 AM, Alex Ogier wrote: > That's too hard to enforce. It would mean that

Re: Security Advisory: BREACH and Django

That's too hard to enforce. It would mean that you can't show user content on any public page, or any page that you want to be accessible from outside links. For example, you couldn't show blog comments to unregistered users. It would be too disruptive. Modifying the format of the secret token is

Re: Security Advisory: BREACH and Django

I think they nibble at it. They look at the compressed length - the shorter the compressed length closer they are. But if an incorrect CSRF was never reflected there would be nothing for them to nibble at. It says this in the paper: "However, we remark that requiring a valid CSRF token for all

Re: Security Advisory: BREACH and Django

They don't try to guess the CSRF directly, AIUI. They use a form field to affect their test. The easiest solution I can see is the one mentioned in the document -- instead of outputting the raw value, output SALT || (SALT ^ TOKEN) so the actual value is never in the response, but it can be

Re: Security Advisory: BREACH and Django

How about requiring that if csrfmiddlewaretoken is set, no matter what http method (GET, POST...), it is correct otherwise 403 response. Simon -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop

Re: Security Advisory: BREACH and Django

On 6 Aug 2013, at 12:34 PM, Tim Chase wrote: > On 2013-08-06 12:53, Donald Stufft wrote: >> This incurs the cost that every request to Django invalidates all >> existing CSRF tokens [] OR requires you to store a separate CSRF token >> for each >> request and look up the submitted CSRF token

Re: Security Advisory: BREACH and Django

On 2013-08-06 12:53, Donald Stufft wrote: > On Aug 6, 2013, at 12:16 PM, Tom Scrace wrote: >> On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss >> wrote: >> >> We plan to take steps to address BREACH in Django itself, but in >> the meantime we recommend that all

Re: Security Advisory: BREACH and Django

On Aug 6, 2013, at 1:28 PM, mac...@framestart.com wrote: > 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

Re: Security Advisory: BREACH and Django

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

Re: Security Advisory: BREACH and Django

Since the 1.6 release is very close, what are the chances that the security fix would get backported to Django 1.4.x, even if 1.6 lands before a fix is backported? There was a blog post about extending support for 1.4, but I don't remember seeing any discussion on the list to help "figure out the

Re: Security Advisory: BREACH and Django

On Aug 6, 2013, at 12:45 PM, Rob Yates 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?

Re: Security Advisory: BREACH and Django

On Aug 6, 2013, at 12:16 PM, Tom Scrace wrote: > On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss wrote: > > 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

Re: Security Advisory: BREACH and Django

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? -Rob On Tuesday, August 6, 2013 10:42:01 AM UTC-4, Jacob Kaplan-Moss wrote:

Re: Security Advisory: BREACH and Django

On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss wrote: > > 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. > > Would randomizing the CSRF token on

Security Advisory: BREACH and Django

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