#34581: Filters should not implicitly mark unsafe strings as safe without
escaping
-------------------------------------+-------------------------------------
Reporter: Shai Berger | Owner:
Type: | omerimzali
Cleanup/optimization | Status: assigned
Component: Template system | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by omerimzali):
Thank you for all clarifications.
For Join filter:
First case: Totally safe inputs the list members and the joiner are safe,
it will be produce safe output. (There's no unsafe input and there no need
to escape in anyway so it doesn't contain any of our conditions)
Second case: When it has any of its inputs (the list members and the
joiner) are safe but also some of the inputs are unsafe, it still needs to
produce safe output.
Third case: All of the inputs are unsafe, it can produce unsafe output.
For Second case, we have 3 conditions to check:
- it needs to produce safe output: For this case yes it needs to produce
safe output because some of the inputs are safe.
- some of its input is unsafe: Yes some of the inputs are not safe,
- the context is such that it should not escape the input: How can we be
sure it should not escape the input? is {% autoescape off %} line enough
to assume this? Could be any other configurations or common behaviours for
some of the filters to not escape the input?
If we check this 3 conditions it should error out.
And for the 3rd case, if all of the inputs are unsafe, it doesn't need to
produce a safe ouput so source doesn't need to error out. Is it correct?
Replying to [comment:7 Shai Berger]:
> Replying to [comment:5 omerimzali]:
> >
> > {{{
> > "I suggest a general rule: A filter which gets unsafe input, should
not escape it, and yet needs to produce safe output, should error out.
This is a hardening, not a security fix, so it should follow a normal
deprecation cycle: The actual change should only happen after the next LTS
release."
> > }}}
> >
> > A filter which gets unsafe input should not escape it. I totally agree
but do we mean it only when autoescape off? {% autoescape off %}
> >
>
> I guess this phrasing was unclear, and I changed it in hope it is
clearer now: The "should not change it" part is not part of "how a filter
should generally behave", but a further condition. A filter for which all
three conditions are true, should error out. "autoescape off" means that
filters, generally, should not escape the input.
>
> > How should I check "All filters which can get unsafe input". I know
Django at least has 4 of them below. What's the right way to find others?
Should this patch contains all of them.
> >
> > {{{
> > join
> > linenumbers,
> > linebreaks,
> > linebreaksbr,
> > }}}
> >
>
> All filters can get unsafe input. Whether the filter actually got safe
or unsafe input is only decided at runtime, and cannot be known in
advance. The interesting question is, "does the filter need to produce
safe output", and this changes from filter to filter: The last three you
listed always need to produce safe output, because they need to include
HTML to break lines; but for some filters, like {{{join}}}, this too is
only decided at runtime -- {{{join}}} needs to produce safe output if (and
only if) any of its inputs (the list members and the joiner) are safe. I
can't think of any way to find which filters are relevant (and when),
except to go over them one by one.
>
> I hope this clarifies the issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/34581#comment:8>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018aebf0ce1d-69e0a5dd-0cdf-4a73-b57f-764f5005f1bb-000000%40eu-central-1.amazonses.com.
