598702 - Escaping Needed to Prevent Stored XSS via Django's CSRF Token

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Add-on Builder, defect)

Description

[Michael Coates [:mcoates] (acct no longer active)]

This issue has been addressed in many Mozilla sites. A patch is already available at mozilla and a patch has been issued by django (see link below)

Issue

Django's CSRF defense contains a flaw which allows cross site scripting attacks via the CSRF cookie.  This issue is being tracked by django here: http://code.djangoproject.com/ticket/14032. 

This attack could be launched from a subdomain or from a man in the middle attack via cookie forcing. This would allow an attacker to inject a stored XSS attack within the victim's browser. The XSS would fire anytime the victim visits a form using DJANGO's csrf controls within a valid domain for the infected cookie. 


Recommended Resolution

This is a publicly disclosed XSS vulnerability and will need to be resolved on our end as soon as possible. The recommended solution is to modify all uses of django's CSRF defense and remove the "safe" flag. This will ensure that DJANGO safely displays the CSRF token within the HTTP response.  

Note: The attacker does not need access to the django components in order to launch this attack. Once the victim's cookie is infected the attack will launch whenever the victim access the page. Therefore, restricted pages, such as those protected by LDAP auth, or equally vulnerable to attack.

Comment 1

[Piotr Zalewa [:zalun]]

This looks like it's fixed in Django itself

Comment 2

[Wil Clouser [:clouserw]]

(In reply to comment #1)
> This looks like it's fixed in Django itself

Flightdeck isn't running off Django trunk - you're saying this is fixed in our version?  mcoates, can you retest?

Comment 3

[Piotr Zalewa [:zalun]]

safe_csrf_token created and used on login page.
Do you think it would be enough to repeat this for every template using csrf?

https://github.com/mozilla/FlightDeck/commit/95466af1b5b67a2fe7c039f718e0174d1a11b441

Comment 4

[Wil Clouser [:clouserw]]

If you can just override csrf_token there won't be mistakes when people don't know about the new version, and when django is upgraded, it will continue to work for free

Comment 5

[Piotr Zalewa [:zalun]]

I know - but it's a defaulttag - is it simple to do?

Comment 6

[Wil Clouser [:clouserw]]

I assume if you load it further down the line than django's helpers it will work fine, but I don't know.  I haven't done much with the built-in templating.

Comment 7

[Piotr Zalewa [:zalun]]

This is done using safe_scrf tag - we don't use any automated templates - safe
Wil, if you agree - please close the bug

Comment 8

[Michael Coates [:mcoates] (acct no longer active)]

Just tested this, its still vulnerable. Has the fix been pushed?

Steps to reproduce:
Update cookie to following value:
  Cookie: csrftoken="d93f275d7'><script>alert(1)</script>";
Browse to 
  https://builder.mozillalabs.com/user/signin/
See alert popup box

Comment 9

[Piotr Zalewa [:zalun]]

builder.mozillalabs.com is still using old version of the site
please check on staging server https://builder-addons.allizom.org or trunk server http://flightdeck.zalewa.info

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I'm going to assume that this bug is no longer valid, and close it.

If I misjudged this, please reopen the bug. :)

Comment 11

[Yvan Boily [:ygjb][:yvan]]

Adding keywords to bugs for metrics, no action required.  Sorry about bugmail spam.