Hacker News Reader

Comment by xg15 | Hacker News Reader

> According to the research team, in most of the cases they analyzed, the Chrome extensions disabled CSP and other security headers “to introduce additional seemingly benign functionalities on the visited webpage,” and didn’t look to be malicious in nature.

Yes, because Chrome's architecture forces extensions to do this, ironically in the name of security.

Normal extension code can access a page's DOM but it cannot interact with any scripts on the page.

If you want your extensions to interact with the page's JS, the only way is to play man-in-the-middle and inject your own JS as if it was loaded by the page.

View on HN

> Yes, because Chrome's architecture forces extensions to do this, ironically in the name of security.

To be fair, I think Firefox has this restriction too? I might be wrong, but I could have sworn I ran into some script-injection extensions that weren't working on some sites because of this problem.

It's been a while since I checked, I eventually gave up on the extensions because I wanted to thin out my list and I wasn't comfortable with them overriding CORS headers -- so things may have changed, or maybe I misunderstood the situation even back then.

Yeah, I keep having issues with CORS headers in Firefox and then it becomes really hard to pinpoint which extension caused what.

I may be wrong but it didn't used to be like that. It's a sideeffect of the whole webextension concept no?

Maybe? I vaguely remember webextensions not needing to do this. But I can't say that with certainty, because it might be that most websites didn't enable CORS so I never noticed, or I could just have the timeline mixed up in my head.

I don't think anything about webextensions requires this problem to exist. So if it is a problem with webextensions, it's a problem we've "chosen" to have. And browsers could fix this without drastically overhauling anything with extensions.

But I can not stress enough how much out of my depth I am commenting on this, my full knowledge is basically a couple days worth of research a year or two ago and some interaction on a bug report.

Any proper implementation of the cors eval/script constraints would block extension script injection, regardless of whether webextensions are used. You'd have to run code outside of the page context, which automatically poses issues since the page is probably in another process.

The problem is that the extension can alter or fully remove the cors headers before it injects scripts, neutering even the best configuration.

What are some use cases for interacting with other scripts, instead of interacting with the DOM?

I suppose that if you want to disable some behavior in the website (to insert your own extension's before letting the website's own execute) you have to do that... But when would you want to do that?

When you want to hook into page functionality and extend it. For example, extensions for YouTube will routinely access the JS objects of the page and listen to player events in order to introduce new features. This is only possible if you run your code in the context of the page.

You can add new scripts to the page though. You don't have to interfere with the existing scripts / change them. That doesn't break CSP if you do it the right way.

Interacting with the page as if your code would have been loaded by the page is only possible if you inject your code in the page context, typically using a script tag in Chrome, at which point you are governed by the CSP restrictions of the page.

You either relax those restrictions in some way, or you can't run your code in the JS context of the page.

It's possible to run code in a content script regardless of how restrictive the pages's CSP headers are, but you are running in an isolated environment that can only access the page DOM.

Can you provide an example of the website which makes it impossible to insert JS from extension? I'd like to tinker with it. I wrote a simple extension which inserted JS to youtube and it worked just fine. I thought youtube is secure enough?

YouTube does not (currently) send CSP headers from what I can see in the dev tools. Hacker News does, but it specifies "unsafe-inline" which negates most of the protection. Not aware of any sites with more locked down policies off the top of my head; it's not exactly an advertised feature of most sites.

GitHub

For a Chrome extension using manifest V2: you can inject "inline" scripts into the DOM and interact with a page's JS regardless of the CSP.

For a Chrome extension using manifest v3: you can inject script tags with a src pointing to a local JS file in the extension regardless of the CSP.

Modifying the CSP is not a requirement for a Chrome extension to interact with a page's JS. I don't know about other browsers though.

slack. I do so with my extension[0]. At one point they rewrote it and added CSP.

In order to inject my code before theirs, I had to come up with different approaches on FF and Chrome... and since it was starting to become a cat and mouse game, I just took the extension private.

After that, they didn't escalate their game. I'm thankful for that, so that I can keep enjoying it without spending lots of time figuring out how to mess with it.

[0] https://refined.chat

Adblockers often inject anti-anti-adblocking scripts. AFAIK, these are often drop-in replacements and so need to communicate with other scripts in the same way as the original.

What about Message passing (https://developer.chrome.com/docs/extensions/mv3/messaging/)?

Reply on news.ycombinator.com