Skip to content
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.

Sign up for GitHub

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

Collect HTML injection sinks and DOM XSS injection sinks under XSS injection sinks #404

Closed
wants to merge 1 commit into from
Closed

Collect HTML injection sinks and DOM XSS injection sinks under XSS injection sinks #404

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 22 additions & 21 deletions spec/index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,10 +67,10 @@ if `aString` contains untrusted data, `foo[bar] = aString` is a statement
that potentially can trigger a vulnerability, depending on a value
of `foo` and `bar`.

This document focuses on preventing DOM-Based Cross-Site Scripting
Copy link
Member

Choose a reason for hiding this comment

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

Please keep the DOM-Based XSS or DOM XSS in the spec text (and the link fragments). Trusted Types only covers DOM XSS (Type 0 XSS). The name is a bid misleading, but DOM XSS covers all sinks available to client side code (i.e. DOM API sinks, but also eval, Location etc). This is as opposed to server-side XSSes (Type 1 and 2).

This applies to all mentions below.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Agree. Thanks for the explanation.

This document focuses on preventing Cross-Site Scripting
that occurs when attacker-controlled data reaches
[[#dom-xss-injection-sinks]], as that eventually causes execution of the
script payload controlled by the attacker. DOM XSS is prevalent in the
[[#xss-injection-sinks]], as that eventually causes execution of the
script payload controlled by the attacker. XSS is prevalent in the
web applications as there are over 60 different
injection sinks (e.g. `Element.innerHTML`, or `Location.href` setters).

Expand Down Expand Up @@ -127,9 +127,9 @@ monitor and review.
that uses a secure templating system to generate the UI
components. The application also depends on 3rd party client-side
libraries that perform auxiliary tasks (e.g. analytics, performance
monitoring). To ensure that none of these components introduce DOM
monitoring). To ensure that none of these components introduce
XSS vulnerabilities, author defines a Trusted Type policy in the
templating library and enables the enforcement for the [[#dom-xss-injection-sinks]].
templating library and enables the enforcement for the [[#xss-injection-sinks]].

* A large team maintains a complex client-side application.
They create a number of Trusted Types policies that satisfy the security
Expand All @@ -141,15 +141,15 @@ monitor and review.
The need to create trusted values to affect [=injection sinks=],
combined with additional scrutiny on changes that affect policy
code, incents developers to use safe abstractions instead of writing ad-hoc
string composition code when interacting with [[#dom-xss-injection-sinks]].
string composition code when interacting with [[#xss-injection-sinks]].

When considering the risk of DOM XSS, security auditors find a
When considering the risk of XSS, security auditors find a
small attack surface; they focus on the small amount of code that
crafts the CSP header and provides the safe abstractions, and ignore the
bulk of client-side application code.

* An existing web application interacts with the DOM mostly using XSS-safe
patterns (i.e. without using [[#dom-xss-injection-sinks]]). In a few places,
patterns (i.e. without using [[#xss-injection-sinks]]). In a few places,
however, it resorts to using risky patterns like loading additional script using
JSONP, calling into `innerHTML` or `eval`.

Expand All @@ -159,7 +159,7 @@ monitor and review.

As such, CSP cannot be enforced on this application (without resorting to
an unsafe version using `'unsafe-eval' 'unsafe-inline'`). Additionally,
it's possible some codebase with DOM XSS flaws was not included in a review,
it's possible some codebase with XSS flaws was not included in a review,
or will be introduced in the future.

To address this risk, the author converts the reviewed parts to using
Expand All @@ -177,7 +177,7 @@ monitor and review.

Any additional code, including the code of often-changing dependencies,
can be excluded from the review, unless it creates a Trusted Type policy.
Without it, the code cannot cause a DOM XSS.
Without it, the code cannot cause XSS.

# Framework # {#framework}

Expand Down Expand Up @@ -205,14 +205,17 @@ it's not easy to distinguish one from the other.
This document organizes the injection sinks into groups, based on the
capabilities that sinks in a given group have. [=Enforcement=] for groups is controlled via <a>trusted-types-sink-group</a> values.

### HTML injection sinks ### {#html-injection-sinks}
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps it might be easier to just merge those two existing sections, and separate them once there is another use case specified?

#407

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Agree.

### Cross-Site Scripting (XSS) injection sinks ### {#xss-injection-sinks}
*This section is not normative.*

Guarding XSS injection sinks is controlled by the <a>trusted-types-sink-group</a> named 'script'.

#### HTML injection sinks #### {#html-injection-sinks}

*This section is not normative.*

HTML <a>injection sinks</a> parse input strings into a DOM tree. Since HTML parsers
can create arbitrary elements, including scripts, and set arbitrary attributes,
enabling the [=enforcement=] of any <a>trusted-types-sink-group</a> also implies
enforcing types for HTML injection sinks.
HTML <a>injection sinks</a> parse input strings into a DOM tree. HTML parsers
can create arbitrary elements, including scripts, and set arbitrary attributes.

Examples of HTML injection sinks include:

Expand All @@ -222,7 +225,7 @@ Examples of HTML injection sinks include:
* Functions that create a new same-origin {{Document}} with caller-controlled
markup like {{DOMParser/parseFromString()}},

### DOM XSS injection sinks ### {#dom-xss-injection-sinks}
#### DOM XSS injection sinks #### {#dom-xss-injection-sinks}

*This section is not normative.*

Expand All @@ -238,8 +241,6 @@ Examples of include:
* Functions that execute code directly like `eval`,
* Navigation to 'javascript:' URLs.

Guarding DOM XSS injection sinks is controlled by the <a>trusted-types-sink-group</a> named 'script'.

## Trusted Types ## {#trusted-types}

To allow the authors to control values reaching injection sinks,
Expand Down Expand Up @@ -1488,7 +1489,7 @@ Types framework for all the [=injection sinks=] of certain groups in a current [
Specifically, it defines what should be the behavior when a string value is passed to an [=injection sink=]
of a given group (i.e. should the type-based enforcement be enabled for such sinks).

Note: Currently, only the enforcement for [[#dom-xss-injection-sinks]] is specified.
Note: Currently, only the enforcement for [[#xss-injection-sinks]] is specified.

The syntax for the directive's [=directive/name=] and [=directive/value=] is described by the following
ABNF:
Expand All @@ -1500,7 +1501,7 @@ directive-value = <a>trusted-types-sink-group</a> *( <a href="https://w3c.github
</pre>

<div class="example" id="require-tt-for-script-header">
Enforce Trusted Types at the DOM XSS injection sinks.
Enforce Trusted Types at the XSS injection sinks.

<pre class="http">
Content-Security-Policy: require-trusted-types-for 'script'
Expand Down Expand Up @@ -1563,7 +1564,7 @@ Content-Security-Policy: require-trusted-types-for 'script'; trusted-types one t

<div class="example" id="header-that-allows-no-policy-names">
An empty [=directive=] [=directive/value=] indicates policies may not be created,
and sinks expect Trusted Type values, i.e. no DOM XSS [=injection sinks=] can be used
and sinks expect Trusted Type values, i.e. no XSS [=injection sinks=] can be used
at all.

<pre class="http">
Expand Down
Loading