Access to the page's full interchangeable DOM API is a core feature of content scripts. the CORS * wildcard shouldn't be respected by browsers because people sometimes misuse it.Īgain: It doesn't make sense to eliminate a core feature simply on the basis that people can misuse it. What you're proposing here is akin to proposing e.g. Therefore: The feature you're proposing removing isn't used solely for the thing you seem to think it is. Furthermore, an extension might have legitimate reason to both mock and listen in to those all-domain messages as a main feature of its core functionality in extending one of these sites. The simple fact of the matter is that extensions are not the only things sending all-domain messages It's a widely-used technique.Ī site might send all-domain messages amongst its various child iframes/popups, with reasonable expectation that it controls those. In a manifest version that already has most professional extension developers panicking to try to find workarounds for communication holes and missing features, you're proposing * a fundamental break in how content scripts work: Something being useful does not justify the continued existence of a security hole. Where functionality is dangerous, or has a history of being misused (as in this case), it forms a strong argument to fix or replace. Web or content scripts can use window.postMessage with a targetOrigin of "*" to broadcast to every listener, but this is discouraged, since an extension cannot be certain the origin of such messages, and other listeners (including those you do not control) can listen in.īeing able to think of one specific scenario where something can be misused isn't sufficient to justify removing that piece from the platform. Place as little trust in messages from the DOM as possible. Origin and source validation are a necessity, but even still, messages could come from JavaScript that was inserted into a page via XSS, via another malicious Chrome extension, etc. This proposed deprecation presupposes that an alternative mechanism be in place for this functionality.Įxamples where security issues have been highlighted: It is proposed that any script that that is not in a position to identify the origin of that script, for example content scripts, be excluded from receiving messages via window.postMessage(). The problem this creates is that web extension developers and webpage developers are being invited to broadcast potentially private information to potentially hostile code. This broadcasts a message to anyone who wants to listen. Right now, the only cross platform way for a content script and a webpage to communicate with each other is using the window.postMessage(message, '*') function.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |