Researchers at browser identification company FingerprintJS recently discovered and disclosed a Fascinating data breach A bug in Apple’s web browser software.
Technically, the vulnerability exists in Apple’s open-source WebKit browser engine, which means it affects any browser that relies on WebKit.
As you might expect, this includes all versions of Apple’s own Safari browser, whether you’re running it on macOS, iPhone or iPad.
But on iOS and iPadOS, even non-Apple browsers that typically don’t use WebKit at all, Apple’s own App Store rules require dropping their regular base and using WebKit.
For example, on Windows and Linux, Firefox uses its own Gecko rendering engine; Microsoft Edge, Google Chrome, and many other browsers are based on Google’s Blink renderer.
Although Blink was originally derived from WebKit, this forked project is now separate and distinct from Appke’s current WebKit codebase.
Therefore, Safari on macOS and almost any browser you use on your iPhone or iPad will be affected by this bug.
A little leak goes a long way
At first glance, the breach sounds unremarkable and unimportant: Although it allows private data to leak between separate browser tabs containing content from unrelated websites, the amount of data leaked is insignificant.
From the very beginning, WebKit made it possible for websites to set up and store so-called stateful data – Information from one visit to the site to the next, traditionally via web cookies.
Cookies are used to remember display settings (such as light mode vs. dark mode), track repeat visits (such as by assigning you a unique visitor ID that can be matched next time), and allow you to log in with a password (such as by record a secret temporary access code called an authentication token).
Historically, cookies were sent in the headers of every web request to the site where they were originally set, so they were not a very efficient way to record web session state: whenever you visit site X, you should send the Point X sets all cookies, even those unrelated to the page you are currently visiting.
Therefore, modern browsers also provide a client-side database called cloud storage Accessible only as needed by JavaScript code in a website page; you’ll often hear the word “cookie” used to encompass both biscuits (sent in every web request, so works even with JavaScript turned off) and cloud storage (Only used when needed, but not available unless JavaScript is enabled).
As you can imagine, data stored in cookies and web storage is not suitable for disclosure to anyone because it often identifies you loosely and often accurately – for example, by granting access to private data on an online account, Such as your name, address, contact details, credit card data, and the password reset page for that account.
Therefore, browsers should enforce the so-called Same Origin Policy (SOP), according to which web data created by website X can only be read by website X.
In fact, the SOP is stricter than this: the protocols used must match (this prevents HTTPS cookies like passwords or your real name from being exposed over HTTP); the server names must match (in order to come from two different clients that happen to be hosted on the same IP number) services that don’t match incorrectly); and the TCP ports used must match (this makes it harder for an impostor with only partial access to your network to set up parallel services on existing servers that differ only by using different ports).
More and more in browsers
Unfortunately, the irony is that today’s cloud-centric world means we run more and more applications in our browsers.
Even the web storage systems we mentioned above are specifically designed to bypass the performance limitations of old-school HTTP cookies…
…when browser-based applications such as document processing systems or image editors need to manage and process large amounts of locally cached data, it turns out to be insufficient.
So, we now have three types of local storage: biscuits, great for simple setups such as pagestyle=dark; cloud storage, for larger chunks of data, such as configuration settings and moderately sized documents; and a local database system called index database, when you need to keep a lot of data and access it efficiently.
Excellent as Mozilla Reference page put it:
IndexedDB is a low-level API for client-side storage of large amounts of structured data, including files [and binary chunks]. This API uses indexes to enable high-performance searches on this data. While Web Storage is useful for storing small amounts of data, it is less useful for storing large amounts of structured data. IndexedDB provides a solution.
IndexedDB is not a full SQL database, but it is capable of storing, indexing, searching, and retrieving larger local databases than you can effectively manage with Web Storage.
Complexity, the enemy of security
Given that complexity is the enemy of security, you can guess what’s going on here.
It turns out that Apple’s implementation of IndexedDB functionality includes a function called indexedDB.databases() that returns a list of all IndexedDB databases currently known to the browser.
Ana While your site can only access databases that match the SOP (so you can’t open IndexedDB created by other sites and read at will)…
…you can access the full list of current database names, regardless of which web page originally created them.
Your first thought might be, “So what? A database name doesn’t reveal much, even if it does reveal anything.”
But stop thinking about it this way for now.
Imagine you have a special directory on your hard drive called PersonalData that contains files that are very important to you, such as ReplyToTaxAudit2016.docs, SpeedingFineLegalAppeal.pdf, PasswordsForHostingCompany.txt, and DNSCoRenewalInfo.xls.
You wouldn’t want to publish these filenames, which themselves, while much less useful to crooks than the actual content, still reveal personal information that could easily aid future attacks on you.
Even in the artificial example above, the filename alone can reveal your affiliation with the tax office; imply that you’re in trouble with driving-related criminal charges; and disclose information about some of the IT companies you use.
For the IndexedDB database name, FingerprintJS noticed that some services (such as Google) use your account’s unique identifier (your Google user ID) in the string naming the Google-specific IndexedDB.
Even if an attacker can’t tell you who you are via that Google user ID, the fact that it’s consistent no matter when you log into Google means that it’s at best a ‘super cookie’ that identifies you’ as the same Users visit other websites, even if you have Tracking Protection turned on to prevent websites from automatically sharing cookie data with each other.
And FingerprintJS reports that the “filename” (for a better word) that other services choose as their IndexedDB identifier often uniquely identifies the service, even if they don’t uniquely identify a particular user.
This means that the list of names exposed by the indexedDB.databases() function in JavaScript can act as a sort of “history list” for rogue websites: by extracting the IndexedDB name list in the browser, crooks can easily learn more about the network than you have recently used expectations of applications and online services.
It’s kind of like a situation where anyone can just see the cover of the passport – not even the picture page, just the outside! – Leave with a full list of all the countries you’ve recently visited.
This is not a complete privacy disaster…
…but definitely shouldn’t work that way!
what to do?
- On macOS, you can simply use a different browser until Apple releases a fix. As mentioned above, browsers such as Firefox, Edge and Chrome do not use the WebKit engine and do not have this bug.
- On iDevices, you can slightly reduce the risk by periodically clearing website data. Switching to a different browser doesn’t help because all App Store browsers use WebKit internally. Also, clear network data (set up > safari > Clear history and data) usually means that you need to log in and readjust your preferences for every website you’ve used recently. Of course, once you use any of these sites again, the IndexedDB list will be updated again.
- Watch Apple’s Security Advisory page for updates. According to FingerprintJS, Apple recently acknowledged the problem and started adding fixes to the WebKit open source code. Sadly, Apple refuses to announce its date until a security fix is released, so we don’t know how long it will be before a patch is released.
