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

VERIFIED FIXED in 2.2.5

Status

support.mozilla.org
Code Quality
--
blocker
VERIFIED FIXED
7 years ago
2 years ago

People

(Reporter: mcoates, Assigned: jsocol)

Tracking

({wsec-xss})

unspecified
2.2.5
wsec-xss

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [infrasec:xss])

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.
(Assignee)

Comment 1

7 years ago
We probably need to apply the patch from bug 591002 to the production servers, since this is not a bug in our code. (See bug 591002 comment 2. Unless we can do what Jeff suggests or find another solution.)
Component: General → Code Quality
QA Contact: general → code-quality
Target Milestone: --- → 2.2.4
(Assignee)

Comment 2

7 years ago
Jeremy, what would be a good way to deploy the patch in attachment 470528 [details] [diff] [review]?
(Assignee)

Comment 3

7 years ago
Make that attachment 470535 [details] [diff] [review].
This missed 2.2.4, right?
(Assignee)

Comment 5

7 years ago
(In reply to comment #4)
> This missed 2.2.4, right?

Yes, the patch was waiting on review and doesn't apply directly to our code, anyway: it's a patch to Django. We can theoretically apply this whenever.
(Assignee)

Comment 6

7 years ago
(In reply to comment #5)
> it's a patch to Django. We can theoretically apply this whenever.

Dead wrong. I misunderstood jbalogh's last patch on bug 591002. I will see if this applies cleanly to kitsune (it should, or close).
Assignee: nobody → james
Target Milestone: 2.2.4 → 2.2.5
(Assignee)

Comment 7

7 years ago
Had to tweak Jeff's patch a bit. I didn't add nuggets to our dependencies yet so this can be cherry-picked onto production.

http://github.com/jsocol/kitsune/commit/b448c414a23 (master)
http://github.com/jsocol/kitsune/commit/7174afb4a2e (2.2.x)

As soon as it's verified on http://support-stage.mozilla.org/questions (or another Kitsune-served page) I'll file a bug to cherry-pick the patch onto prod.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Updated

7 years ago
Depends on: 591002
Rebecca/Michael, have we taken a look at this, yet?
Nope, I reviewd the patch for another site and the patch itself looks good. But it still needs to be verified for SUMO
Verified with the help of stephend, and mcoates
Status: RESOLVED → VERIFIED
Depends on: 593508
No longer depends on: 593508
Adding keywords to bugs for metrics, no action required.  Sorry about bugmail spam.
Keywords: wsec-xss
These bugs are all resolved, so I'm removing the security flag from them.
Group: websites-security
You need to log in before you can comment on or make changes to this bug.