Document that escapejs doesn't make template literals safe

[Alvin Lindstam]

The escapejs template tag is used to make arbitrary input strings safe to put in a JavaScript string literal. Since 6ae1b04fb584db0fdb22b8e287784c4ed3ac62ac, it escapes the U+0060 (grave accent) which indicates that it could be used to escape values within JavaScript template strings (which grave accents are used to declare). The ticket that it fixes also states that it is intended to be supposed to be used within template literals (#27900).

escapejs escapes the grave accent, so it will not be able to end the template literal. However, template literals allow embedded expressions which are executed and whose return value is used in the string. The syntax to use such expressions is not escaped.

Whenever escapejs is used to escape a user provided value to a js template literal, an attacker could insert text that will be executed as JavaScript by wrapping it in curly braces with a leading dollar sign, such as ${alert(String.fromCharCode(88) + String.fromCharCode(83) + String.fromCharCode(83))} (which would translate to executing alert("XSS") in the client.

Adding the dollar sign to _js_escapes in ​https://github.com/django/django/blob/d38a3169a426516623929ff8c2b2c9703d801b75/django/utils/html.py#L55-L68 and replacing it with \u0024 would fix the problem but break the case of using template variables to intentionally deliver template literals (non-user provided). Following a report to the security mailing list, the consensus is to document that escapejs shouldn't be used to protect untrusted template literals.

[Tim Graham]

​PR

[GitHub <noreply@…>]

In f229049:

Fixed #29055 -- Doc'd that escapejs doesn't make template literals safe.

[Tim Graham <timograham@…>]

In ed206a9b:

[2.0.x] Fixed #29055 -- Doc'd that escapejs doesn't make template literals safe.

Backport of f229049d6cd186025f4033dc47608b0c9731e882 from master