Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4d3260a66f0b8fb9eed262d966c3841d78388bc4
      
https://github.com/WebKit/WebKit/commit/4d3260a66f0b8fb9eed262d966c3841d78388bc4
  Author: Luke Warlow <lwar...@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
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to