Bug in WebKit’s IndexedDB implementation makes Safari 15 leak Google account info… and more
An improperly implemented API that stores data on browsers has caused a vulnerability in Safari 15 that leaks user internet activity and personal identifiers.
The vulnerability was discovered by fraud detection service Fingerprint JS, which has contacted the WebKit maintainers and provided a public source code repository.
As of 28 November last year, the issue had not been fixed, so the team at Fingerprint JS decided to make the finding public to encourage the expedition of its repair.
The commonly used low-level JavaScript API, called IndexedDB, follows same-origin policy, meaning documents or scripts associated with one origin should not interact with resources associated with other origins. A webpage opened in one tab of the browser should not be able to share data with the next tab, for obvious reasons, such as if one tab was used to access a user’s bank and the other a malicious website.
But in the case of this particular indexed database, the separate pages do interact, putting the user at risk. When using Safari 15, which relies on IndexedDB, every time a website interacts with a database, a new empty one with the same name is created in all active frames, tabs, and windows in the same browser session. This results in other websites having access to the name of the databases. The Safari bug can then expose publicly available information from, say, a Google account.
Users logged into their Google account will have their unique Google User ID placed into the database’s name. Database names can then be used to extract identifying information from a lookup table if sites scrape the Google User ID and use it to find personal information.
But not only can a malicious website learn the user’s identity, it can stitch together multiple separate accounts from the same user without that person even doing anything, other than running a window in the background. The malicious website can open other websites, if programmed in an iframe or popup, and thus open a Pandora’s box of leaking data.
Fingerprint JS made a video explaining the process:
The team found that more than 30 websites out of the Alexa Top 1000 interacted with indexed databases on their homepage without the user doing anything, and they reckon there are tons more out there.
Sadly, browsing in Private Mode didn’t solve the problem, although the extent of information available via the leak is more limited by nature of the tool.
The fraud detection service created a demo to identify the sites a Google account user has open or opened recently. It looks for over 20 specific websites it knows are problematic when used in combination with Safari 15 on macOS, iOS 15 or iPadOS 15 as Apple requires WebKit be used with those browsers, and a Google account.
Other than blocking JavaScript, not using Google accounts or switching to different browsers if available (not available for iOS and iPadOS) while surfing the web on an Apple product, there’s not much to be done other than wait it out, said the team.
It’s all a bit ironic given that in June 2020, Apple refused to implement 16 web APIs into Safari’s WebKit engine, claiming they posed a privacy threat. Some researchers applauded the move as a win for privacy, but many met the decision with derision, saying the action was done to force the use of native iOS apps and the income they bring in.
Of course, this sort of our-product-only approach goes beyond browsers for the company. Just last week Apple was forced to stop dragging its feet and allow third-party app billing systems in Korea per the country’s Telecommunications Business Act. Google was given a command to do the same in September and compiled in November – over two months prior to Apple.
Steamrolling use of WebKit and thus IndexedDB has been problematic in the past. A bug in Safari 14.1.1 on macOS 11.4 and iOS 14.6 that manifests when applications first try to use IndexedDB NoSQL manager to store data caused user outrage last June. One open-source developer referred to Apple as being “outright hostile to the web.” ®
READ MORE HERE