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.

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

Trusted types attributes #1268

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

Conversation

lukewarlow
Copy link
Member

@lukewarlow lukewarlow commented Mar 27, 2024

This calls the get Trusted Types-compliant attribute value algorithm from Trusted Types (w3c/trusted-types#418) from attribute's change, append, and replace.

Changed the signature of setAttribute and setAttributeNS to accept Trusted Types as values. The underlying Attr node's values continue to be DOMString, so moving nodes across elements or adding standalone attributes to elements can cause TT violations. This matches WPT tests and the Chromium's implementation.

See and #789. Supercedes #809 and #1247

(See WHATWG Working Mode: Changes for more details.)


Preview | Diff

@lukewarlow
Copy link
Member Author

This is a clone of #1247 where I will finish any outstanding work to get this across the line

@lukewarlow lukewarlow force-pushed the trusted-types-attributes branch 2 times, most recently from 3562fcb to ac5b4aa Compare April 10, 2024 15:52
@lukewarlow lukewarlow marked this pull request as ready for review April 11, 2024 12:21
@lukewarlow
Copy link
Member Author

See also #1258 which is another integration point with the DOM spec that we need for TT.

@lukewarlow lukewarlow marked this pull request as draft April 15, 2024 10:22
dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated
<li><p><a>Validate and set attribute value</a> <var>attr</var>'s <a for="Attr">value</a> for
<var>attr</var> with <var>element</var>.

<li><p>If <var>element</var> <a lt="has an attribute">has</a> an <a>attribute</a>

Choose a reason for hiding this comment

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

I still find it difficult to wrap my head around this logic. I think conceptually, we want to have the old value -- from before the call, and thus before a default policy might have mucked with it. That's what should go into the change attribute logic. But once we have that, I'm not sure why we'd need to throw an exception here. I'm not sure why we'd have to care whether the default policy does anything funny with the attribute in the mean time.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've read through this spec path and I believe that, if the default policy removes the existing attribute node, then this will call replace an attribute, which in turn calls replace a list item, which results in a no-op because the old value no longer exists to be replaced.

So I think in this situation you're probably right the spec doesn't need to do anything, will make that change.

Copy link
Member Author

Choose a reason for hiding this comment

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

Having said that I'm slightly uneasy about stuff like attribute change steps still firing and how that all works spec wise.

Both Chromium and WebKit don't actually follow the spec 100% here and so I think would actually result in a different behaviour to this spec (the index lookup happens after the TT call) so that's also not ideal.

@lukewarlow lukewarlow marked this pull request as ready for review April 22, 2024 12:53
@lukewarlow
Copy link
Member Author

I think I've addressed all the comments from #1247.

I do want to point out Chrome and WebKit don't (or at least not in a way obvious to me) 100% follow the flow of the spec and as a result this may result in differences specifically in weird cases with attribute mutation.

So that bit especially it would be good to get feedback on.

It's also worth being aware that like Chromium's implementation this spec means that certain ways to update a nodes value don't work with a trusted type object as a user might expect. (e.g. iframe.getAttributeNode('srcdoc').value = trustedHTMLObj; will throw unless allowed by a default policy). I think in pratice this will be fine, and in some cases is the only real option we have without nodes keeping track of whether they're trusted or not (which would add lots of complexity)

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

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

This change is either incomplete or makes many cosmetic changes that would be best proposed separately as they confuse me quite a bit.

dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
@lukewarlow
Copy link
Member Author

This change is either incomplete or makes many cosmetic changes that would be best proposed separately as they confuse me quite a bit.

Apologies I thought I'd reverted all of these changes but I missed a few, it's because I changed stuff and then changed it back and this led to some wonky diffs. Have hopefully reverted all of these unnecessary changes

@lukewarlow lukewarlow force-pushed the trusted-types-attributes branch 2 times, most recently from 1d42460 to 1eeaf00 Compare April 22, 2024 15:52
dom.bs Outdated
<li><p>If <var>attribute</var>'s <a for=Attr>element</a> <a lt="has an attribute">has</a>
an <a>attribute</a> <var>attribute</var>, then <a>handle attribute changes</a> for
<var>attribute</var> with <var>attribute</var>'s <a for=Attr>element</a>, <var>oldValue</var>, and
<var>value</var>.
Copy link
Member

Choose a reason for hiding this comment

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

Should this be value or attribute's value? They can be different, right?

dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
dom.bs Outdated Show resolved Hide resolved
dom.bs Show resolved Hide resolved
@lukewarlow
Copy link
Member Author

lukewarlow commented May 7, 2024

@otherdaniel, @annevk , and @smaug---- regarding the case where the default policy changes assumptions about the existence of an attribute mid-way through what would you prefer the spec say to do? Currently I've specced to throw, but Chromium currently re-looks up the index (spec doesn't explicitly work on an index basis but Chromium and WebKit do)

@annevk
Copy link
Member

annevk commented May 13, 2024

Attributes are stored in a list and those do have indices per Infra. What am I missing?

@lukewarlow
Copy link
Member Author

Sorry I mean algorithmically the spec and implementations don't follow the same flow. So it's trickier to reason between the spec and implementation. This might just be my lack of familiarity with these APIs too.

@annevk
Copy link
Member

annevk commented May 13, 2024

The path of least resistance is prolly matching Chromium. Introducing new paths that throw is always risky. If you are looking for guidance as to how, I'd need quite a bit more context to provide helpful suggestions.

@lukewarlow lukewarlow force-pushed the trusted-types-attributes branch 2 times, most recently from 4089eaf to 02db8c7 Compare May 16, 2024 15:41
@lukewarlow
Copy link
Member Author

The path of least resistance is prolly matching Chromium. Introducing new paths that throw is always risky. If you are looking for guidance as to how, I'd need quite a bit more context to provide helpful suggestions.

I've partially matched Chromium but gone a bit further with the error correction as Chromium still has some bugs wrt mutating attributes within the default policy.

@lukewarlow lukewarlow requested a review from annevk May 16, 2024 15:44
@lukewarlow
Copy link
Member Author

@otherdaniel if you've got time could you read through this to ensure it makes sense to you?

@@ -6530,23 +6545,39 @@ string <var>namespace</var> (default null):</p>

<div algorithm>
<p>To <dfn export id=concept-element-attributes-set-value>set an attribute value</dfn> given an
Copy link
Member Author

Choose a reason for hiding this comment

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

This algorithm covers setAttributeNS

<a for=Attr>local name</a> is <var>qualifiedName</var>, <a for=Attr>value</a> is
<var>value</var>, and <a for=Node>node document</a> is <a>this</a>'s <a for=Node>node document</a>,
then <a lt="append an attribute">append</a> this <a>attribute</a> to <a>this</a>, and then return.
<li><p>Let <var>attributeExists</var> be false if <var>attribute</var> is null, and true otherwise.
Copy link
Member Author

Choose a reason for hiding this comment

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

This algorithm covers setAttribute

@@ -7382,7 +7430,13 @@ string <var>value</var>, run these steps:
<li><p>If <var>attribute</var>'s <a for=Attr>element</a> is null, then set <var>attribute</var>'s
<a for=Attr>value</a> to <var>value</var>.

<li><p>Otherwise, <a lt="change an attribute">change</a> <var>attribute</var> to <var>value</var>.
<li><p>Otherwise:
Copy link
Member Author

Choose a reason for hiding this comment

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

This covers attr.nodeValue, attr.value, and attr.textContent.

@@ -6519,6 +6529,11 @@ string <var>namespace</var> (default null):</p>

<li><p>If <var>oldAttr</var> is <var>attr</var>, return <var>attr</var>.

<li><p>Let <var>verifiedValue</var> be the result of calling <a>verify attribute value</a>
Copy link
Member Author

Choose a reason for hiding this comment

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

This covers, setAttributeNode, setAttributeNodeNS, setNamedItem and setNamedItemNS

dom.bs Outdated Show resolved Hide resolved
lukewarlow added a commit to lukewarlow/WebKit that referenced this pull request Jun 11, 2024
https://bugs.webkit.org/show_bug.cgi?id=275352

Reviewed by NOBODY (OOPS!).

The DOM spec PR no longer enforced Trusted Types within toggleAttribute so this removes that from the implementation.

See whatwg/dom#1268

* LayoutTests/imported/w3c/web-platform-tests/trusted-types/Element-toggleAttribute-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/trusted-types/Element-toggleAttribute.html: Added.
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::toggleAttribute):
@annevk
Copy link
Member

annevk commented Jun 12, 2024

This now seems to invoke TT even when we have specifications manipulate attributes, or when element.id's setter is used. Is that intentional?

For review it really helps to have an up-to-date commit message that clearly describes the intent. That's why we made it one of the PR checkboxes.

It also seems that it would cause a change in ordering between enforcing this in IDL and in the algorithms as now certain exceptions are thrown first. That will need test coverage.

webkit-commit-queue pushed a commit to lukewarlow/WebKit that referenced this pull request Jun 12, 2024
https://bugs.webkit.org/show_bug.cgi?id=275352

Reviewed by Darin Adler.

The DOM spec PR no longer enforced Trusted Types within toggleAttribute so this removes that from the implementation.

See whatwg/dom#1268

* LayoutTests/imported/w3c/web-platform-tests/trusted-types/Element-toggleAttribute-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/trusted-types/Element-toggleAttribute.html: Added.
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::toggleAttribute):

Canonical link: https://commits.webkit.org/279950@main
@lukewarlow
Copy link
Member Author

lukewarlow commented Jun 13, 2024

Trusted Types integration with DOM

The DOM spec already contains partial integration with Trusted Types this was included in #1258

This PR updates the DOM functions related to attributes.

The following functions' IDL are adjusted, to accept a TrustedType (TrustedHTML or TrustedScript or TrustedScriptURL) or a string.

Element.setAttribute
Element.setAttributeNS

The above two functions are the "sanctioned" methods for updating the value of an attribute, any other way relies on default policy else they'll fail TT checks.

The algorithm for setAttribute function (and the "set an attribute value" algorithm only when used by setAttributeNS) is updated to call into the Trusted Types such that if the attribute being set is one of those covered by Trusted Types,
the value being set is verified (potentially being replaced with a different value).

These algorithms include some handling for if the trusted types default policy changes whether the attribute being set exists or not.

Element.setAttributeNode and Element.setAttributeNodeNS both, along with NamedNodeMap.setNamedItem and NamedNodeMap.setNamedItemNS make use of the "setting an attribute" algorithm, which is similarly updated to call into Trusted Types.

Attr.value, Node.textContent, and Node.nodeValue setters call "set an existing attribute value", this algorithm is updated such that for attributes attached to an element, trusted types is called into and verifies the value.

In all these cases the changes only have any impact for a select few attributes (e.g. event handlers, iframe srcdoc attribute)

@lukewarlow
Copy link
Member Author

lukewarlow commented Jun 13, 2024

The change to set an attribute value breaks iframe.srcdoc property setting currently (it'll do a double check). It's possible that there's other reflection properties that have the same issue (script.src comes to mind).

I'll take a look into how best to sort that out. I'm thinking adding an optional boolean to control this check, that setAttributeNS sets to true?

Edit: this should be fixed with the new verify flag.

…rue from setAttributeNS to fix issue with current spec
@lukewarlow
Copy link
Member Author

This now seems to invoke TT even when we have specifications manipulate attributes,

Should I add a verify flag to these other algorithms so they can't be accidentally invoked doing TT checks?

I don't think element.id is related because it's not one of these specific attributes. But you raise a good point which I think the verify flag I just added addresses

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

Successfully merging this pull request may close these issues.

None yet

5 participants