#34514 closed Bug (invalid)
`firstof` and `cycle` tags do not escapes variables defined in `wth` tag
Reported by: | Алексей Поклонский | Owned by: | nobody |
---|---|---|---|
Component: | Template system | Version: | 4.0 |
Severity: | Normal | Keywords: | firstof, with, templates |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
django version: 4.0.1
Template snippet example:
{% with var0="<script>alert('XSS');</script>" var1="12" %} {% firstof var0 "123" var1 %} {% endwith %}
Renders with:
def index(request): return render(request, 'polls/index.html')
Rendered result is:
<script>alert('XSS');</script>
Expected output is:
<script>alert('XSS');</script>
In docs you noted that firstof
will escape variables, but it does not escape them as you can see. And also it does not escape passed string literals. For example:
{% firstof var1 var2 var3 "<script>alert('XSS');</script>" %}
Will result in the same not escaped html with XSS.
The same problem with the cycle
tag:
{% with var0="<script>alert('XSS');</script>" %} {% for var2 in list_var %} {% cycle var0 "123" %} {% endfor %} {% endwith %}
Where list_var is just a context-defined list variable.
Related #17906
Change History (5)
comment:1 by , 20 months ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
follow-up: 3 comment:2 by , 20 months ago
follow-up: 5 comment:4 by , 20 months ago
Description: | modified (diff) |
---|---|
Summary: | `firstof` tag do not escapes variables defined in `wth` tag → `firstof` and `cycle` tags do not escapes variables defined in `wth` tag |
The same problem with the cycle
tag.
comment:5 by , 20 months ago
Replying to Алексей Поклонский:
The same problem with the
cycle
tag.
As before, this is not an issue, but a documented and expected behavior.
All string literals defined on templates are consider safe. If you can define string literals on templates you can put whatever you want and you don't need XSS vulnerabilities. Therefore, there is no value to auto-escaping them.
For the future, report security issues in private by emailing security@… not via the public issue tracker, see docs.