![](\"https:\/\/media.wired.com\/photos\/61e731353e654a13e9a16fc8\/master\/pass\/Security-iOS-15-Leak-107178697.jpg\"\/)
<\/p>\n<\/p>\n
Credit to Author: Dan Goodin, Ars Technica| Date: Wed, 19 Jan 2022 18:15:00 +0000<\/strong><\/p>\n Dan Goodin, Ars Technica<\/a><\/span><\/span><\/p>\n To revist this article, visit My Profile, then View saved stories<\/a>.<\/p>\n To revist this article, visit My Profile, then View saved stories<\/a>.<\/p>\n For the past<\/span> four months, Apple\u2019s iOS and iPadOS devices and Safari browser have violated one of the internet\u2019s most sacrosanct security policies. The violation results from a bug<\/a> that leaks user identities and browsing activity in real time.<\/p>\n This story originally appeared on Ars Technica<\/a>, a trusted source for technology news, tech policy analysis, reviews, and more. Ars is owned by WIRED's parent company, Cond\u00e9 Nast.<\/p>\n The same-origin policy<\/a> is a foundational security mechanism that forbids documents, scripts, or other content loaded from one origin\u2014meaning the protocol, domain name, and port of a given webpage or app\u2014from interacting with resources from other origins. Without this policy, malicious sites\u2014say, badguy.example.com\u2014could access login credentials for Google<\/a> or another trusted site when it\u2019s open in a different browser window or tab.<\/p>\n Since September\u2019s release of Safari 15 and iOS<\/a> and iPadOS 15, this policy has been broken wide open, research published late last week<\/a> found. As a demo site<\/a> graphically reveals, it\u2019s trivial for one site to learn the domains of sites open in other tabs or windows, as well as user IDs and other identifying information associated with the other sites.<\/p>\n \u201cThe fact that database names leak across different origins is an obvious privacy violation,\u201d Martin Bajanik, a researcher at security firm FingerprintJS, wrote. He continued:<\/p>\n 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.<\/em><\/p>\n Attacks work on Macs<\/a> running Safari 15 and on any browser running on iOS or iPadOS 15. As the demo shows, safarileaks.com is able to detect the presence of more than 20 websites\u2014Google Calendar, YouTube, Twitter, and Bloomberg among them\u2014open in other tabs or windows. With more work, a real-world attacker could likely find hundreds or thousands of sites or webpages that can be detected.<\/p>\n When users are logged in to one of these sites, the vulnerability can be abused to reveal the visit and, in many cases, identifying information in real time. When logged in to a Google account open elsewhere, for instance, the demo site can obtain the internal identifier Google uses to identify each account. Those identifiers can usually be used to recognize the account holder.<\/p>\n The leak is the result of the way the Webkit browser engine implements IndexedDB, a programming interface supported by all major browsers. It holds large amounts of data and works by creating databases when a new site is visited. Tabs or windows that run in the background can continually query the IndexedDB API for available databases. This allows one site to learn in real time what other websites a user is visiting.<\/p>\n Websites can also open any website in an iframe or pop-up window in order to trigger an IndexedDB-based leak for that specific site. By embedding the iframe or popup into its HTML code, a site can open another site in order to cause an IndexedDB-based leak for the site.<\/p>\n \u201cEvery 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,\u201d Bajanik wrote. \u201cWindows and tabs usually share the same session, unless you switch to a different profile, in Chrome for example, or open a private window.\u201d<\/p>\n Bajanik said he notified Apple<\/a> of the vulnerability in late November, and as of publication time, it still had not been fixed in either Safari or the company's mobile operating systems. Apple representatives didn\u2019t respond to an email asking if or when it would release a patch. As of Monday, Apple engineers had merged potential fixes and marked Bajanik's report<\/a> as resolved. End users, however, won't be protected until the Webkit fix is incorporated into Safari 15 and iOS and iPadOS 15.<\/p>\n For now, people should be wary when using Safari for desktop or any browser running on iOS or iPadOS. This isn\u2019t especially helpful for iPhone<\/a> or iPad<\/a> users, and in many cases, there\u2019s little or no consequence of browsing activities being leaked. In other situations, however, the specific sites visited and the order in which they were accessed can say a lot.<\/p>\n \u201cThe only real protection is to update your browser or OS once the issue is resolved by Apple,\u201d Bajanik wrote. \u201cIn the meantime, we hope this article will raise awareness of this issue.\u201d<\/p>\n This story originally appeared on<\/em> Ars Technica<\/em><\/a>.<\/em><\/p>\n