Safari exploit can leak browser histories and Google account info

The flaw also affects third-party browsers on iPhones and iPads.

Apple device users appear to be vulnerable to a significant browser privacy flaw. According to 9to5Mac, FingerprintJS has disclosed an exploit that lets attackers obtain your recent browser history, and even some Google account info, from Safari 15 across all supported platforms as well as third-party browsers on iOS 15 and iPadOS 15. The IndexedDB framework (used to store data on many browsers) is violating the "same-origin" policy that prevents documents and scripts from one location (such as a domain or protocol) from interacting with content from another, letting appropriately coded websites deduce Google info from signed-in users as well as histories from open tabs and windows.

The flaw only compromises the names of the databases rather than the content itself. However, this would still be enough for a malicious site owner to grab your Google username, discover your profile picture and otherwise learn more about you. The history could also be used to piece together a rudimentary profile of the sites you like. Private browsing won't defeat the exploit, FingerprintJS said.

We've asked Apple for comment. FingerprintJS said it reported the issue on November 28th, however, and that Apple hadn't yet addressed it with security patches honoring same-origin policy. Until then, the only solution may be to either use a third-party browser on Macs or block all JavaScript, neither of which is necessarily an option.

By Jon Fingas

CONTINUED:

A bug in Safari 15 can leak your browsing activity, and can also reveal some of the personal information attached to your Google account, according to findings from FingerprintJS, a browser fingerprinting and fraud detection service (via 9to5Mac). The vulnerability stems from an issue with Apple’s implementation of IndexedDB, an application programming interface (API) that stores data on your browser.

A bug in Safari 15 can leak your browsing activity, and can also reveal some of the personal information attached to your Google account, according to findings from FingerprintJS, a browser fingerprinting and fraud detection service (via 9to5Mac). The vulnerability stems from an issue with Apple’s implementation of IndexedDB, an application programming interface (API) that stores data on your browser.

As explained by FingerprintJS, IndexedDB abides by the same-origin policy, which restricts one origin from interacting with data that was collected on other origins — essentially, only the website that generates data can access it. For example, if you open your email account in one tab and then open a malicious webpage in another, the same-origin policy prevents the malicious page from viewing and meddling with your email.

THERE’S NOT MUCH YOU CAN DO TO GET AROUND THE ISSUE

FingerprintJS found that Apple’s application of the IndexedDB API in Safari 15 actually violates the same-origin policy. When a website interacts with a database in Safari, FingerprintJS says that “a new (empty) database with the same name is created in all other active frames, tabs, and windows within the same browser session.”

This means other websites can see the name of other databases created on other sites, which could contain details specific to your identity. FingerprintJS notes sites that use your Google account, like YouTube, Google Calendar, and Google Keep, all generate databases with your unique Google User ID in its name. Your Google User ID allows Google to access your publicly-available information, such as your profile picture, which the Safari bug can expose to other websites.

FingerprintJS created a proof-of-concept demo you can try out if you have Safari 15 and above on your Mac, iPhone, or iPad. The demo uses the browser’s IndexedDB vulnerability to identify the sites you have open (or opened recently), and shows how sites that exploit the bug can scrape information from your Google User ID. It currently only detects 30 popular sites that are affected by the bug, such as include Instagram, Netflix, Twitter, Xbox, but it likely affects far more.

Unfortunately, there’s not much you can do to get around the issue, as FingerprintJS says the bug also affects Private Browsing mode on Safari. You can use a different browser on macOS, but Apple’s third-party browser engine ban on iOS means all browsers are affected. FingerprintJS reported the leak to the WebKit Bug Tracker on November 28th, but there hasn’t been an update to Safari yet. The Verge reached out to Apple with a request for comment but didn’t immediately hear back.

By Emma Roth

CONTINUED:

DISCLAIMER: FingerprintJS does not use this vulnerability in our products and does not provide cross-site tracking services. We focus on stopping fraud and support modern privacy trends for removing cross-site tracking entirely. We believe that vulnerabilities like this one should be discussed in the open to help browsers fix them as quickly as possible. To help fix it, we have submitted a bug report to the WebKit maintainers, created a live demo, and have made a public source code repository available to all.

GitHub - fingerprintjs/blog-indexeddb-safari-leaks-demo: Demo showcasing information leaks resulting from an IndexedDB same-origin policy violation in WebKit.

Demo showcasing information leaks resulting from an IndexedDB same-origin policy violation in WebKit. - GitHub - fingerprintjs/blog-indexeddb-safari-leaks-demo: Demo showcasing information leaks re...

GitHubfingerprintjs

In this article, we discuss a software bug introduced in Safari 15’s implementation of the IndexedDB API that lets any website track your internet activity and even reveal your identity.

We have also published a demo site to see the vulnerability in action:

Safari 15 IndexedDB Leaks

Information leaks resulting from an IndexedDB same-origin policy violation in WebKit (a browser engine primarily used in Safari, as well as all iOS and iPadOS web browsers).

A short introduction to the IndexedDB API

IndexedDB is a browser API for client-side storage designed to hold significant amounts of data. It’s supported in all major browsers and is very commonly used. As IndexedDB is a low-level API, many developers choose to use wrappers that abstract most of the technicalities and provide an easier-to-use, more developer-friendly API.

Like most modern web browser technologies, IndexedDB is following Same-origin policy. The same-origin policy is a fundamental security mechanism that restricts how documents or scripts loaded from one origin can interact with resources from other origins. An origin is defined by the scheme (protocol), hostname (domain), and port of the URL used to access it.

Indexed databases are associated with a specific origin. Documents or scripts associated with different origins should never have the possibility to interact with databases associated with other origins.

If you want to learn more about how IndexedDB APIs work check out the MDN Web Docs or the W3C specification.

The IndexedDB leaks in Safari 15

In Safari 15 on macOS, and in all browsers on iOS and iPadOS 15, the IndexedDB API is violating the same-origin policy. Every time a website interacts with a database, a new (empty) database with the same name is created in all other active frames, tabs, and windows within the same browser session. Windows and tabs usually share the same session, unless you switch to a different profile, in Chrome for example, or open a private window. For clarity, we will refer to the newly created databases as “cross-origin-duplicated databases” for the remainder of the article.

Why is this leak bad?

The fact that database names leak across different origins is an obvious privacy violation. It lets arbitrary websites learn what websites the user visits in different tabs or windows. This is possible because database names are typically unique and website-specific. Moreover, we observed that in some cases, websites use unique user-specific identifiers in database names. This means that authenticated users can be uniquely and precisely identified. Some popular examples would be YouTube, Google Calendar, or Google Keep. All of these websites create databases that include the authenticated Google User ID and in case the user is logged into multiple accounts, databases are created for all these accounts.

The Google User ID is an internal identifier generated by Google. It uniquely identifies a single Google account. It can be used with Google APIs to fetch public personal information of the account owner. The information exposed by these APIs is controlled by many factors. In general, at minimum, the user's profile picture is typically available. To learn more, refer to Google's People API documentation.

Not only does this imply that untrusted or malicious websites can learn a user’s identity, but it also allows the linking together of multiple separate accounts used by the same user.

Note that these leaks do not require any specific user action. A tab or window that runs in the background and continually queries the IndexedDB API for available databases, can learn what other websites a user visits in real-time. Alternatively, websites can open any website in an iframe or popup window in order to trigger an IndexedDB-based leak for that specific site.

How many websites are affected?

We checked the homepages of Alexa’s Top 1000 most visited websites to understand how many websites use IndexedDB and can be uniquely identified by the databases they interact with.

The results show that more than 30 websites interact with indexed databases directly on their homepage, without any additional user interaction or the need to authenticate. We suspect this number to be significantly higher in real-world scenarios as websites can interact with databases on subpages, after specific user actions, or on authenticated parts of the page.

We also saw a pattern where indexed databases named as universally unique identifiers (UUIDs) are being created by subresources, specifically ad networks. Interestingly, loading of these resources seems to be in some cases blocked by Safari’s tracking prevention features, which effectively prevents the database names from leaking. These leaks will also be prevented if the resources are blocked by other means, for example when using adblocker extensions or blocking all JavaScript execution.

Does Safari private mode protect against the leak?

Firstly, when followed, the same-origin policy is an effective security mechanism for all window modes. Websites with one origin should never have access to resources from other origins regardless of whether a visitor is using private browsing or not unless it’s explicitly allowed via cross-origin resource sharing (CORS).

In this case, private mode in Safari 15 is also affected by the leak. It’s important to note that browsing sessions in private Safari windows are restricted to a single tab, which reduces the extent of information available via the leak. However, if you visit multiple different websites within the same tab, all databases these websites interact with are leaked to all subsequently visited websites. Note that in other WebKit-based browsers, for example Brave or Google Chrome on iOS, private tabs share the same browser session in the same way as in non-private mode.

The leak was reported to the WebKit Bug Tracker on November 28, 2021 as bug 233548.

Demo

We created a simple demo page that demonstrates how a website can learn the Google account identity of any visitor. The demo is available at safarileaks.com. If you open the page and start the demo in an affected browser, you will see how the current browsing context and your identity is leaked right away. Identity data will only be available if you are authenticated to your Google account in the same browsing session.

Moreover, the demo detects the presence of 20+ websites in other browser tabs or windows, including Google Calendar, Youtube, Twitter, and Bloomberg. This is possible because database names, which those websites interact with, are specific enough to uniquely identify them.

The supported browsers are Safari 15 on macOS, and essentially all browsers on iOS 15 and iPadOS 15. That is because Apple’s App Store guidelines require all browsers on iOS and iPadOS to use the WebKit engine.

Try the demo

Reproducing the leak

To reproduce the leak yourself, simply call the indexedDB.databases() API. In case websites opened in other frames, tabs, or windows interact with other databases, you will see the cross-origin-duplicated databases.

Based on our observations, if a database is deleted, all related cross-origin-duplicated databases are also deleted. However, there seems to be an issue when developer tools are opened and a page refresh happens. On every page refresh, all databases are duplicated once again and seem to become independent from the original databases. In fact, it’s not even possible to delete these duplicated databases by using the regular indexedDB.deleteDatabase() function.

This behavior makes it very difficult to use the developer tools to understand what exactly is happening with the databases that a website interacts with. It is therefore recommended to use other means of debugging (for example rendering output into the DOM instead of using console logs or the JavaScript debugger) when trying to reproduce the leaks described in this article.

How to protect yourself

Unfortunately, there isn’t much Safari, iPadOS and iOS users can do to protect themselves without taking drastic measures. One option may be to block all JavaScript by default and only allow it on sites that are trusted. This makes modern web browsing inconvenient and is likely not a good solution for everyone. Moreover, vulnerabilities like cross-site scripting make it possible to get targeted via trusted sites as well, although the risk is much smaller. Another alternative for Safari users on Macs is to temporarily switch to a different browser. Unfortunately, on iOS and iPadOS this is not an option as all browsers are affected.

The only real protection is to update your browser or OS once the issue is resolved by Apple. In the meantime, we hope this article will raise awareness of this issue.

By Martin Bajanik, FingerprintJS

Safari exploit can leak browser histories and Google account info

Safari exploit can leak browser histories and Google account info The flaw also affects third-party browsers on iPhones and iPads. Apple device users appea...

fml.lol forumfml