A team of researchers from the University of Wisconsin-Madison has uploaded to the Chrome Web Store a proof-of-concept extension that can steal plaintext passwords from a website's source code 

An examination of the text input fields in web browsers revealed that the coarse-grained permission model underpinning Chrome extensions violates the principles of least privilege and complete mediation.

Additionally, the researchers found that numerous websites with millions of visitors, including some Google and Cloudflare portals, store passwords in plaintext within the HTML source code of their web pages, allowing extensions to retrieve them. 

Source of the problem

The researchers explain that the problem concerns the systemic practice of giving browser extensions unrestricted access to the DOM tree of sites they load on, which allows accessing potentially sensitive elements such as user input fields.

Given the lack of any security boundary between the extension and a site's elements, the former has unrestricted access to data visible in the source code and may extract any of its contents.

Additionally, the extension may abuse the DOM API to directly extract the value of inputs as the user enters them, bypassing any obfuscation applied by the site to protect sensitive inputs, and stealing the value programmatically.

The Manifest V3 protocol that Google Chrome introduced, and adopted by most browsers this year, limits API abuse, prohibits extensions from fetching code hosted remotely that could help evade detection, and prevents the use of eval statements that lead to arbitrary code execution.

However, as the researchers explain, Manifest V3 does not introduce a security boundary between extensions and web pages, so the problem with content scripts remains. 

Uploading a PoC on the Web Store

To test Google's Web Store review process, the researchers decided to create a Chrome extension capable of password-grabbing attacks and try to upload it on the platform.

The researchers created an extension posing as a GPT-based assistant that can:

1. Capture the HTML source code when the user attempts to login on a page by means of a regex.
2. Abuse CSS selectors to select target input fields and extract user inputs using the '.value' function.
3. Perform element substitution to replace JS-based obfuscated fields with unsafe password fields.

The extension does not contain obvious malicious code, so it evades static detection and does not fetch code from external sources (dynamic injection), so it is Manifest V3-compliant.

This resulted in the extension passing the review and getting accepted on Google Chrome's Web Store, so the security checks failed to catch the potential threat.

The team followed ethical standards to ensure no actual data was collected or misused, deactivating the data-receiving server while only keeping the element-targeting server active.

Also, the extension was set to "unpublished" at all times so that it wouldn't gather many downloads and was promptly removed from the store following its approval. 

Potential for exploitation

Subsequent measurements showed that from the top 10k websites (as per Tranco), roughly 1,100 are storing user passwords in plain text form within the HTML DOM.

Another 7,300 websites from the same set were deemed vulnerable to DOM API access and direct extraction of the user's input value. 

The technical paper the researchers at the University of Wisconsin-Madison published earlier this week claims that approximately 17,300 extensions in the Chrome Web Store (12.5%) secure the required permissions to extract sensitive information from websites.

Several of those, including widely used ad blockers and shopping apps, boast millions of installations.

Notable website examples of lack of protections highlighted in the report include:

• gmail.com – plaintext passwords on HTML source code
• cloudflare.com – plaintext passwords on HTML source code
• facebook.com – user inputs can be extracted via the DOM API
• citibank.com – user inputs can be extracted via the DOM API
• irs.gov – SSNs are visible in plaintext form on the web page source code
• capitalone.com – SSNs are visible in plaintext form on the web page source code
• usenix.org – SSNs are visible in plaintext form on the web page source code
• amazon.com – credit card details (including security code) and ZIP code are visible in plaintext form on the page's source code

Finally, the analysis showed that 190 extensions (some with over 100k downloads) directly access password fields and store values in a variable, suggesting that some publishers may already be trying to exploit the security gap.

BleepingComputer reached out to the mentioned companies to ask if they plan to remediate the risks highlighted in the paper, and so far we've received responses from Amazon and Google: 

At Amazon, customer security is a top priority, and we take several steps to protect it. Customer information entered into Amazon web sites is secure.

We encourage browser and extension developers to use security best practices to further protect customers using their services. 

by Amazon spokesperson

A Google spokesperson has confirmed that they're looking into the matter, and pointed to Chrome's Extensions Security FAQ that does not consider access to password fields a security problem as long as the relevant permissions are properly obtained.