aboutsummaryrefslogtreecommitdiff
path: root/src/html/template/context.go
AgeCommit message (Collapse)Author
2026-03-05[release-branch.go1.25] html/template: properly escape URLs in meta content ↵Roland Shoemaker
attributes The meta tag can include a content attribute that contains URLs, which we currently don't escape if they are inserted via a template action. This can plausibly lead to XSS vulnerabilities if untrusted data is inserted there, the http-equiv attribute is set to "refresh", and the content attribute contains an action like `url={{.}}`. Track whether we are inside of a meta element, if we are inside of a content attribute, _and_ if the content attribute contains "url=". If all of those are true, then we will apply the same URL escaping that we use elsewhere. Also add a new GODEBUG, htmlmetacontenturlescape, to allow disabling this escaping for cases where this behavior is considered safe. The behavior can be disabled by setting htmlmetacontenturlescape=0. Updates #77954 Fixes #77971 Fixes CVE-2026-27142 Change-Id: I9bbca263be9894688e6ef1e9a8f8d2f4304f5873 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3360 Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3644 Reviewed-by: Damien Neil <dneil@google.com> Commit-Queue: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/752101 Auto-Submit: Gopher Robot <gobot@golang.org> TryBot-Bypass: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-10-16html/template: track brace depth for each nested expressionRoland Shoemaker
We need to track the brace depth for each individual nested expression, since a string interpolation expression may be nested inside of an object. e.g. `${ {1:`${}`}}` has brace depths [1, 0] when inside of the inner ${} expression. When we exit the inner expression, we need to reset to the previous brace depth (1) so that we know that the following } closes the object, but not the outer expression. Note that if you write a broken expression (i.e. `${ { }`) escaping will clearly not work as expected (or depending on your interpretation, since it is broken, it will work as expected). Since the JS parser doesn't catch syntax errors, it's up to the user to write a valid template. Updates #61619 Change-Id: I4c33723d12aff49facdcb1134d9ca82b7a0dffc4 Reviewed-on: https://go-review.googlesource.com/c/go/+/532995 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-10-02html/template: support parsing complex JS template literalsRoland Shoemaker
This change undoes the restrictions added in CL 482079, which added a blanket ban on using actions within JS template literal strings, and adds logic to support actions while properly applies contextual escaping based on the correct context within the literal. Since template literals can contain both normal strings, and nested JS contexts, logic is required to properly track those context switches during parsing. ErrJsTmplLit is deprecated, and the GODEBUG flag jstmpllitinterp no longer does anything. Fixes #61619 Change-Id: I0338cc6f663723267b8f7aaacc55aa28f60906f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/507995 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
2023-09-06html/template: properly handle special tags within the script contextRoland Shoemaker
The HTML specification has incredibly complex rules for how to handle "<!--", "<script", and "</script" when they appear within literals in the script context. Rather than attempting to apply these restrictions (which require a significantly more complex state machine) we apply the workaround suggested in section 4.12.1.3 of the HTML specification [1]. More precisely, when "<!--", "<script", and "</script" appear within literals (strings and regular expressions, ignoring comments since we already elide their content) we replace the "<" with "\x3C". This avoids the unintuitive behavior that using these tags within literals can cause, by simply preventing the rendered content from triggering it. This may break some correct usages of these tags, but on balance is more likely to prevent XSS attacks where users are unknowingly either closing or not closing the script blocks where they think they are. Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this issue. Fixes #62197 Fixes CVE-2023-39319 [1] https://html.spec.whatwg.org/#restrictions-for-contents-of-script-elements Change-Id: Iab57b0532694827e3eddf57a7497ba1fab1746dc Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1976594 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/526157 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2023-09-06html/template: support HTML-like comments in script contextsRoland Shoemaker
Per Appendix B.1.1 of the ECMAScript specification, support HTML-like comments in script contexts. Also per section 12.5, support hashbang comments. This brings our parsing in-line with how browsers treat these comment types. Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this issue. Fixes #62196 Fixes CVE-2023-39318 Change-Id: Id512702c5de3ae46cf648e268cb10e1eb392a181 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1976593 Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/526156 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
2023-04-04html/template: disallow actions in JS template literalsRoland Shoemaker
ECMAScript 6 introduced template literals[0][1] which are delimited with backticks. These need to be escaped in a similar fashion to the delimiters for other string literals. Additionally template literals can contain special syntax for string interpolation. There is no clear way to allow safe insertion of actions within JS template literals, as handling (JS) string interpolation inside of these literals is rather complex. As such we've chosen to simply disallow template actions within these template literals. A new error code is added for this parsing failure case, errJsTmplLit, but it is unexported as it is not backwards compatible with other minor release versions to introduce an API change in a minor release. We will export this code in the next major release. The previous behavior (with the cavet that backticks are now escaped properly) can be re-enabled with GODEBUG=jstmpllitinterp=1. This change subsumes CL471455. Thanks to Sohom Datta, Manipal Institute of Technology, for reporting this issue. Fixes CVE-2023-24538 Fixes #59234 [0] https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-template-literals [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802457 Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Change-Id: Ia221fefdb273bd0f066dffc2abcf2a616801d2f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/482079 TryBot-Bypass: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2022-04-11all: gofmt main repoRuss Cox
[This CL is part of a sequence implementing the proposal #51082. The design doc is at https://go.dev/s/godocfmt-design.] Run the updated gofmt, which reformats doc comments, on the main repository. Vendored files are excluded. For #51082. Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407 Reviewed-on: https://go-review.googlesource.com/c/go/+/384268 Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-09-23html/template, text/template: implement break and continue for range loopsRuss Cox
Break and continue for range loops was accepted as a proposal in June 2017. It was implemented in CL 66410 (Oct 2017) but then rolled back in CL 92155 (Feb 2018) because html/template changes had not been implemented. This CL reimplements break and continue in text/template and then adds support for them in html/template as well. Fixes #20531. Change-Id: I05330482a976f1c078b4b49c2287bd9031bb7616 Reviewed-on: https://go-review.googlesource.com/c/go/+/321491 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2019-06-17html/template: handle nil Error values in context.StringSamuel Tan
Add a special case to print a generic nil error when context.err is nil. Previously, this case was unchecked, leading to a call to (*Error).Error with a nil receiver, which was triggering a nil pointer access. However, this bug was masked by the panic-recovery code in package fmt. I tested this change by running `dlv test` in src/html/template, running the `continue` command, and verifying that no "bad access" errors are returned. Fixes #28854 Change-Id: I0b637b943de003d9efc294f6f1e49b793668d037 Reviewed-on: https://go-review.googlesource.com/c/go/+/181579 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
2018-08-22html/template: use named consts instead of their valuesIskander Sharipov
Use defined named constants instead of 0 literal in comparisons. Found using https://go-critic.github.io/overview.html#namedConst-ref Change-Id: Ic075cece248f6e51db0b3d9d9eaba7d6409c9eef Reviewed-on: https://go-review.googlesource.com/123376 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-06-01all: update comment URLs from HTTP to HTTPS, where possibleTim Cooper
Each URL was manually verified to ensure it did not serve up incorrect content. Change-Id: I4dc846227af95a73ee9a3074d0c379ff0fa955df Reviewed-on: https://go-review.googlesource.com/115798 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
2018-02-20html/template: make more use of stringerDaniel Martí
The code was maintaining manual versions of it in multiple places - replace all of them. Change-Id: I04c3063877b05ba914de9f5dddb33ffe09f308fe Reviewed-on: https://go-review.googlesource.com/95356 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-02-19all: add more uses of stringerDaniel Martí
By grepping for ]string{$, one can find many manual implementations of stringer. The debug/dwarf ones needed the new -trimprefix flag, too. html/template was fairly simple, just implementing the fallback as stringer would. The changes there are trivial. The ones in debug/dwarf needed a bit of extra logic since the GoString wants to use its own format, depending on whether or not the value is one of the known constants. Change-Id: I501ea7deaa538fa425c8e9c2bb895f480169273f Reviewed-on: https://go-review.googlesource.com/77253 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2017-12-14html/template: add srcset content typeMike Samuel
Srcset is largely the same as a URL, but is escaped in URL contexts. Inside a srcset attribute, URLs have their commas percent-escaped to avoid having the URL be interpreted as multiple URLs. Srcset is placed in a srcset attribute literally. Fixes #17441 Change-Id: I676b544784c7e54954ddb91eeff242cab25d02c4 Reviewed-on: https://go-review.googlesource.com/38324 Reviewed-by: Kunpei Sakai <namusyaka@gmail.com> Reviewed-by: Mike Samuel <mikesamuel@gmail.com> Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-09-29html/template: check "type" attribute in <script>Nodir Turakulov
Currently any script tag is treated as a javascript container, although <script type="text/template"> must not be. Check "type" attribute of "script" tag. If it is present and it is not a JS MIME type, do not transition to elementScript state. Fixes #12149, where // inside text template was treated as regexp. Fixes #6701 Change-Id: I8fc9e504f7280bdd800f40383c061853665ac8a2 Reviewed-on: https://go-review.googlesource.com/14336 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2015-09-09html/template: preserve attr in stateBeforeValueNodir Turakulov
Context: #12149. The problem there is that contents of <script type="text/template"> are treated as JS, and thus // is treated as regexp. Preserve context.attr while we are in the attribute, in particular in stateBeforeValue, so we have attr when reading attr value. Next CL will actually fix the bug. Change-Id: I99add2237b0885ecdcc08b4f7c25d0af99173e53 Reviewed-on: https://go-review.googlesource.com/14335 Reviewed-by: Rob Pike <r@golang.org>
2014-09-08build: move package sources from src/pkg to srcRuss Cox
Preparation was in CL 134570043. This CL contains only the effect of 'hg mv src/pkg/* src'. For more about the move, see golang.org/s/go14nopkg.