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 javasc
>
> 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 a
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 you can't show user con
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 a
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
req
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 retrie
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 receivi
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 in
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 users of Django under
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 loc
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 wro
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
s
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?
Essentially if you hav
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 and take
> action if a
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:
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
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
prot
17 matches
Mail list logo