- From: juj <notifications@github.com>
- Date: Tue, 08 Oct 2024 01:36:47 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/1315@github.com>
### What is the issue with the DOM Standard? Consider the following page: ```html <html><body> <img name='currentScript' src='http://google.com/foo.js'> <script> console.log(document.currentScript.src); </script></body></html> ``` This will print `'http://google.com/foo.js'` instead of printing whatever script file is currently being executed on the web server's domain. If an attacker is able to inject DOM elements into a web page (due to some pre-existing security flaw), with this `<img name='currentScript'>` trick they can potentially escalate their attack power to a higher tier XSS security flaw. Searching the web, there are several CVE advisories about this trick being used to elevate an attacker's threat area: https://vulert.com/vuln-db/CVE-2024-45389 https://github.com/advisories/GHSA-gcx4-mw62-g8wm https://nvd.nist.gov/vuln/detail/CVE-2024-45812 https://github.com/webpack/webpack/security/advisories/GHSA-4vvj-4cpr-p986 Surely web browsers should just plug this threat vector altogether, and not allow any DOM element `name=''` attribute overwrite any element name (e.g. 'body', 'head', 'elements', 'URL', 'addEventListener', 'removeEventListener', etc...) on [document](https://developer.mozilla.org/en-US/docs/Web/API/Document/currentScript) that has a prereserved meaning in the DOM spec? For example, it was recently reported to Emscripten project that [Emscripten should not be accessing document.currentScript.src "bare" since it could be attacked via this way](https://github.com/emscripten-core/emscripten/pull/22688), but instead always only access it on the condition that `document.currentScript.tagName == 'SCRIPT'`. It feels a bit nonsensical and misplaced to have to account for this problem in Emscripten since surely nobody should be allowed to have `<foo name='currentScript'>` replace `document.currentScript` - there are no good legitimate uses of that for anyone? Also, in addition to the `document.currentScript` functionality, even if developers sanitize that hole, an attacker could cause denial of service problems to web pages by injecting an element like `<img name='addEventListener'>` which will a site to otherwise function incorrectly. Can the DOM spec enforce a guarantee that built-in attributes cannot be replaced in this manner? That way web developers would not need to think about this kind of threat vector elevation attacks, and this whole class of CVEs like have been reported above would be impossible? -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/1315 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/dom/issues/1315@github.com>
Received on Tuesday, 8 October 2024 08:36:51 UTC