Exploiting IndexedDB API information leaks in Safari 15

https://fingerprintjs.com/blog/indexeddb-api-browser-vulnerability-safari-15/

by danpinto • 5 years ago

250 92 5 years ago

keewee7• 5 years ago

The IndexedDB API in Safari has been buggy and unstable for a very long time.

gwill• 5 years ago

new bugs all the time too. in iOS 13 i found a bug where getting data from a store by key would ignore whatever store you pass it, so it would return data from every store that matched the key.

mrweasel• 5 years ago

Given that there’s really no way around Safari on the iPhone, developers should perhaps just not use IndexedDB if the browser is Safari, given how buggy the implementation is.

It pretty clear that Apple isn’t giving Safari/WebKit the focus it needs, but it’s also clear that developers just continue to push for more and more features in the browser. I’d much prefer that browsers started to cut back. While Google is excellent about updates, remember that critical bugs are found in Chrome constantly.

easrng2• 5 years ago

The problem is there's no alternative. LocalStorage is synchronous and has low limits, but works OK for things like preferences and auth tokens. If you are doing anything bigger like editing files then IndexedDB is your only option.

LAC-Tech• 5 years ago

Maybe the way forward is to forge ahead without Safari, until pressure from customer forces them to implement this (and other web features).

Already on chrome we can go to a URL, click the 'install' button, and have an app on our desktop/homepage. No app store, no massive download. I sincerely hope this is the future and not brilliant dead-end HN will be nostalgic about in 10 years.

cglong• 5 years ago

Unfortunately, if I advertised my webapp as "Works Best in Chrome", people would claim I was "supporting the browser monoculture".

iqanq2• 5 years ago

What the web needs is fewer APIs.

capableweb• 5 years ago

What we need are companies working on browsers that actually care about the web. Apple have demonstrated time and time again that they don't, because they favor native applications on iOS and macOS over anything web, so we end up with subpar browsers who ship with the OSes. In some cases (iOS), we even end up with a browser-monopoly where no other browser is even welcome.

iqanq2• 5 years ago

It's good that Apple doesn't care about the web, because that means that developers can't rely on the APIs that Apple refuses to implement, meaning that in the end the web ends up with fewer APIs that can be used in practical terms.

cmsj2• 5 years ago

What we need is the web to stop coalescing ever more tightly around Google.

Apple's iOS browser monopoly is literally the only thing preventing Google from having a near total monopoly on web standards.

eyelidlessness2• 5 years ago

Apple has been rapidly addressing shortcomings in WebKit and significantly expanding its team over the last year (at least). They’re clearly investing, so they clearly care in that sense. It’s also obvious that that rapid pace and onboarding could produce defects. But I don’t think it’s accurate at all to say they don’t care about the web.

finiteseries3• 5 years ago

iOS sure but native mac applications are dead, D-E-A-D, muerto, morte, morto etc on macOS and have been almost entirely ejected in favor of web based SAAS and electron apps over the past 4 years.

I genuinely can’t name a native application released for macOS built with AppKit or SwiftUI or whatever that didn’t come from Apple.

eyelidlessness2• 5 years ago

I mean, I’m not agreeing or disagreeing (and I’ve felt both ways depending on context and mood), but it’s not like this is an exceptionally new API.

baybal2• 5 years ago

I fully support you. Now, getting rid of obsolete, and dead APIs, and features is way more important than adding new ones.

I can recall a dozen of XSLT implementation bugs which were in Chrome from day 1.

XSLT is not going anywhere from browsers, but they also cannot be fixed, because there is so few people using XSLT today to raise above the noise floor for WebKit devs.

argvargc• 5 years ago

and in all browsers on iOS and iPadOS 15

Wow. I wonder what Brave thinks of this?

streptomycin• 5 years ago

All browser vendors are very unhappy that Apple only allows their browser engine on iOS. For security and many other reasons.

kyriakos4• 5 years ago

Security in this case is broken by actually forcing the browser engine monopoly on ios.

parhamn• 5 years ago

It's very interesting seeing exploits like this from this organization. On one hand their service fingerprints users and offers extended metadata like whether the user is in incognito via sketchy web apis.

On the other hand they report (and help close) some gnarly exploits like this via sketchy web apis.

What do you all make of this? It's hard to not see it as some weird "were not doing a bad thing" gaslighting (perhaps even internally to their team).

toomuchtodo• 5 years ago

Managing the Overton window and anchoring wrt browser tracking.

codeptualize• 5 years ago

I had the same thoughts; it seems to present a friendly picture but there are a lot of unanswered problems with this technology, even if only used for fraud protection.

What if clients use it for tracking and other shady purposes, would they do something about it?

Btw I tried with Tor Browser and it did not accurately fingerprint it between sessions which makes me wonder how effective it really is. Especially for fraudsters; intentional bad actors, I think it would be quite easy to bypass.

tinus_hn2• 5 years ago

This vulnerability exists whether they report it or not.

ezfe4• 5 years ago

It isn't properly fingerprinting me on Safari between incognito/non-incognito sessions either: https://i.imgur.com/80en4LY.png

There's also an extra session on one of my incognito tabs listed in the session history on the demo page.

matkoniecz• 5 years ago

Maybe they help to close exploits used by competition?

Or ones they are not planning to use anyway, but are possible to be used by competition?

Or for marketing purposes to be not known as 100% clearly evil?

Or for marketing purposes to be better known?

easrng2• 5 years ago

IndexedDB isn't sketchy, just annoying. It is the only semi-reliable way to store more than a few MBs of data with JS, but the API is awful and it's a pain to use without some kind of wrapper to make it bearable. (LocalForage is good, it provides a LocalStorage-like API on top of IndexedDB or some other APIs in older browsers.)

fabian2k• 5 years ago

The way they describe the behaviour when the dev tools are used with undeletable database copies being created, this just looks like the whole area is buggy. Which is of course not an excuse for this, but might also indicate that there could be even more attack surface there.

cmsj2• 5 years ago

it's almost like allowing websites to silently create databases on our computers, was a bad idea.

kitsunesoba3• 5 years ago

It would seem I’m not alone in thinking that many web features are too implicit. “Dialog fatigue” or “ok-click syndrome” are real problems, but for many features I think the correct behavior is probably not a silent grant. Anything that consumes the user’s resources after navigating away from the page should probably require direct user consent in some form or another.

jmull5• 5 years ago

This doesn't really have anything to do with IndexedDB being about databases.

davidatbu3• 5 years ago

Is it usual to disclose (what appears to me to be) a vulnerability with massive potential for exploitation towards disastrous ends, before the developers of the software have shipped a fix?

I guess I'm curious as to what the norms are around disclosure of such discovered vulnerabilities are in general.

Thorrez• 5 years ago

It's a hot topic of debate. Some people advocate for full disclosure, which means tell everyone as soon as you find it. The idea behind that is that attackers might have already found it and be exploiting it, so people should know in order to protect themselves. Others advocate for coordinated disclosure (sometimes called responsible disclosure, a controversial term[1]), with some sort of time limit. Google Project Zero does that with a 90-day time limit, with some exceptions to extend it or reduce it[2].

[1] https://news.ycombinator.com/item?id=12308246

[2] https://googleprojectzero.blogspot.com/2021/04/policy-and-di...

davidatbu3• 5 years ago

Forgot to say thanks for a well-cited and helpful response!

afavour• 5 years ago

The bug was filed in November. More than enough time for a fix. Eventually you have to go public to force Apple’s hand.

tinus_hn2• 5 years ago

It allows a site to see which other sites you have visited. It’s not that disastrous.

davidatbu3• 5 years ago

You have a point. I initially misread the article as suggesting that the entire DB from other sites was leaked.

Still though:

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.

agys• 5 years ago

What a mess Safari has become. It used to be my preferred browser for navigating AND developing but it has become less and less appealing, especially for the latter (I submitted several bugs to webkit, but my love is fading).

meibo• 5 years ago

Safari is hell nowadays, bad UX, not compliant with web standards - not just whatever API Google comes up this year, but basic CSS that's common and works in every other browser.

At my last web dev gig, we had to go and get Apple hardware because our visual tests kept failing on Safari. They need to get their shit together or let people port good browser engines.

michelb• 5 years ago

It’s clear that Safari is not a top prio at Apple, even though it’s probably the most important app on their operating systems. Contrast with Google that needs Chrome to exert their control over the web.

WhyNotHugo2• 5 years ago

Well, Apple does promote native apps a lot nowadays, whereas Google has mostly webapps (think ChromeOS), so Google can't really afford to have Chrome broken.

oefrha• 5 years ago

Safari 14 had this nasty IndexedDB bug last year: https://bugs.webkit.org/show_bug.cgi?id=226547 and I had to add https://github.com/jakearchibald/safari-14-idb-fix to all my sites using IndexedDB. Now this. Why the hell are they messing with IndexedDB?

Last IDB shitstorm was discussed at https://news.ycombinator.com/item?id=27509206.

tehbeard• 5 years ago

I'm currently fighting a safari IDB bug where blobs stop being returned or all reference the same data.

Apple just doesn't care about IDB or the web.

matt7340• 5 years ago

IndexedDB on Safari has had issues it feels like since day one. IIRC there was a full rewrite somewhere along the way too, and still problems seemingly every Safari release. My favorites were the iOS upgrades that simply deleted all IDB data.

Super frustrating, makes me glad I’m not currently building anything that relies on significant local storage.

The web could fill so many needs instead of using apps, but with crap like this it’s no surprise that it still doesn’t.

sangeeth96• 5 years ago

How is this not a P1 thing in the iOS/iPadOS/macOS/security teams at Apple? Seriously? Bare minimum, why didn't they let people know about this? We know the whole "we care about privacy" thing is marketing fluff now but holy F this is just unacceptable.

And this kind of an issue is exactly why Apple needs to stop screwing around and do the following things ASAP:

1. Decouple Safari from the OS so that it can be updated independently to fix critical issues like this and deploy to all customers quickly

2. Let other browser engines on the platform for fuck's sake!

withinboredom• 5 years ago

Number 1 is number one on my list. I am literally (right now) just installed an old MBP from an empty disk. Literally could not use Safari to download another browser because it’s “updating.” So I’m literally watching a 10 minute progress bar just to download a browser.

callalex• 5 years ago

curl is pre-installed :)

ezfe4• 5 years ago

On macOS, it's already decoupled.

On iOS, there's nothing stopping them from releasing a critical fix to iOS that auto-installs as quickly as a decoupled update would.

cerved• 5 years ago

The title is too sensationalized. It leaks the names of IndexedDB databases.

This can in cases where the names follow a known pattern be used to infer domains of other websites in the session and, in the case of YouTube, your Google id which can be used to identify your Google account.

The vulnerability doesn't leak all your browsing history. It leaks a small part of it

edit: title is changed now

mulmen5• 5 years ago

I rarely (never?) see Apple engineers posting in these threads. With other big tech organizations some kind of insider insight is occasionally provided.

Is Apple’s culture of secrecy that strong? Is it a sense of superiority? Is it embarrassment? Are they just not here?

As a mid-career engineer with highly marketable skills and an inbox stuffed with job offers the only two companies I would never entertain an offer from are Facebook and Apple.

Facebook because their fundamental purpose for existence is harmful to society and Apple for their perceived (or actual?) engineering incompetence.

I don’t really have a sense for the kind of engineer that works for Apple. With other big tech orgs I have some sense, even if informed almost entirely by tech forums.

gleenn• 5 years ago

Why does (near) silence equate to incompetence?

mulmen5• 5 years ago

My perception of Apple’s (software) engineering capabilities comes from being their customer and using their products daily.

This might be different if I had some perception of what was happening internally or how problems are approached. But from what I see nobody at Apple cares. So the silence contributes to the perception of incompetence by not counter-acting it.

ksec2• 5 years ago

I rarely (never?) see Apple engineers posting in these threads.

You mean on HN? Oh they do, From JSC to Webkit Engineers. Mostly on technical discussions.

mulmen5• 5 years ago

Maybe I’m just not reading the right threads then. It’s all a perception.

nicoburns• 5 years ago

I believe it’s considered a durable offence to give out secret information at Apple. Similar, with few exceptions, Apple employees are not allowed to contribute to open source projects.

It’s a shame really, because otherwise I think I’d quite like working at Apple. Their laser focus on product is right up my street.

mobileexpert• 5 years ago

Apple’s tight-fisted control of browser engines on iOS leads to worse security and privacy for the whole platform.

fabiospampinato• 5 years ago

It's sad how buggy IndexedDB is in Safari, and in general how much pain Safari causes to web developers and consequently their users.

I hope regulators will eventually force support for other browsers (that can install apps) in iOS, I don't understand how Apple is allowed to have such a tight control on the market.

ezfe4• 5 years ago

As an aside, this is awkward for Fingerprint JS: https://i.imgur.com/80en4LY.png

Exploiting IndexedDB API information leaks in Safari 15

Related Stories