Re: Opt-in flag to disable DOM clobbering

Yes, we have some data on that, and I completely agree, the amount of
potential breakage seems to be too high for deprecation. I think the
way-to-go should be more toward an opt-in CSP directive or feature policy
response header to allow developers to disable or restrict different types
of named property accesses, and preventing the clobbering of built-in
window properties could definitely be the first step.

In fact, such protection seems to be already existent for a few certain
window APIs, like window.location, but not for many others (see, e.g., here
<https://domclob.xyz/domc_wiki/browsers/browserAPIs.html>), so an opt-in
policy could complement that.

Our dataset (top 5K sites, 206K webpages) shows that disabling DOM
clobbering for the remaining built-in window properties could potentially
break 1.4% of the webpages or 4.8% of the sites (over-approximation). These
are the sites that used the name of at least one clobberable window
property as the id/name attribute of a tag in the rendered HTML tree!

In comparison, 16.7% of the webpages or 42% of the websites could be at
risk because they use these clobberable built-in window properties in their
JavaScript code, and attackers can potentially tamper with the execution by
injecting a markup with colliding names. These websites may benefit from
such an opt-in protection.

Cheers,
Soheil

On Mon, Oct 24, 2022 at 2:10 PM Titouan Rigoudy <titouan@chromium.org>
wrote:

> What an *interesting* feature that is! HTML never ceases to amaze me.
>
> 10% sounds way too high for a deprecation unfortunately - even if ~8.3% is
> malicious (if I understand your 5:1 metric correctly). Breaking 0.1% of
> websites is already extremely challenging.
>
> Maybe a more narrowly-scoped improvement we could start with would be to
> prevent clobbering of built-in window variables? Do we have any data on
> that?
>
> Cheers,
> Titouan
>
> On Sun, Oct 23, 2022 at 12:22 PM Soheil Khodayari <
> soheil.khodayari@cispa.de> wrote:
>
>> Hi all,
>>
>> We are researchers from CISPA, germany. In our latest project, we studied
>> the state of DOM clobbering on the Web, and found that these attacks can
>> pose concerning threats to web apps (see our paper
>> <https://publications.cispa.saarland/3756/1/sp23_domclob.pdf> / website
>> <https://domclob.xyz/>). In the past, we have also witnessed other
>> prominent examples of DOM clobbering by other researchers (e.g.,
>> AMP4Email
>> <https://research.securitum.com/xss-in-amp4email-dom-clobbering/>) and
>> there has been discussions to disable named property accesses at
>> browser-level (see, e.g., here
>> <https://github.com/w3c/webappsec-permissions-policy/issues/349> and here
>> <https://github.com/WICG/document-policy/issues/32>).
>>
>> Unfortunately, such a solution cannot be immediately rolled out, as
>> according to Google Chrome Telemetry, almost 10% of webpages in the
>> wild use clobbered variable accesses to implement functionalities that may
>> otherwise break (see, i.e., DOMClobberedVariableAccessed
>> <https://chromestatus.com/metrics/feature/timeline/popularity/1824>). In
>> our paper, we confirmed this number, and estimated a breakage-benefit ratio
>> of ~ 5:1 websites.
>>
>> In light of these circumstances, perhaps we want to allow site owners to
>> optionally switch off DOM Clobbering features, and for that an opt-in CSP
>> flag or feature/permissions policy could be a good idea. What do you
>> think? 🙂
>>
>> Cheers,
>> Soheil
>>
>> --
>> Soheil Khodayari | Doctoral Candidate
>>
>> CISPA Helmholtz Center for Information Security
>>
>> Stuhlsatzenhaus 5,
>>
>> 66123 Saarbrücken, Germany
>>
>> Email soheil.khodayari@cispa.de
>>
>> Web https://www.cispa.de
>>
>

-- 
Soheil Khodayari | Doctoral Candidate

CISPA Helmholtz Center for Information Security

Stuhlsatzenhaus 5,

66123 Saarbrücken, Germany

Email soheil.khodayari@cispa.de

Web https://www.cispa.de