Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Because if they are allowed to write to the DOM, they can just add a script tag that loads a script from an arbitrary URL.

By my understanding, this is still possible. If you dynamically inject a script tag, your code runs in the JS context of the page itself.

On the other hand, the chrome.tabs.executeScript API referred to in this article injects a "content script", which runs in an isolated world and has access to all of the same extension APIs that statically-deployed code does. As I understand it, this is what they're really aiming to prevent: dynamically-loaded code that runs in the extension's privileged context.

There's a section at the end of the design doc that explicitly lists preventing arbitrary code execution in page contexts as a non-goal, at least for now: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...

> Also, the example shows a use of fetch. What keeps the script from eval-ing a string from the result of that fetch?

As I mentioned in another comment, Manifest V3 bans the use of eval() in extension code. If you inject a script tag into a page, that script may or may not be allowed to call eval(), depending on the page's content security policy.



For clarity, injecting a script that is not included with the extension is expressly disallowed by the Chrome Web Store Developer Program Policies.

> Some common violations include: > > * Including a <script> tag that points to a resource that is not within the extension's package

https://developer.chrome.com/docs/webstore/program_policies/...


> As I understand it, this is what they're really aiming to prevent: dynamically-loaded code that runs in the extension's privileged context.

Thank you, this is extremely helpful for me understanding the security model here, and explains what I was missing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: