Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#15845 closed Bug (invalid)

CSRF validation leak

Reported by: Jay <jay.shure@…> Owned by: nobody
Component: CSRF Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Russell Keith-Magee)

The CSRF validation compares request.COOKIES[settings.CSRF_COOKIE_NAME] and request.POST.get('csrfmiddlewaretoken', ) to see if a request is legal. But unfortunately both two values are provided by the client side, and they are the same. So it is easy for attackers to fake a request that no 403 will be thrown.

The attached project provides one url entry that returns "ok", unless CSRF fails. Following cmds show how to cheat.

# 200
curl http://127.0.0.1:8000

# 200
curl -G -d test=test http://127.0.0.1:8000

# 403
curl -d test=test http://127.0.0.1:8000

# 200
curl -d "test=test;csrfmiddlewaretoken=1" -b csrftoken=1  http://127.0.0.1:8000

Attachments (1)

csrfleak.tar.bz2 (1018 bytes ) - added by Jay <jay.shure@…> 14 years ago.

Download all attachments as: .zip

Change History (3)

by Jay <jay.shure@…>, 14 years ago

Attachment: csrfleak.tar.bz2 added

comment:1 by Luke Plant, 14 years ago

Resolution: invalid
Status: newclosed

This does not result in a CSRF vulnerability. curl is irrelevant - CSRF is about browsers being abused.

comment:2 by Russell Keith-Magee, 14 years ago

Description: modified (diff)

I would also point out that if you even *suspect* that you have found a security issue with Django, *DO NOT* report it in Trac. Mail security@… instead.

Note: See TracTickets for help on using tickets.
Back to Top