Code

Changes between Version 2 and Version 3 of AutoEscaping


Ignore:
Timestamp:
01/16/07 12:51:11 (7 years ago)
Author:
Gary Wilson <gary.wilson@…>
Comment:

Fixed heading levels.

Legend:

Unmodified
Added
Removed
Modified
  • AutoEscaping

    v2 v3  
     1= AutoEscaping proposal = 
     2 
    13See also: [wiki:"AutoEscape alternative" Autoescape alternative] 
    2  
    3 == AutoEscaping proposal == 
    44 
    55[http://en.wikipedia.org/wiki/Cross-site_scripting XSS vulnerabilities] are the most common form of security hole in web applications by an order of magnitude. In Django, they are avoided using the `escape` template filter - but it is easy to forget to use this, and just one mistake makes an application vulnerable. 
     
    99Here is a proposed design, based on extensive discussion on the mailing lists. 
    1010 
    11 === Auto escaping === 
     11== Auto escaping == 
    1212 
    1313Consider a variable `name` passed from the URL, which contains the following  string: 
     
    3939You will also be able to set a flag on the context, as explained below. 
    4040 
    41 === Escaped v.s. non-escaped strings === 
     41== Escaped v.s. non-escaped strings == 
    4242 
    4343A major risk with auto escaping is that things will end up being double escaped. What if the user were already using a filter somewhere along the line that causes HTML to be escaped? The solution is to introduce two types of string: escaped and non-escaped. 
     
    7171This allows us to use them to mark strings that have already been escaped. The auto escape mechanism can then use this marker to decide if something should be escaped or not. This has a number of uses. Firstly, filters that convert a value in to HTML (such as `urlize` and `markdown`) can flag it as already being escaped (maybe escape is the wrong term - 'safe' might be better) so that the auto escape mechanism knows not to escape the output. Secondly, model fields that are known to contain safe HTML can likewise be marked. Thirdly, the existing 'escape' filter can use this, preserving backwards compatibility for templates written before the introduction of auto escaping. 
    7272 
    73 === Implementation === 
     73== Implementation == 
    7474 
    7575I propose adding a new property to the `Context` class, called `autoescape`. This defaults to being set to `True`, but can be toggled either in view functions or by `{% autoescape off %}` blocks in templates. The `VariableNode` render() method then uses this context flag to decide if escaping should be performed or not: 
     
    114114}}} 
    115115 
    116 === Additional work === 
     116== Additional work == 
    117117 
    118118A bunch more work needs to be done to implement this change (probably in a branch), including the following: 
     
    123123 * Extensive documentation 
    124124 
    125 === Prior discussion === 
     125== Prior discussion == 
    126126 
    127127 * [http://groups.google.com/group/django-developers/browse_thread/thread/17d1dfecd67864ab/2d177ac262232b73 Proposal: default escaping] on django-developers