search

w3c / trusted-types

A browser API to prevent DOM-Based Cross Site Scripting in modern web applications.
https://w3c.github.io/trusted-types/dist/spec/
Other
602 stars 72 forks source link

Handling of dependent types #6

Closed xtofian closed 5 years ago

xtofian commented 7 years ago

There are attributes where the required security type contract of the assigned value depends on the value of another attribute. Notably, the <link> element's href attribute requires a type that represents a URL that references a trustworthy resource (TrustedResourceUrl in Closure; similar to TrustedScriptURL in this proposal), if the element's rel attribute has a value of import or stylesheet. For other values of rel (e.g., author) the href attribute is interpreted as a plain hyperlink, and hence a weaker contract suffices ("following the link / navigating to the URL does not result in any undesirable side effects such as script execution").

This is a rather unfortunate design but we're presumably stuck with it.

In particular, we need to account for the possibility that the attribute that the type depends on (rel) is changed from a value that requires the weaker contract to one that requires the stronger contract after the dependently-typed attribute (href) itself.

In Closure, this is accounted for by a typed wrapper (goog.dom.safe.setLinkHrefAndRel) that sets both attributes at the same time, and dynamically enforces the appropriate type contract, combined with disallowing direct assignment to either attribute (rel or href) in application source.

In a native implementation of typed setters such a combined setter is likely undesirable. However, the issue could be addressed by changing the behavior of the rel attribute setter to clear the href attribute's value on assignment to the rel attribute (or perhaps preferably, to throw an exception if rel is assigned when href already has a non-empty value). The setter for the href attribute can then dynamically enforce the appropriate type contract depending on the rel attribute's actual value.

xtofian commented 7 years ago

Another example is the srcdoc attribute of <iframe> elements: If the element's sandbox attribute contains allow-same-origin, then the value assigned to srcdoc must be HTML markup that's safe to evaluate in the same origin. Otherwise, a weaker contract is sufficient.

xtofian commented 6 years ago

Another variant: The contents of <script> are treated as JavaScript if the type attribute is "module" or a JS MIME type, or omitted. If it's some other value, the contents are an uninterpreted data block with application-defined semantics.

Somewhat aside, it's not obvious what type should be required for the contents (or URL) of a Githubissues.

  • Githubissues is a development platform for aggregating issues.