Thousands of Chrome Extensions Are Tampering With Security Headers (therecord.media) 31
An anonymous reader quotes a report from The Record: Thousands of Google Chrome extensions available on the official Chrome Web Store are tampering with security headers on popular websites, putting users at risk of a wide range of web-based attacks. While they are a little-known technical detail, security headers are an important part of the current internet landscape. At a technical level, a security header is an HTTP response sent by the server to a client app, such as a browser. [...] In a paper presented at the MADWeb workshop at the NDSS 2021 security conference, researchers from the CISPA Helmholtz Center for Information Security said they tried to assess the number of Chrome extensions tampering with security headers for the very first time. Using a custom framework they built specifically for their study, the research team said they analyzed 186,434 Chrome extensions that were available on the official Chrome Web Store last year. Their work found that 2,485 extensions were intercepting and modifying at least one security header used by today's Top 100 most popular websites (as available in the Tranco list).
The study didn't focus on all security headers, but only on the four most common ones, such as: Content-Security Policy (CSP), HTTP Strict-Transport-Security (HSTS), X-Frame-Options, and X-Content-Type-Options. While 2,485 extensions disabled at least one, researchers said they found 553 disabling all the four security headers they analyzed in their research. The most commonly disabled security header was CSP, a security header that was developed to allow site owners to control what web resources a page is allowed to load inside a browser and a typical defense that can protect websites and browsers against XSS and data injection attacks. 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. However, even if the extensions wanted to enrich a user's experience online, the German academics argued that by tampering with security headers, all the extensions did was to expose users to attacks from other scripts and sites running inside the browser and on the web.
The study didn't focus on all security headers, but only on the four most common ones, such as: Content-Security Policy (CSP), HTTP Strict-Transport-Security (HSTS), X-Frame-Options, and X-Content-Type-Options. While 2,485 extensions disabled at least one, researchers said they found 553 disabling all the four security headers they analyzed in their research. The most commonly disabled security header was CSP, a security header that was developed to allow site owners to control what web resources a page is allowed to load inside a browser and a typical defense that can protect websites and browsers against XSS and data injection attacks. 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. However, even if the extensions wanted to enrich a user's experience online, the German academics argued that by tampering with security headers, all the extensions did was to expose users to attacks from other scripts and sites running inside the browser and on the web.
Bad design choices (Score:4, Interesting)
Extensions and JS APIs should probably not have much or any access to the protocol level. They should only be able to operate at the mess/document level.
Obviously some minimal stuff like READ ONLY access to response headers, the ability to ADD custom request headers and URL parameters (obviously) is probably needed but you should not be able to modify any of the default request headers from what the browser ordinarily generates according to the usual rules.
As long as the Browser has to be 'all the things' its going to always be a security black-hole.
Re:Bad design choices (Score:5, Interesting)
Right - that's fine. The point is its your computer you don't want content in the browser able to change the rules probably. Because that means SOMEONE ELSE can do what they want with it :-)
There was good solution to this that existed before a bunch of unthinking shitheads pushed HTTPS everywhere without addressing really any of the very fundamental problems with authentication around that.
You used to be able to easily setup tools like Privoxy that could do things OUTSIDE the browser and therefore beyond the reach of some nastiness in a third party script sourced from who-knows-where. Google made sure to break that.
We get an extension framework now that is ineffective when it comes to privacy tools and ad-blocking and way more insecure at the same time than the old way. Thanks Google, I guess it 'was your computer'
Re:Bad design choices (Score:4, Interesting)
What we really need is a "proxy" that runs on localhost that all browsers talk to. That proxy is then responsible for filtering, blocking JS etc, etc, etc and you can run multiple browsers without having to configure each one separately for this stuff.
I'm using squid as a MITM proxy (a lot of peek and splice, a bit of peek and bump) but it has its problems over something designed into the browser properly.
Re:Bad design choices. But of what? (Score:4, Insightful)
Or bad design of the extensions. A lot of entries in our CSP violations log come from browser extensions injecting all kinds of crap into the visited web pages.Those injections should be done through an independent request, not injected as if the HTML of a page requests for it.
I am surprised that such behaviour is not filtered out by the browser makers as malicious.
I would argue against limiting any extension the access to headers, because that would also block extensions that let the user control those headers.
Re: Bad design choices (Score:4, Insightful)
I think there's a nice middle ground with appropriately presented security dialogs. If the extension asks me if I will allow it to "hijack private communications", I can make an informed decision.
Re: (Score:2)
That means you can never write a cookie manager, or a privacy manager because cookies are added to the HTTP header by the browser. A cookie manager will need to be able to delete those header entries to n
Browser should have stuck to displaying content (Score:5, Insightful)
ie, be a dumb static text and graphics display system with maybe some basic input ability, and not become some kind of pseudo-OS with all the pitfalls that entails. If the browser stack was a half decent design it wouldn't be so bad but the appalling mashup of HTML, CSS, javascript and all the other poorly implemented "technologies" involved designed by 2nd raters and used by 3rd raters just makes things far worse than they should be.
Re: (Score:2)
Which is what the browser is doing. But it seems that a bunch of extensions are fiddling with the 'content' (which I take to include the headers) before the browser gets it.
Re: (Score:3)
Congrats on completely missing the point. If you didn't have javascript in the first place you couldn't have plug-ins to fiddle with the content.
Where's the list of extensions? (Score:5, Insightful)
So which extensions are we talking about here?
I would like to be able to uninstall any offending extensions I may be using if we could see a list of these 2485 items.
Re: (Score:2)
Re: (Score:2)
Don't Install Thousands of Extensions (Score:2)
Re: (Score:3)
Don't use chrome, problem solved
er (Score:2, Informative)
The whole point of browser extensions is to modify how the browser operates.
If that's just too terrifying, then don't build a browser that allows extensions.
Re: (Score:2)
Don't force the user to make all-or-nothing decisions when granting/denying permissions.
Developers are lazy (or malicious) and frequently ask for more than they need. I should be able to deny subsets of the requested rights and suffer the breakage that may incur or feedback about it.
There should not be thousands of extensions (Score:2)
There should not be thousands of extensions in the first place. That makes security auditing difficult and is a waste of time.
There are not thousands of tasks requiring extensions. Adblocking, accessibility and other FUNCTIONALLY VALUABLE extensions are a worthy use of the ability to add them. That's not a huge number.
It should not be a matter of "what is not excluded is permitted" but of "what is deemed necessary after thorough security review and functional justification" is permitted and those not liking
How much is too many? (Score:2)
Yet more problems with Chrome it seems (Score:2)
The big complaint I have with Chrome is how it allows extensions to just get installed/added without asking the user if the extension was authorized. Picture if programs could just install themselves in the background without your knowledge or intent, which is what Microsoft addressed with User Account Control back in the days of Vista. Firefox will verify that you meant to install a plugin or not, Chrome just lets any junk go in.
No shit Sherlock (Score:1)
Find me a webapp that doesn't... (Score:2)
Seriously.
I've been building enterprise web apps for 20yrs, and at least 3/4 of them have had to fuck with these headers in *some* way to get around one bug or another.
And that's for apps where the company owns everything: hardware, software, switches & data lines etc...
"Security" (Score:2)
These security headers are a bad idea in the first place. At best they're telling the browser, "Pretty please follow these rules." The user *should* be able to install a browser extension that modifies the content, including headers, regardless of the advice of the web site sending it.
Maybe the browser should have some sort of "I know what I'm doing" click-through before allowing the installation of such extensions. But if a user wants to arm the foot-gun in order to improve their experience, more power