html/template: predefined HTML escaper does not properly escape user input

[stjj89]

version: go version devel +4cce27a3fa Sat Jan 21 03:20:55 2017 +0000 linux/amd64
env: linux amd64

When we have

.X = `haha onclick=evil()`,

The following template

<a title={{.X}}>

evaluates to

<a title=haha&#32;onclick&#61;evil()>

which is properly escaped. However, the following template:

<a title={{.X | html}}>

evaluates to

<a title=haha onclick=evil()>

which is improperly escaped, and insecure.

This is happening because the html/template escaper considers the predefined global html function equivalent to its internal _html_template_nospaceescaper escaping directive. Since the former is already present in the pipeline, it does not insert the latter to prevent over-escaping (see original commit of this behavior here). However, the above example shows that these two escaping functions are not equivalent.

We should thoroughly re-evaluate the equivalency of predefined global escapers to internal escapers, or get rid of this logic entirely. If we go with the latter option, we could consider removing all user-supplied escapers before adding internal escaper directives, in order to prevent over-escaping.

See related issue 19336 for another security issue related to this equivalent-escapers logic.

[mikesamuel]

nice catch!

We should thoroughly re-evaluate the equivalency of predefined global escapers
to internal escapers

or get rid of this logic entirely. If we go with the latter option, we could consider
removing all user-supplied escapers before adding internal escaper directives,
in order to prevent over-escaping.

So

<a title={{.X | html}}>

would become

<a title={{.X | htmlAttrNospace}}>

it seems that removing equivalents and upgrading sounds fine.

I'm a little leery of this in one instance

<iframe srcdoc="{{.X | html | htmlAttr}}">

is semantically quite different from

<iframe srcdoc="{{.X | htmlAttr}}">

but perhaps that's just a weakness in how we handle

<iframe srcdoc="{{.X}}">

[stjj89]

I'm a little leery of this in one instance

<iframe srcdoc="{{.X | html | htmlAttr}}">

is semantically quite different from

<iframe srcdoc="{{.X | htmlAttr}}">

If I understand correctly, and htmlAttr refers to the internal _html_template_attrescaper directive, then the scenario you highlighted won't ever occur. _html_template_attrescaper is hidden from the user, so the user can only call html. In my proposed solution, both

<iframe srcdoc="{{.X | html}}">

and

<iframe srcdoc="{{.X}}">

will be rewritten to

<iframe srcdoc="{{.X | _html_template_attrescaper}}">

where in the former case, we remove the html directive before adding _html_template_attrescaper.

[gopherbot]

CL https://golang.org/cl/37880 mentions this issue.

[bradfitz]

To @rsc for review.

[stjj89]

This is no longer an issue now that golang.org/cl/37880 has landed.

[stjj89]

I took a closer look at this, and determined that html and _html_template_nospaceescaper are unsafe to use interchangeably, since the former function does not escape whitespace, which is significant in the unquoted-attribute-value context that it is used in.

The rest of the functions in the equivEscapers should be safe to use interchangeably.

[gopherbot]

CL https://golang.org/cl/40936 mentions this issue.