[webkit-changes] [WebKit/WebKit] 4d3260: Trusted Types can be bypassed by event handlers no...

[Luke Warlow]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4d3260a66f0b8fb9eed262d966c3841d78388bc4
      https://github.com/WebKit/WebKit/commit/4d3260a66f0b8fb9eed262d966c3841d78388bc4
  Author: Luke Warlow <lwarlow at igalia.com>
  Date:   2025-01-10 (Fri, 10 Jan 2025)

  Changed paths:
    M LayoutTests/imported/w3c/web-platform-tests/trusted-types/TrustedTypePolicyFactory-getAttributeType-event-handler-content-attributes.tentative-expected.txt
    M LayoutTests/imported/w3c/web-platform-tests/trusted-types/trusted-types-event-handlers-expected.txt
    M LayoutTests/platform/win/imported/w3c/web-platform-tests/trusted-types/TrustedTypePolicyFactory-getAttributeType-event-handler-content-attributes.tentative-expected.txt
    M Source/WebCore/dom/TrustedType.cpp
    M Source/WebCore/dom/TrustedType.h
    M Source/WebCore/dom/make-event-names.py

  Log Message:
  -----------
  Trusted Types can be bypassed by event handlers not defined in HTMLElement.idl
https://bugs.webkit.org/show_bug.cgi?id=283927

Reviewed by Chris Dumez.

Currently to determine if an attribute is an event handler attribute, we use HTMLElement::eventNameForEventHandlerAttribute.
It turns out this doesn't include all event handler attributes, missing ones defined for specific elements
such as HTMLBodyElement or HTMLMediaElement.

There exists a HTMLBodyElement::eventNameForWindowEventHandlerAttribute method which I could additionally check,
but this wouldn't deal with HTMLMediaElement or any other special cases.

To address this issue and prevent regressions a new approach is taken.

make-event-names.py has been updated to generate a HashSet of event handler names.

A new isEventHandlerAttribute method is added which uses this new HashSet to check if the attribute
name exists within it. This replaces the eventNameForEventHandlerAttribute mechanism.

This does mean that attributes with a name that isn't an event handler content attribute but an event exists for
(e.g. onreadystatechange from XHR) get protected by TrustedTypes. This matches Chromium's current behaviour, and feels like the safest approach
to avoid introducing bypasses in future.

* LayoutTests/imported/w3c/web-platform-tests/trusted-types/TrustedTypePolicyFactory-getAttributeType-event-handler-content-attributes.tentative-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/trusted-types/trusted-types-event-handlers-expected.txt:
* LayoutTests/platform/win/imported/w3c/web-platform-tests/trusted-types/TrustedTypePolicyFactory-getAttributeType-event-handler-content-attributes.tentative-expected.txt:
* Source/WebCore/dom/TrustedType.cpp:
(WebCore::trustedTypeForAttribute):
(WebCore::isEventHandlerAttribute):
* Source/WebCore/dom/TrustedType.h:
* Source/WebCore/dom/make-event-names.py:
(main):

Canonical link: https://commits.webkit.org/288723@main



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications