URL sanitisation design

Sanitisation only applies to Go expressions, it wouldn't apply to constant attribute values like <a href="javascript: alert('hi!')"> because that's a compile time constant.

Users will need to migrate from using string expressions:

<a href={%= variable %}>

To using a new templ.URL function that applies URL sanitisation, returning a templ.SafeURL type with sanitisation rules applied.

<a href={%= templ.URL(variable) %}>

To bypass sanitisation, it's possible to convert a string directly to the templ.SafeURL type:

<a href={%= templ.SafeURL(s) %}>

This allows for compile time checks, because the Generator will be updated to generate specific code for the href attribute that expects a templ.SafeURL to be returned by the expression.

Notes

The sanitisation will be to check that URLs in variables are relative, or are an approved protocol.

Go's built-in templating language just checks that the URL is relative, or is approved protocol (http, https, mailto): https://github.com/golang/go/blob/2ebe77a2fda1ee9ff6fd9a3e08933ad1ebaea039/src/html/template/url.go#L48

There are some useful tests that describe the sanitisation behaviour at https://golang.org/src/html/template/escape_test.go

Google's safehtml package allows http, https, mailto and ftp, but also data URLs for specific MIME types:
https://github.com/google/safehtml/blob/85ae69c35a0990a1f40f265f0788e0a75be771a1/url.go#L114

I'll do Go's set as a first pass, and might add in support for data URLs later.

Bypass notes

Google's SafeHTML package doesn't allow this sort of bypass, preferring to force a safe API surface, but Angular.js / Hugo etc. provide something similar to a trustAsUrl function https://docs.angularjs.org/api/ng/service/$sce#trustAsUrl which bypasses sanitisation.

Security reviewers can check for the presence of templ.SafeURL in the *.templ files, and ban it via static analysis checks if required, since its only purpose is to skip the approved protocol checks. A check could be added to the templ command tool to enforce this in CI/CD as a future feature.

Example design

package main

import (
	"fmt"
	"strings"
)

func main() {
	safe := URL("/safe")
	unsafe := URL("javascript:alert('hi')")
	bypassedChecks := SafeURL("javascript:alert('used SafeURL to bypass sanitization')")
	fmt.Println(safe)
	fmt.Println(unsafe)
	fmt.Println(bypassedChecks)
}

// I'm British, and use an 's' in 'sanitisation', but I use US English in code to match the Go programming language.
const FailedSanitizationURL = SafeURL("about:invalid#TemplFailedSanitizationURL")

func URL(s string) SafeURL {
	//TODO: Actual checks.
	if strings.HasPrefix(s, "javascript:") {
		return FailedSanitizationURL
	}
	return SafeURL(s)
}

type SafeURL string

Added support for URL sanitisation in: b7cfe4b

I've also added a new CSS capability that applies CSS value sanitisation to all expression-generated values by default (with no option to override, because the sanitisation is sensible).

I don't think it's a good idea to use a templating language to insert variables or expressions into JavaScript or CSS. It would be good to find out more about why people might be doing that and provide alternative examples.

Next steps are to:

• Update the generator to ensure that onClick/on* attributes require a templ.SafeScript instead of a bare string. Using templ.SafeScript(variableOrFunction) means that the developer is telling templ to bypass sanitisation, in the same way that the templ.SafeURL does.
• Update style expression attributes to generate code that expects the Go expression to return a templ.Style instead of a string that's similar to templ.Classes that takes in an array of SafeCSS elements.
• Update the contents of style tags to only allow Go expressions that returntempl.SafeCSS instead of strings.
• Update the contents of script tags to only allow Go expressions that return templ.SafeScript instead of strings.

As a note, React currently allows unsafe strings in href atttributes, so I think templ's behaviour is better than what's commonplace out there for href attributes.

https://jsfiddle.net/adrianhesketh/j2bm149h/1/

This React code renders a link that results in an alert("xss"), with a warning in the console that this behaviour will be changed in a future release.

const Component = ({ userProvidedUrl }) => (
  <div>
    <h3>Secure</h3>
    <a href="https://google.com">Google</a>
    <h3>Insecure</h3>
    <a href={ userProvidedUrl }>Google</a>
  </div>
);

const host = document.querySelector("#app");

const userProvidedUrl = `javascript:alert("xss")`;
ReactDOM.render(<Component userProvidedUrl={ userProvidedUrl }/>, host);

["Warning: A future version of React will block javascript: URLs as a security precaution. Use event handlers instead if you can. If you need to generate unsafe HTML try using dangerouslySetInnerHTML instead. React was passed %s.%s", "\"javascript:alert(\\"xss\\")\"", "
    at a
    at div
    at Component (<anonymous>:4:22)"]

CSS behaviour in React

Unsafe CSS expressions an unsafe are automatically removed, so this code:

const Component = ({ width, backgroundColor }) => (
  <div>
    <div style={{ width: width, backgroundColor: backgroundColor }}>Google</div>
  </div>
);

const host = document.querySelector("#app");

const width = `expression(alert('1337'))`;
const red = "#ff0000";
ReactDOM.render(<Component width={width} backgroundColor={red}/>, host);

Will strip the width CSS property because it contains a dangerous value.

Notes on onClick / on* behaviour in React

React will complain with this code:

const Component = ({ onClick }) => (
  <div>
    <div onClick={ onClick }>Google</div>
  </div>
);

const host = document.querySelector("#app");

const onClick = `alert("css")`;
ReactDOM.render(<Component onClick={onClick} />, host);

The result is:

["Warning: Expected `%s` listener to be a function, instead got a value of `%s` type.%s", "onClick", "string", "
    at div
    at div
    at Component (<anonymous>:4:22)"]

I'm going to close this in favour of smaller tickets now that I've got an idea of what I want to do.

For script related items:

• Update the generator to ensure that onClick/on* attributes require a templ.SafeScript instead of a bare string. Using templ.SafeScript(variableOrFunction) means that the developer is telling templ to bypass sanitisation, in the same way that the templ.SafeURL does.
• Update the contents of script tags to only allow Go expressions that return templ.SafeScript instead of strings.

See #23

• Update style expression attributes to generate code that expects the Go expression to return a templ.Style instead of a string that's similar to templ.Classes that takes in an array of SafeCSS elements.
• Update the contents of style tags to only allow Go expressions that returntempl.SafeCSS instead of strings.

See #24