1548773 - Remove support for typemustmatch

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Anne (:annevk)]

It's not supported by other browsers and it creates a smallish cross-origin leak: https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels#object-typemustmatch.

HTML: https://github.com/whatwg/html/pull/4590
WPT: https://github.com/web-platform-tests/wpt/pull/16656

Comment 1

[Frederik Braun [:freddy]]

Attachment: Bug 1548773: Remove support for typemustmatch r?bzbarsky

Comment 2

[Frederik Braun [:freddy]]

wpt are being removed in https://github.com/web-platform-tests/wpt/pull/16656

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a08af741bd23
Remove support for typemustmatch r=bzbarsky

Comment 4

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/a08af741bd23

Comment 5

[Frederik Braun [:freddy]]

terjanq (CCd to the bug) wrote the PoC at https://xsleaks.github.io/xsleaks/examples/content-type/ and shared his research at the xsleaks wiki https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels#object-typemustmatch.
He should be credited for identifying this problem.

Comment 6

[Daniel Veditz [:dveditz]]

Can't the attacker just directly ping the URL to find out its content-type most of the time? This only leaks a bit of info if it's a server or page that can't be reached by a non-authenticated user.

Comment 7

[terjanq]

Hi, thanks for adding me to the issue. I haven't expected this to be an actual bug because the behavior follows the feature specification.

(In reply to Daniel Veditz [:dveditz] from comment #6)

Can't the attacker just directly ping the URL to find out its content-type most of the time? This only leaks a bit of info if it's a server or page that can't be reached by a non-authenticated user.

I am not sure how would that exactly work but I suspect that you are talking about requesting resources by using tags like <script> or <image> and watching for them to throw load/error events. I don't think it's as much similar behavior because there, you can only gain a limited portion of information and some of the content-types will return the same results, which in most scenarios would leak the information the attacker looks for. In my method, as long as the server responds with 200 OK, you can confirm the content-type with 100% accuracy.

As for the impact, there is a lot of webpages that when the user doesn't have access to request a specific resource the request is being redirected to a 404 Not Found webpage which in reality is 200 OK response. Then using the technique it's trivial to detect that the response has text/html content-type even when the website is not frameable.
This also could be applied to the search endpoints that depending on the search query responds with a different response. For example, the website that will trigger the content-disposition when there is a result and display the error otherwise.

Comment 8

[Kohei Yoshino]

Posted site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2019/typemustmatch-attribute-has-been-dropped-from-object/