Changes between Version 2 and Version 3 of AutoEscaping
- Timestamp:
- Jan 16, 2007, 2:51:11 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AutoEscaping
v2 v3 1 = AutoEscaping proposal = 2 1 3 See also: [wiki:"AutoEscape alternative" Autoescape alternative] 2 3 == AutoEscaping proposal ==4 4 5 5 [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. … … 9 9 Here is a proposed design, based on extensive discussion on the mailing lists. 10 10 11 == = Auto escaping ===11 == Auto escaping == 12 12 13 13 Consider a variable `name` passed from the URL, which contains the following string: … … 39 39 You will also be able to set a flag on the context, as explained below. 40 40 41 == = Escaped v.s. non-escaped strings ===41 == Escaped v.s. non-escaped strings == 42 42 43 43 A 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. … … 71 71 This 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. 72 72 73 == = Implementation ===73 == Implementation == 74 74 75 75 I 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: … … 114 114 }}} 115 115 116 == = Additional work ===116 == Additional work == 117 117 118 118 A bunch more work needs to be done to implement this change (probably in a branch), including the following: … … 123 123 * Extensive documentation 124 124 125 == = Prior discussion ===125 == Prior discussion == 126 126 127 127 * [http://groups.google.com/group/django-developers/browse_thread/thread/17d1dfecd67864ab/2d177ac262232b73 Proposal: default escaping] on django-developers