Note that these leaks do not require any specific user action. 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. To learn more, refer to Google's People API documentation. In general, at minimum, the user's profile picture is typically available. The information exposed by these APIs is controlled by many factors. It can be used with Google APIs to fetch public personal information of the account owner. It uniquely identifies a single Google account. The Google User ID is an internal identifier generated by Google. 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. Some popular examples would be YouTube, Google Calendar, or Google Keep. This means that authenticated users can be uniquely and precisely identified. Moreover, we observed that in some cases, websites use unique user-specific identifiers in database names. This is possible because database names are typically unique and website-specific. It lets arbitrary websites learn what websites the user visits in different tabs or windows. The fact that database names leak across different origins is an obvious privacy violation. For clarity, we will refer to the newly created databases as “cross-origin-duplicated databases” for the remainder of the article. Windows and tabs usually share the same session, unless you switch to a different profile, in Chrome for example, or open a private window. 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. In Safari 15 on macOS, and in all browsers on iOS and iPadOS 15, the IndexedDB API is violating the same-origin policy. If you want to learn more about how IndexedDB APIs work check out the MDN Web Docs or the W3C specification. Documents or scripts associated with different origins should never have the possibility to interact with databases associated with other origins. Indexed databases are associated with a specific origin. An origin is defined by the scheme (protocol), hostname (domain), and port of the URL used to access it. 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. Like most modern web browser technologies, IndexedDB is following Same-origin policy. 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. It’s supported in all major browsers and is very commonly used. IndexedDB is a browser API for client-side storage designed to hold significant amounts of data. A short introduction to the IndexedDB API Update (Wednesday January 26th 2022): Apple has released Safari 15.3 on iOS and macOS where this vulnerability has been fixed. The leak was reported to the WebKit Bug Tracker on Novemas bug 233548. We have also published a demo site to see the vulnerability in action: 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. 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. We believe that vulnerabilities like this one should be discussed in the open to help browsers fix them as quickly as possible. We focus on stopping fraud and support modern privacy trends for removing cross-site tracking entirely. DISCLAIMER: Fingerprint does not use this vulnerability in our products and does not provide cross-site tracking services.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |