Go: promote html-template-escaping-bypass-xss

[owen-mc]

Promoting this experimental XSS query.

[github-actions]

QHelp previews:

go/ql/src/Security/CWE-079/HtmlTemplateEscapingBypassXss.qhelp

Cross-site scripting via HTML template escaping bypass

In Go, the html/template package has a few special types (HTML, HTMLAttr, JS, JSStr, CSS, Srcset, and URL) that allow values to be rendered as-is in the template, avoiding the escaping that all the other strings go through.

Using them on user-provided values allows for a cross-site scripting vulnerability.

Recommendation

Make sure to never use those types on untrusted content.

Example

In the first example you can see the special types and how they are used in a template:

package main
import (
"html/template""net/http"
)
funcbad(w http.ResponseWriter, r*http.Request) {
r.ParseForm()
username:=r.Form.Get("username")
tmpl, _:=template.New("test").Parse(`<b>Hi {{.}}</b>`)
tmpl.Execute(w, template.HTML(username))
}

To avoid XSS, all user input should be a normal string type.

package main
import (
"html/template""net/http"
)
funcgood(w http.ResponseWriter, r*http.Request) {
r.ParseForm()
username:=r.Form.Get("username")
tmpl, _:=template.New("test").Parse(`<b>Hi {{.}}</b>`)
tmpl.Execute(w, username)
}

[smowton]

Looks plausible if QA shows good results in practice; minor optional wording quibbles.

[owen-mc]

MRVA only found two repos with results (and one is deliberately vulnerable). I've started DCA on those repos. I also ran the query locally on the one which isn't deliberately vulnerable and looked at the tuple counts. They seemed fine - no predicate took longer than 361ms, and none of the slowest predicates seem related to this query.

[smowton]

Results sound good

[owen-mc]

I have checked autofix results and they are good enough. Ideally the alert message would contain a link to the step where the type conversion happens, but I do not think this is easy to do with the shared data flow library.