html/template: URL path/fragment component not properly escaped

[stjj89]

Given the following two templates:

<a href="http://www.foo.com/bar?{{.}}">link</a>
<a href="http://www.foo.com/bar%3F{{.}}">link</a>

When . is "hello#param1=value1&param2=value2", the templates produce the following HTML output:

<a href="http://www.foo.com/bar?hello%23param1%3dvalue1%26param2%3dvalue2">link</a>
<a href="http://www.foo.com/bar%3Fhello#param1=value1&amp;param2=value2">link</a>

Example at https://play.golang.org/p/pbdV0f9DdE.

Notice that the interpolated fragment separator #, and the & sub-delimiter is escaped (via percent-encoding) in the first template, but not the second, despite the fact that both URLs are equivalent (%3F is the percent encoding of ?). This allows parameters and fragments to be injected into the URL in the second template.

The problem is that the state machine only transitions into the URL query/frag component state when the # or ? rune is found. It does not account for their percent-encoded equivalents.

The fix for this is simple, but it would break users by changing html/template's URL-escaping behavior. I'm not sure if such a change would be worth it.

[stjj89]

@mikesamuel

[tv42]

Are the URLs really equivalent? I would not expect %3F to behave like the unquoted question mark -- how else would you quote a question mark that is part of the URL path?

Consider:

• https://github.com/golang/go/issues?q=foobar does a search
• https://github.com/golang/go/issues%3Fq=foobar gives 404

As far as I understand, /bar?{{.}} will quote as query, /bar%3F{{.}} will quote as URL path.

[ghost]

@tv42 Yes, looks like they aren't equivalent.

node.js:

let url = require('url');
console.log(url.parse('http://www.foo.com/bar?x=y').pathname);
console.log(url.parse('http://www.foo.com/bar%3Fx=y').pathname);

Output:

/bar
/bar%3Fx=y

[stjj89]

@tv42 @opennota Thanks for pointing that out. I once again confused myself over how percent-encoded and HTML-escaped characters get interpreted by the browser.

My concern should have been if ? in <a href="http://www.foo.com/bar&#63;{{.}}">link</a> is properly un-escaped into ?, and interpreted by the URL parser. As it turns out, it is, and the action after the HTML-escaped question mark gets query-escaped properly.