Closed Bug 1141153 Opened 9 years ago Closed 9 years ago

Django 1.7.6 released (Input)

Categories

(Input :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: willkg, Assigned: willkg)

Details

(Whiteboard: u=dev c=security p=1 s=input.2015q1)

On Monday, March 9th, 2015, the Django project issued a set  of releases to remedy security issues reported. This bug contains descriptions of the issues.

Please read the entirety of this bug. Then either:

1. apply the update and mark this bug as FIXED, or

2. verify this doesn't apply to your project and close this bug with a WONTFIX plus an explanation of why these don't apply to your project


From https://www.djangoproject.com/weblog/2015/mar/09/security-releases/

"""
Issue: XSS attack via properties in ModelAdmin.readonly_fields
==============================================================

The ModelAdmin.readonly_fields attribute in the Django admin allows displaying model fields and model attributes. While the former were correctly escaped, the latter were not. Thus untrusted content could be injected into the admin, presenting an exploitation vector for XSS attacks.

In this vulnerability, every model attribute used in readonly_fields that is not an actual model field (e.g. a @property) will fail to be escaped even if that attribute is not marked as safe. In this release, autoescaping is now correctly applied.

This issue has been assigned the identifier CVE-2015-2241.


Advisory: HTML escaping when calling template filters from Python code
======================================================================

The vulnerability described above was caused by the admin's use of the linebreaksbr function which doesn't escape its output by default when used outside of a template.

This same behavior is present in other functions from django.template.defaultfilters that output HTML:

    join
    linebreaksbr
    linebreaks_filter
    linenumbers
    unordered_list
    urlize
    urlizetrunc

In versions older than 1.8b2, they use autoescape=None as a default argument. This means when calling these functions directly from Python code, the input would be marked safe, but is not actually escaped, creating an XSS attack vector.

We've remedied this issue in 1.8b2+ by changing the default value of this option to True. This ensures a safe behavior by default and helps prevent similar cases in the future. In addition, the documentation for writing custom template filters has been updated to recommend True as the default value.

The change of the default parameter in 1.8 may create a compatibility issue for some users, but we feel it's important to use safe defaults. If escaping is not desired for your calls of these functions, you can revert to the old behavior by passing autoescape=False.

Users of Django versions 1.0 to 1.7 should check their code for Python calls to these filters and ensure that any usage either explicitly sets autoescape=True or passes only trusted content.

This issue only affects these template filters when they are called directly from Python code and not when they are used in templates.
Affected versions

    Django master development branch (currently at pre-alpha status)
    Django 1.8 (currently at beta status)
    Django 1.7
"""
In a PR: https://github.com/mozilla/fjord/pull/520
Assignee: nobody → willkg
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: u=dev c=security p= s=input.2015q1
https://github.com/mozilla/fjord/commit/cc75befe6d9c4f4cd2a74102093f360a8a7ea42e

Pushed to prod just now. Marking as FIXED.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: u=dev c=security p= s=input.2015q1 → u=dev c=security p=1 s=input.2015q1
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.