Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 22 commits into
base: main
Choose a base branch
from

Conversation

owen-mc
Copy link
Contributor

@owen-mc owen-mc commented Apr 25, 2025

Promoting this experimental XSS query.

Copy link
Contributor

github-actions bot commented Apr 25, 2025

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"
)

func bad(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"
)

func good(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)
}

@owen-mc owen-mc force-pushed the go/promote/html-template-escaping-bypass-xss branch from 896cf81 to bef38a4 Compare May 1, 2025 15:08
@owen-mc owen-mc marked this pull request as ready for review May 1, 2025 15:10
@owen-mc owen-mc requested a review from a team as a code owner May 1, 2025 15:10
smowton
smowton previously approved these changes May 9, 2025
Copy link
Contributor

@smowton smowton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@owen-mc
Copy link
Contributor Author

owen-mc commented May 13, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants