Why do Googlers enthusiasts make radical changes to Chrome? Because they created a monster. And are fighting to secure it • The registry

Analysis In a slight public relations blitz, Google's engineers insisted this month that the advertising giant's changing Chrome browser extensions will not kill ad blockers. Instead, we are told, Googlers make plugins safer. These engineers have more work to do than it may seem.

Leaving aside for a moment Google's public reports about the threat of ad blockers and the steps Google has taken in the Google Play store to limit interference with mobile ads, the Internet goliath has Reasons to revamp its Chrome Extension ecosystem – because it's as fragile as a house of cards.

Google insists that it is facing the situation, noting that the installations of malicious extensions have decreased by 89% since early 2018. But the Tech Titan coders are still attacking the cause fundamental: a platform with few guardrails.

Chrome extensions have an obvious utility for developers and users. They can enhance privacy, add features and enhance the web surfing experience. But they are so powerful that they can easily be used and the security process set up by Google for the Chrome Web Store is not foolproof.

The main problem is that Chrome Extensions can cancel the browser security model and recover sensitive data. A reader who wrote to develop this question suggested that if people really understood how unrestrained chromium extensions are, they would get a score of 10.0 CVE and be banned from the companies.

This may seem exaggerated given that the API at the center of this mess, particularly blocking the capacity of the Web request The API will continue to be available to businesses once the current platform renovation is completed because it is very useful.

Raymond Hill, the developer of uBlock Origin, disagrees with this characterization because, he says, the ability to change headers is an intrinsic part of the design of the Web request API – not an oversight.

"There is no CVE problem here because the extensions are optional and what they can do is revealed to the users who choose to install them," he said in an email to The register.

But Google's platform design decisions have security implications. And Mozilla too, since Firefox also supports the Web request API for add-ons (aka extensions).

At the Canadian Security Conference, SecTor held in October of last year (that is, the very month that Google announced its Chrome extensions review plan, called Manifest v3), Lilly Chalupowski, developer of security applications at GoSecure, gave a presentation titled The Chrome Crusader.

Stripped security

Chalupowski has demonstrated that Chrome Extensions has the ability to remove HTTP headers, including security headers, from website interactions. The result is that it is trivial to design an extension that breaks the security model of the same browser origin.

As she put in a phone interview with The register, "The injection is a feature."

"When injection is a feature, it's at that point that you have to start worrying," said Chalupowski, "especially when you hand over a feature to edit secure headers." on the fly and change them literally.

During his demonstration, Chalupowski showed how to design a basic Chrome extension that interacts with the Flask command and control server – run locally for demonstration – in order to steal passwords from a service website. online banking.

It must be said that Google is monitoring malicious extensions, but Mr. Chalupowski has suggested some ways that villains could avoid detection.

Chalupowski has posted a PoC code on GitHub; The register has not yet determined whether changes to Chrome since the initial release of PoC code affect its functionality.

"uBlock Origin and a few others use this ability to modify headers for good purposes, for security reasons," she said. "At the same time, these same features will be used in Chrome and Firefox for malicious purposes."

And here's the problem: a developer with good intentions can create an advantageous extension code and a developer with bad intentions can use the same API to abuse the trust and steal information.

In 2010, when the Web request The API was under development, there had been discussions about the implications in terms of security and privacy, but this was not the main concern. The design document mentions the problem by passing:

Chrome extensions were even more open. Hills said that in 2013, Chrome extensions could see network requests from other extensions via the Web request API. It was a useful but also abusive feature and so it was removed.

Google may need to do Web request The risk is less, but among those who develop extensions, it is hoped that the price of security will not be an inefficient blocking of content and insufficient privacy controls.

Hill says Google should implement a finer authorization model to loosen the CORS and CSP headers. In this way, extensions that require certain features might require them directly rather than choosing a lower performing API. He also suggested Google to refuse the Web request API access to a larger number of request headers, as is already done in some cases.

"At the moment, the browser just relies on browser extensions, which is good," said Chalupowski. Changing that, she said, "is only good news for users."

For developers and users able to make responsible choices about the software that they install, it's a bit more complicated. ®