Chrome extensions are tampering with security headers
therecord.media
therecord.media
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.
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.
I may be wrong but it didn't used to be like that. It's a sideeffect of the whole webextension concept no?
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.
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?
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.
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.
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.
The reason I created the extension is that our company provides a service where loading your site in our iframe is necessary for us to provide our service.
Lots of sites use security headers to block this, so we created a chrome extension to strip the headers out.
This would obviously be horrible if we recklessly stripped the headers on ALL sites. But what we did to minimize the security risk is to register a dedicated domain where ONLY that iframe loading your site occurs, and that dedicated domain is the ONLY domain where the chrome extension strips security headers.
In other words, our extension doesn't do anything, unless the user is actively logged into our service using our tool, which requires their site load in an iFrame.
The risk of doing this is minimal if you take the correct precautions and only strip the headers when absolutely necessary (and never strip headers when the parent frame is a domain outside of your control).
As someone who runs a website with a strict CSP, when I first went live I was panicked by the fact that we got TONS of reports about CSP violations to our report URL. It was only then when I realized that our CSP was blocking a ton of extensions that people had installed. Honestly, I think at that point I would have preferred that the extension update our CSP, it's not like the extension couldn't already see everything on our pages.
Edit: typo
I am not familiar with the architectural framework of browser extensions, but would this already be possible, that is for an extension to read the contents of the page (which it obviously already has access to) but then send that information using a connection that doesn't operate in the same security context as the page that was read?
I mean, browser extension CSP violations are triggered because the extension just basically injects a script into the page. Is it possible for the extension to just filter the page context and make a remote request by some other means?
Yes it is. I think what you describe is in fact the preferred way for extensions that need to communicate with a remote service are expected to work, and when implemented that way, the CSP rules (rightly) don't apply.
From what I understood of the article, this alternative way of sending data isn't what they mean by extensions tampering with security headers. The article doesn't go into detail but it would be interesting to see if the header tampering is necessary in all these cases, or if a different approach could work without triggering CSP.
Adblockers need to play whack-a-mole with this URL list to provide mocks that pretend to be ads to anti-adblock mechanisms, updating that declaration with extension updates every few hours will only lead to frustration.
Chrome's security policies are a nightmare to develop on so install your Chrome extension disabling Cors or whatever you need to.
I wonder what the number of extensions look like excluding the ones you want them to tamper the headers.
Edit: typo.
Chrome could make things much easier for developers, and arguable safer, by offering some straightforward way for an extension to interact with a page that doesn't involve messing with CSP headers.
In my mind, it's similar to when people hand-wring about extensions requesting access on all URLs. The security model for extensions is not fine-tuned enough to enable better behavior. It railroads extensions into over-requesting access to everything. I consider this to be a serious problem, but... I don't know, it doesn't talked about that much. To be fair, the web makes granular permissions difficult, and also to be fair Manifest V3 does try to make things more granular, in at least some ways. It's easier to make an extension now that only operates on some pages. But building limited extensions that don't have a lot of power is still somewhat difficult.
But regardless, I don't believe any of this is actionable advice you can use for your own pages. Which is good, because as a website author, you should not have the ability to override the user's decision about how extensions interact with your page; I would consider that to be an anti-web, anti-user sentiment in most cases. Websites don't get to decide what code can be run in an extension.
[1]: Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].
Then the process of developing an extension could be:. (1) request all permissions. (2) write code for extension. (3) run extension in test session and exercise all functionality. (4) let tool suggest the correct set of required permissions, which can be very granular.
This means the developers don't need to know the precise details of each of hundreds of permissions.
I only install a few extensions that I need and trust but it would be very nice to be able to limit potential damages.
It's also a problem at the workplace due to people having all kinds of dev related extensions with full access to everything
There are lots of legitimate use-cases to disable this stuff.
The use of the verb "tamper" instead of "modify" further reinforces the authoritarian spin.
Good. It drives me crazy how many user agents modify our site somehow, immediately footgun themselves by honoring the CSP, and then send us a report about it.
Fully disabling the CSP is reckless overkill but they should indeed be modifying it.
For this reason I treat extension ecosystem as non-existent.
As long as the research doesn’t allude that every extension is malicious, then it’s covered. While maybe it doesn’t belong in the research itself, someone could publish it in a separate blog post or gist.
That's actually the complete list of plugins I have, uBlock Origin, Privacy Badger, SponsorBlock and RES.
Why wouldn't this same idea apply to any other extension? You are right, everything is potential malware (the two extensions you mentioned included). There is nothing magical about the two extensions you mentioned.
And 1000s of eyeballs are on those works.
When is the last time you checked out the UBO Git?
Now extensions are a "security threat". Here we go...
Google has nigh-on monopoly power over the browser ecosystem. Also, extensions are by-and-large malware. Making people aware that extensions are mostly malware helps Google to consolidate its monopoly; but also (obviously) helps people to avoid malware.
We don't want Google to control the Internet, and we don't want browsers to be full of malware. That's a dilemma. It has no obvious solution. But it's better to be aware of the dilemma — and so realize there is no easy solution — than to ignorantly push for one side or the other to "win."
Google could be educating users to make their own responsible decisions, but it's far more profitable to keep them uninformed and feed them propaganda to maintain the paranoia that lets it monetise and take control away from them. Being ultimately an ad company, it thrives on deception.
and so realize there is no easy solution — than to ignorantly push for one side or the other to "win."
Twenty years ago, what Apple Google Microsoft do today with their software would be widely considered adware/spyware. One side has already won the battle; we can't let it win the war.
"Give me liberty or give me death," as the famous saying goes.
The solution doesn't necessitate removing extensions, it just means potentially constraining the API surface of extensions in order to mitigate the attack surface.
Extension users do want the extensions to interact with pages, often including cross-origin requests. That is what extensions are for and they won't work with restricting API surface.
Every extension you install should be carefully vetted and only enabled as long as absolutely necessary. It's the top malware vector I see today.
Also, not all extensions run on every single site. Also, some extensions actually help in blocking malware, crypto-trackers etc so the potential upsides are also great.
This is not where I want computing to go, and we're all just playing cat-and-mouse games feigning "security" when really "we" just don't trust the "plebs" to administer their own machines and keep themselves safe. This is arguably where Android is already, so one need only look there to see the future of computing and how the browser and "security" is being used as a trojan horse to get there.
If you go to the average non-technical user's Chrome extensions tab, they have 10-12 extensions. 7 of them are actively malicious.
This isn't like a "hey, freedom allows you the freedom to make mistakes" thing. This is a "good practice hasn't even been attempted here, and it's the top vector of all bad things ever" thing.
It's fine for browser extensions to exist, they serve a purpose. However, all existing extension stores should probably delist the entirety of their collection, solely re-accept extensions which an actual software engineer has reviewed, and make it much harder than one click to inadvertently install one when a website asks you to.