- From: Soheil Khodayari <soheil.khodayari@cispa.de>
- Date: Fri, 21 Oct 2022 10:36:49 +0200
- To: <public-webappsec@w3.org>
- CC: "Pellegrino, Giancarlo" <pellegrino@cispa.de>
- Message-ID: <CABFWSjD136TdsT9x_jHvFxTossQPGu_+rGyALihs2bY9XAcOSg@mail.gmail.com>
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
Received on Sunday, 23 October 2022 10:21:16 UTC