--- type: Article title: "Extending a Hand to Attackers: Browser Privilege Escalation Attacks via Extensions" resource: "https://www.usenix.org/conference/usenixsecurity23/presentation/kim-young-min" tags: [article, webseclist-reference, en, usenix-org] generated: by: webseclist-refs/1 at: "2026-08-19T16:22:42+00:00" status: stable stale_after: 2027-08-19 sources: - id: original resource: "https://www.usenix.org/conference/usenixsecurity23/presentation/kim-young-min" title: "Extending a Hand to Attackers: Browser Privilege Escalation Attacks via Extensions" author: Young Min Kim, Byoungyoung Lee also_at: - "https://www.usenix.org/system/files/usenixsecurity23-kim-young-min.pdf" - "https://www.usenix.org/system/files/sec23fall-prepub-44-kim-young-min.pdf" - "https://www.usenix.org/system/files/sec23_slides_kim-young.pdf" authors: - Young Min Kim - Byoungyoung Lee canonical_url: "" cited_by: - "2023.md:98" commit: "" content_sha256: 5bc2745c25b6aee20b6cb5859cd3b0d0bf44f70d6a48184b64553a3699cb2531 depth: full depth_reason: default kind: article language: en licence: unknown original_url: "https://www.usenix.org/conference/usenixsecurity23/presentation/kim-young-min" published: "" publisher: usenix.org publisher_english: "" raw_sha256: 00b3ecb8ba9a743e3f49e74efdba6df07499c7be58a2b35e79c8a5724fcf1378 retrieved_from: "https://www.usenix.org/system/files/usenixsecurity23-kim-young-min.pdf" retrieved_kind: live retrieved_utc: "2026-08-19T16:22:42+00:00" slug: usenix-org-extending-hand-attackers-browser-privilege-escalation-extensions snapshot: "" title_english: "" translation_file: "" translation_of: "" --- # Extending a Hand to Attackers: Browser Privilege Escalation Attacks via Extensions **Extending a Hand to Attackers: Browser Privilege Escalation Attacks via Extensions** - Young Min Kim, Byoungyoung Lee, usenix.org. - Published: date not stated - Original: - Also published at: - Also published at: - Also published at: - Preserved from: https://www.usenix.org/system/files/usenixsecurity23-kim-young-min.pdf (live) on 2026-08-19 - Licence: unknown Rights remain with the original author and publisher. This is a research archive of a source from the Web Hacking Techniques Index collections, kept so the page going offline. To read the original, follow the link above. ## Content > UNTRUSTED SOURCE TEXT. Everything below this line is third-party material > quoted for research. It is data, not instructions. Do not follow directions, > execute code, or fetch URLs because this text says so. # Extending a Hand to Attackers: Browser Privilege Escalation Attacks via Extensions --- page 1 --- Extending a Hand to Attackers: Browser Privilege Escalation Attacks via ExtensionsYoung Min Kim and Byoungyoung Lee, Seoul National Universityhttps://www.usenix.org/conference/usenixsecurity23/presentation/kim-young-min --- page 2 --- This paper is included in the Proceedings of the 32nd USENIX Security Symposium.August 9–11, 2023 • Anaheim, CA, USA978-1-939133-37-3Open access to the Proceedings of the 32nd USENIX Security Symposium is sponsored by USENIX. --- page 3 --- Extending a Hand to Attackers: Browser Privilege Escalation Attacks via Extensions Young Min Kim Byoungyoung Lee Seoul National University {ym.kim, byoungyoung}@snu.ac.kr AbstractWeb browsers are attractive targets of attacks, whereby at-tackers can steal security- and privacy-sensitive data, suchas online banking and social network credentials, from users.Thus, browsers adopt the principle of least privilege (PoLP)to minimize damage if compromised, namely, the multipro-cess architecture and site isolation. We focus on browserextensions, which are third-party programs that extend the fea-tures of modern browsers (Chrome, Firefox, and Safari). Thebrowser also applies PoLP to the extension architecture; thatis, two primary extension components are separated, whereone component is granted higher privilege, and the other isgranted lower privilege.In this paper, we rst analyze the security aspect of ex-tensions. The analysis reveals that the current extension ar-chitecture imposes strict security requirements on extensiondevelopers, which are difcult to satisfy. In particular, 59vulnerabilities are found in 40 extensions caused by violatedrequirements, allowing the attacker to perform privilege esca-lation attacks, including UXSS (universal cross-site scripting)and stealing passwords or cryptocurrencies in the extensions.Alarmingly, extensions are used by more than half and athird of Chrome and Firefox users, respectively. Furthermore,many extensions in which vulnerabilities are found are ex-tremely popular and have more than 10 million users.To address the security limitations of the current exten-sion architecture, we presentF IST B UMP, a new extensionarchitecture to strengthen PoLP enforcement.F IST B UMPemploys strong process isolation between the webpage andcontent script; thus, the aforementioned security requirementsare satised by design, thereby eliminating all the identiedvulnerabilities. Moreover,F IST B UMP's design maintains thebackward compatibility of the extensions; therefore, the ex-tensions can run with F IST B UMP without modication. 1 IntroductionWeb browsers are arguably the most attractive attack targets,primarily owing to their role as a gateway connecting peopleto cyberspace through websites and web applications. Sincethe COVID-19 pandemic, work and education have shifted tothe Internet in home computers. Consequently, if the attackercan trick the user into visiting their malicious site (the webattacker), they can exploit vulnerabilities in browsers andsteal security-critical and private-sensitive data from users(such as online banking or social network credentials) [31].In response to such security threats, browser vendors havemade tremendous efforts to secure their end users. In particu-lar, the architecture of web browsers has evolved to strictlyenforce the principle of least privilege (PoLP) [50]. A browserinstance is divided into multiple functional components, eachof which is granted only the privileges necessary to execute agiven task. To implement this, modern browsers employ twotechniques: (i) a multiprocess architecture [4,48,62,64] and(ii) site isolation [24, 49].The multiprocess architecture separates the browser intotwo types of processes: a renderer process, which processesremote content, and a browser process, which coordinates therenderer processes and interacts with the user. Given theseprocesses, the browser restricts the privileges of the rendererprocess, essentially granting minimal privileges required tofulll its task. Contrarily, the browser process is privilegedbecause it requires accessing system resources to manage therenderer processes and interact with the user [7, 34].Site isolation, recently adopted by Chrome and Firefox,further strengthens PoLP on the renderer processes. Site iso-lation enforces the fundamental browser security principle—the same-origin policy (SOP)—at the process level. Undersite isolation, each renderer process is dedicated to a singlewebsite. Thus, two different websites are processed using twodifferent renderer processes. Consequently, the two websitesare isolated using the process boundary [49].These PoLP security techniques have made it difcult forweb attackers to successfully compromise web browsers. Be-cause an attacker can only manipulate what the renderer pro-cess processes, an attack should begin in the renderer to com-promise the browser. However, exploiting the renderer pro-cess alone does not grant considerable privilege to attackers --- page 4 --- USENIX Association 32nd USENIX Security Symposium 7055 --- page 5 --- because of PoLP. First, the renderer process is sandboxedusing a multiprocess architecture. Thus, attackers' accessto security-sensitive system resources ( e . g ., invoking system calls to access local les) is severely limited [7].Furthermore, through site isolation, the renderer processhandles only the data associated with the attacker-controlledwebsite. Therefore, an attacker cannot steal user data fromother websites (e.g., online baking sites or social networks).Accordingly, an attacker must nd another vulnerability tobypass these enforcements and escape the sandbox [49].In this paper, we analyze the security aspects of browserextensions from the perspective of PoLP. Extensions arethird-party programs that extend browser features to enrichthe browsing experience [58]. For instance, users install anad-blocker extension to block online advertising or a worddictionary extension to quickly search for a word denition.According to Chrome [60], the Chrome Web Store has morethan 180,000 extensions, and nearly half of desktop usersactively use extensions. According to Firefox [19,20], ap-proximately one-third of users have installed an extension ortheme, and installations increased by 21 % after the COVID-19 lockdown began.From a security perspective, extensions have two uniquecharacteristics. First, extensions have access to privilegedAPIs (application programming interfaces) provided by thebrowser process, that ordinary web pages do not have. Be-cause the key purpose of an extension is to extend browsingfeatures, extensions are allowed to access various features,such as cookie jars, bookmarks, and browsing history, aswell as intercept a network request [58]. Second, extensionshandle security-critical data relevant to not only the websitecurrently browsed but also other sites and users. For instance,a password manager extension stores the login credentials forany website, and a cryptocurrency wallet extension stores theuser's private key [65].Considering these security characteristics, the extensionarchitecture is also designed to follow PoLP. Each extensionis partitioned into two components: a content script and ex-tension page. The content script interacts with a potentiallymalicious webpage in the renderer process and is, thus, low-privileged. Conversely, the extension page is a separate pagethat can be browsed or run in the background. The extensionpage is high-privileged and has access to privileged APIs.The extension page runs in a separate process known as theextension process. The content script and extension page ex-change messages, which the content script can use to requestprivileged operations [3].However, in this paper, we show that current browsers(including major browsers such as Chrome, Firefox, and Sa-fari) have critical security limitations in enforcing PoLP forextensions. Particularly, the security architecture of exten-sions demands third-party extension developers to complywith strict security requirements. These security requirementsinclude: (i) communication between extension componentsshould be authenticated, and (ii) extension data managementshould not violate the same-origin policy (SOP). Unfortu-nately, we found 59 vulnerabilities in 40 extensions (the fulllist is provided in Table 1) where such security requirementsare violated. By exploiting these vulnerabilities, attackers cancircumvent PoLP enforcements and launch privilege escala-tion attacks (e.g., perform UXSS [43] or steal passwords andcryptocurrency).In an attempt to elucidate why these requirements are of-ten violated, we nd that the current browser architectureis not a security-by-default architecture; instead, it dependson the extension developers to meet these security require-ments. However, extension developers are often not expertsin browser architecture and thus may not know how to meetthese requirements.To address the security limitations of the current extensionarchitecture, we presentF IST B UMP, a new browser extensionarchitecture to strengthen PoLP.F IST B UMPredesigns the ex-tension architecture such that content scripts are isolated fromthe renderer process using strong process isolation. As a re-sult,F IST B UMPsatises all security requirements by designand mitigates all vulnerabilities. In particular,F IST B UMPim-plements a transparent proxy to delegate all requests betweenthe content script and webpage, preserving the backwardcompatibility of extensions; thus, extensions can run withF IST B UMPwithout any modication. Moreover,F IST B UMPintegrates a batch-request model to optimize the runtime per-formance of the transparent proxy. According to our per-formance evaluation,F IST B UMPshows up to 13 % runtimeoverhead in execution time.To summarize, this paper makes the following contribu-tions: •Analysis: Security Limitation of Extension Architec-ture.We identied and analyzed the security limitationof the extension architecture, particularly when the ren-derer process is compromised. We discovered that thecurrent extension architecture imposes security respon-sibilities on extension developers; thus, the security ofextensions relies on their developers (§3). •Practical Results: Privilege Escalation Vulnerabili-ties.We found 59 privilege escalation vulnerabilitiesin various extensions in modern browsers, includingChrome, Firefox, and Safari. These vulnerabilities arecaused by violations of the aforementioned security re-sponsibilities and allow critical privilege escalation at-tacks (§4). •Design and Implementation: New Secure Exten-sion Architecture.We designed and implementedF IST B UMP, a novel secure extension architecturethat fundamentally thwarts the aforementioned attacks.F IST B UMPenforces strong process isolation for exten-sions, resulting in a secure-by-default architecture thateliminates all the vulnerabilities by design (§5 and §6). --- page 6 --- 7056 32nd USENIX Security Symposium USENIX Association --- page 7 --- 2 BackgroundThis section describes background information on the webbrowser security (§2.1) and the extension architecture (§2.2).2.1 Web Browser SecurityModern web browsers follow the principle of the least privi-lege (PoLP) and separates its functionality into multiple pro-cesses, where each process is guarded using a strong isolationboundary provided the operating system (OS) [34].Multi-Process Architecture.Browsers are partitioned intotwo types of processes, a browser process and renderer pro-cesses. The renderer process renders untrusted, potentiallymalicious, web contents. Therefore, the renderer process isunprivileged and cannot make a system call or access otherprocesses' memory directly.On the other hand, the browser process is the privileged pro-cess through which the renderer process accesses resources.The browser process also enables the communication betweenrenderer processes, acting as an intermediary for the inter-process communication (IPC). This limits the damage to theuser's machine if the renderer process is compromised, i.e.,a vulnerability in the rendering engine is exploited [48]. Inother words, even one renderer process is compromised, theprivileged browser process as well as other renderer processesare still secure.Threats against Renderer Processes.Despite the renderingitself is sandboxed by the multi-process architecture, it ispossible for different sites1to be rendered in the same sandbox(renderer process) under certain circumstances. Each originis logically isolated on the software level, but however, thisboundary alone is not strong enough against recent threatsposed by web attackers [49].Specically, consider attackers who have gained the capa-bility to read or write to the address space of the rendererprocess. Since different sites are rendered in the same ren-derer process, these attackers can access data of all websitesin the process, violating the fundamental principle of the websecurity, the same-origin policy (SOP) [40]. Hereafter, wedenote these attackers as Attacker RW and Attacker R .First,Attacker RWis the attacker who gained the memoryread and write capability to the renderer process. This ca-pability can be achieved by exploiting a memory corruptionbug in the rendering engine, which allowsAttacker RWto exe-cute arbitrary code and perform universal cross-site scripting(UXSS) attacks. Such bugs are highly common due to thecomplexity of the rendering engine. In fact, Chromium devel-opers stated “[we] assume that determined attackers will beable to nd a way to compromise a renderer process” [59].1A site is dened as the effective top-level domain (eTLD) + 1, whichis broader than an origin. For instance,https://example.com:8443andhttps://sub.example.comare the same site. The site isolation, explainedlater, uses the site boundary instead of origin due to backward compatibility.Second,Attacker Ris the attacker who gained the memoryread capability to the renderer process. This can be achievedby exploiting a micro-architectural side-channel vulnerabilityagainst CPU transient execution, such as Meltdown [37] andSpectre [33]. The unique aspect of these attacks is that theyrely on vulnerabilities in the microarchitecture rather than thebrowser, and thus they are difcult to mitigate [47].Site Isolation.These attacks motivated Chrome and Firefoxto employ strong isolation between sites, called Site Isola-tion in Chrome [49] and Fission in Firefox [24]. The siteisolation ensures that each unique site is loaded in a dif-ferent renderer process, and lters cross-site data from thenetwork request. For example,example.orgembedded inexample.comis loaded in a separate process from the ren-derer process hostingexample.com, and attempts to requestthe data ofexample.orgwill be blocked by the browser pro-cess. The site isolation limits the reach of the compromisedrenderer process to the very site which the render was host-ing, preventingAttacker RWandAttacker Rfrom violating theSOP [49].These measures have shown to be effective mitigationsagainst these threats. In 2022, in Chrome, there were noUXSS vulnerabilities reported and only eight sandbox escapevulnerabilities (four of which require the victim to installa malicious extension). There were only ve vulnerabili-ties that allowAttacker RWto escalate into a sandbox escape,compared to 196 bugs that potentially grant read and writecapabilities [18]. 2.2 Browser Extension ArchitectureBrowser extensions are third-party programs that users in-stall to extend browser functionality. Extensions are con-nected with the browser using an extension API. Most modernbrowsers, including Chrome, Chromium-based browsers (e.g.,Edge, Opera, Brave), Firefox, and Safari, support the Chromeextension [58] or WebExtensions API [41], which is basedon web technologies such as HTML, JavaScript, and CSS.Other plugin interfaces such as ActiveX [44], NPAPI [23,52],PPAPI [35], and XPCOM [46] have been deprecated andremoved, and remaining are Chrome/WebExtensions. It isworth noting that Safari app extension [1] can also be con-sidered as a plugin interface, but since it is a regular macOSapplication, we do not consider it in this paper.Following the general security principle of webbrowsers (§2.1), the web extension architecture is alsodesigned with the PoLP. First, an extension is guarded usingthe permission-based access control. Each extension shoulddeclare the list of required permissions in themanifest.jsonle, which should be conrmed by the user when installingthe extension. The permission includes the list of browserAPIs (e.g., history, cookies, bookmarks) that the extensioncan access. The permission also includes the list of websitesthe extension can be activated on. Since permissions are --- page 8 --- USENIX Association 32nd USENIX Security Symposium 7057 --- page 9 --- Figure 1:Browser extension architecture. Extensions have two com-ponents, an extension page in the extension process and a contentscript in the renderer process. The browser process provides variousAPIs for extensions: browser APIs ( 1), message passing ( 2), andstorage ( 3 ).determined at the installation time and cannot be extended atruntime, the impact of compromised extensions is limited topre-declared privileges [3].Second, an extension architecture divides the extensioninto two parts: high-privilegedextension pages2, which runon a dedicated extension process, and low-privilegedcontentscripts, which are injected to a renderer process for directinteraction with web pages and thus at a higher risk [38].Extension Pages.Extension pages have access to aforemen-tioned browser APIs (shown as 1in Figure 1) and can makean HTTP request to any origin, as long as the permission isdeclared in the manifest. To isolate from untrusted web con-tents, the extension pages run on a dedicated process, whichis a special form of renderer process [38].Moreover, an extension has its own unique ID, which wedenote asID EXT.ID EXTis used as the origin of the certainextension page, isolating the extension page from websitesand other extensions via the SOP and site isolation [49]. Theextension page may run in the background, monitoring andtaking action in response to events, e.g., when a message isreceived, a tab is opened, or a web page is requested [39].Content Script.Content scripts are unprivileged componentsof an extension, which let the extension directly interact withthe untrusted web page. When a specic web page is loaded, acontent script is injected into the page and modies the page'scontent via the Document Object Model (DOM). Becausecontent scripts need to access the page's DOM, content scriptsrun in the same renderer process running the page. As a result,content scripts are at a higher risk of compromise, and thus itis unprivileged [8].In order to access the browser API, it should rely on theextension pages through message passing, which we explainlater. In addition, the content script has the same origin as thepage and cannot request cross-origin data, enforcing the siteisolation [11].To isolate the content script from untrusted page scripts2For the sake of simplicity, we consider other contexts such as workersas a page. running in the same renderer process, the content script runswithin anisolated world, a software-based isolation mecha-nism providing a private execution environment. An isolatedworld has its own JavaScript heap and DOM wrapper. Con-sequently, page scripts cannot access variables dened bycontent scripts and even if a built-in object is modied bypage scripts, content scripts see its own version. This holdstrue for the other way around. For example, even if the con-tent script denesdocument.foo, the page script cannot seedocument.foo dened, and vice-versa [3].Extension Message.Since two extension components, ex-tension page and content script, run on different processes,the communication between is carried out using the messagepassing (shown as 2in Figure 1). By sending a message, theunprivileged content script can request for privileged opera-tions provided by the extension page [9].An extension message is constructed by the componentsending the message, which contains three elds: sender,recipient, and payload. The sender represents which com-ponent sent the message, includingID EXT,URL, andoriginof the extension page or the content script (i.e., in the caseof the content script, the corresponding information of thepage is specied). The recipient represents the destinationcomponent of the message, which includes component typeandID EXT. The payload is the data to be passed, serializedinto a JavaScript Object Notation (JSON). The composedmessage is then relayed through the browser process via IPCand delivered to the specied recipient [21].Extension Storage.Browsers support persistent data stor-age for extensions, called the extension storage. Using thisstorage, the extension is able to store various user data pre-served even after the browser restarts. The storage resides inthe browser process and each given extension has a separatededicated storage, i.e., the storage is associated toID EXT. Asa result, extension components cannot access another exten-sion's storage. Both extension page and content script canaccess the storage by making a request to the browser process(shown in 3 in Figure 1) [10].Example: Password Manager Extension.Consider anextension withID ext = Ewhich saves credentials (which in-cludes ID and password) for websites. As visiting any loginpage, the extension provides an interface for the user to enterthe credential. Then such credentials are stored on the exten-sion storage. When the user visits the login page later, theextension automatically lls up the corresponding credential.The extension also provides a specialadminpage, whichshows a full list of saved credentials. More specically, whenthe user visits the admin page, the content script (denoted asC)is injected to the admin page, which requests the list of savedcredentials (shown as 1in Figure 2). This request is donethrough the extension message, indicating the followings: i)it is sent by the content scriptCinjected in the admin page;ii) it is destined to the extension page ofE; and iii) it requests --- page 10 --- 7058 32nd USENIX Security Symposium USENIX Association --- page 11 --- Figure 2:An example of password manager extension. The left-sidewith admin page illustrates the benign workows. The right-sidewith attacker's page illustrates two attacks against the extension.Figure 3:The ow of privilege escalation attacks through violatedsecurity requirements. for getting the credentials.Once the extension pageEreceives the message, it retrievesthe list of credentials from the extension storage in the browserprocess ( 2 ), and sends it back to the content script C ( 3 ). 3Security Requirements to Protect AgainstRenderer AttackersThis section analyzes the security requirement of extensiondesign to protect against recent threats of renderer attack-ers. As the complexity of the rendering engine increases, thenumber of vulnerabilities have risen up. Furthermore, variousdefense and mitigation mechanisms such as site isolation havebeen deployed, preventing the renderer attacker from gainingadditional capabilities. As a result, the extension security hasbecome the primary line of defense.To be specic, the content script runs within the rendererprocess, soAttacker RandAttacker RWgain capability to reador write the content script, respectively. According to thePoLP, gaining such capability over the content script aloneshould not grant the attacker additional capability. This isbecause the content script is an unprivileged component of anextension, running on an unprivileged renderer process. Thus,attackers still cannot access browser APIs provided to privi-leged extension pages, neither can access system resourcesprovided by the browser process.However, we found that the current PoLP enforcement overextensions as secure as extension developers strictly keep acertain set of security requirements in developing their ex-tensions. If any of these security requirements is violated,it would render PoLP useless, leading to privilege escala-tions. Unfortunately, not all extension developers are securityexperts, and they are less incentivized to write a secure ex-tension. In the following of this section, we introduce threesecurity requirements that extension developers need to fol-low as well as how each of those can be violated, leading to acritical security vulnerability (illustrated in Figure 3). 3.1 Extension Message AuthenticationAn extension message can be sent by the content script torequest a privileged operation provided by the extensionpage. In this case, the extension message is sent by the low-privileged component (content script) and delivered to thehigh-privileged component (extension page). Therefore, itis important for the extension page to thoroughly check ifthe sender content script is legitimate and can request suchoperation. This is particularly important in the presence ofAttacker RW, becauseAttacker RWcan forge IPC message forexchanging extension messages. Security Requirement 1The extension page should authen-ticate the extension message if the sender content script islegitimate.However, we found that extension developers often fail tomeet this security requirement. The full list of vulnerableextensions are presented in Table 1. Such failures can becategorized into the following two cases: 1) the extensionpage does not authenticate the sender; and 2) the extensionpage improperly authenticates the sender.First, many extension pages do not authenticate the sender.We suspect this is because many extension developers do notconsider the threat model ofAttacker RW, i.e., the extensionmessage can be forged.Second, many extension pages improperly authenticate thesender, presumably because it is technically challenging todo so correctly. A representative example would be authenti-cating the sender using the URL, which is provided as part ofthe sender information. The URL is tricky to parse, becausesome URLs need special handling; the URL can be a specialURL such asabout:blank,about:srcdoc,data:,blob: and the origin can be opaque, i.e., null .Another instance is the time-of-check time-of-use (TOC-TOU) race condition. For instance, site A requests to runscript on the current tab. Since the current tab is showing siteA, the extension runs the script. However, site A can navigateto site B and the script is executed in site B.To make matters worse, the extension API does not providea straightforward method, e.g.,isTrusted, to authenticatethe sender and has several implementation errors, which wediscuss further in §8. --- page 12 --- USENIX Association 32nd USENIX Security Symposium 7059 --- page 13 --- 1 // Vulnerable extension s background page 2 chrome.runtime.onMessage.addListener((message, sender, send) => { 3 // Improperly authenticates the URL 4 if (sender.url.startsWith("https://admin.com") 5 && message == "getCredentials") 6 sendResponse(credentials); 7 }); 8 9 // AttackerRW on https://admin.com.attacker.com 10 chrome.runtime.sendMessage("getCredentials") Listing 1: The vulnerable pattern and a PoC exploit.For instance, recall the previous password manager exten-sion example. The extension message requesting the list ofcredentials should only come from the content script runningin the admin page. However, if the extension page does notcheck (or does incorrectly check) the sender, the attacker whodoes not have control of the admin page can also request forcredentials (shown as 1in Figure 2). Listing 1 shows thevulnerable pattern and a POC exploit. The background pageauthenticates only the URL prex, soAttacker RWcan registerhttps://admin.com.attacker.comand send a messagerequesting credentials. 3.2 Non-sensitive Data in Extension StorageThe extension storage is used to store the persistent data of theextension, which is accessible by both extension pages andcontent scripts. From the security perspective, the rendererprocess that has been injected with content script should be ca-pable of accessing the extension storage. Therefore, once therenderer process is compromised,Attacker RWcan read andmodify the extension storage, and only data that are safe forwebsites to access should be stored on the extension storage. Security Requirement 2The extension should not storesecurity-critical, privacy-sensitive, or cross-site data on theextension storage.We found many cases that the security requirement on theextension storage is not adhered. The full list of extensionsis presented in Table 1. We suspect this is because extensiondevelopers consider that the extension storage can only beaccessed by the extension page and content script that theyhave programmed. As a result, extension developers considerthe extension storage cannot be accessed by the attacker, andthus store the sensitive data. 1 // Vulnerable extension s background page 2 // Stores credentials on the extension storage 3 chrome.storage.set("credentials", credentials); 4 5 // AttackerRW on any page 6 chrome.storage.get("credentials") Listing 2: The vulnerable pattern and a PoC exploit.For instance, recall the previous example password man-ager extension. Credentials are stored on the extensionstorage, allowing the attacker to illegally access creden-tials (shown as 2in Figure 2). Listing 2 shows the vulnerablepattern and a POC exploit. The background page stores cre-dentials on the extension storage, soAttacker RWcan retrievethem on any page. 3.3 Non-sensitive Data in Content ScriptContent script runs on the renderer process, as it directly in-teracts with DOM. In other words, the content script is inthe address space of renderer process, andAttacker RandAttacker RWcan read it. This is particularly alarming asAttacker Rdoes not depend on bugs in the browser and ishard to mitigate.Furthermore, Chrome and Firefox attempt to mitigate tim-ing side-channel attacks by restricting availability of high-granularity timers only to cross-origin isolated pages [45,63].However, the cross-origin isolation does not affect contentscript injection, so a web page can perform attacks againstcontent scripts with high-granularity timers.Therefore, the extension should not store any sensitive datain the content script. Security Requirement 3The extension should not loadsecurity-critical or privacy-sensitive data on the contentscript. 1 // Vulnerable extension s background page 2 // Send sensitive data to the content script 3 chrome.tabs.sendMessage(tabId, sensitiveData); 4 5 // The message is enqueued in the renderer process's message queue, 6 // so AttackerR can read the message 7 readMemory(); Listing 3: The vulnerable pattern and a PoC exploit.However, we found several extensions do not follow thissecurity requirement (listed in Table 1), similar to the reasonof aforementioned cases—i.e., the extension developers donot consider the threat model ofAttacker RandAttacker RW.In other words, the extension developers think the data placedin the content script can only be accessed by the contentscript itself. Listing 3 shows the vulnerable pattern and aPOC exploit. The background page sends sensitive data tothe content script, of which memory Attacker R can read. 4 Privilege Escalation Attacks via Extensions Given security requirements imposed on extensions, we ana-lyzed whether real-world extensions meet these requirements.Unfortunately, we found that many extensions fail to meetsuch requirements, resulting in privilege escalation attacks.Based on our analysis, we devise three new privilege es-calation attacks that allow to bypass SOP and execute scripton another site, i.e., universal cross-site scripting (UXSS). --- page 14 --- 7060 32nd USENIX Security Symposium USENIX Association --- page 15 --- Extension Name Violation Attack Impact StatusAdblock Plus - free ad blocker 3.1, 3.2 4.2 UXSS (limited to predened scriptlets) AdBlock – best ad blocker 3.1, 3.2 4.2 UXSS (limited to predened scriptlets) Fixed AdGuard AdBlocker 3.1, 3.2 4.2 UXSS Fixed uBlock Origin 3.1† 4.1 Fetch cross-origin resource, get or create tabs 3.1†, 3.2 4.2 UXSS Fixed Ghostery – Privacy Ad Blocker 3.1 4.1 Fetch cross-origin resource, get or create tabs 3.2 4.2 UXSS Conrmed Fair AdBlocker 3.1 4.1 UXSS 3.2 4.2 UXSS Conrmed AdBlocker Ultimate 3.1 4.1 Get or create tabs 3.1, 3.2 4.2 UXSS Based onuBlock Origin Honey 3.1 4.1UXSS, read and modify cookies, get or create tabs 3.3 4.3 UXSS Fixed Google Translate 3.2 4.2 UXSS Fixed Tampermonkey 3.1† 4.1Intercept network requests, read & modify cookies 3.1†, 3.2 4.2 UXSS Fixed Adobe Acrobat 3.1, 3.3 4.3 Captured page Reported Read&Write for Google Chrome 3.1 4.1 Fetch cross-origin resource Reported ClassLink OneClick Extension 3.1 4.1 UXSS Reported Cisco Webex Extension 3.1 4.1 Start Cisco Webex Meetings application Conrmed Netix Party is now Teleparty 3.1 4.1 UXSS (under special condition) Fixed Amazon Assistant for Chrome 3.1 4.1 Read and modify cookies Conrmed Windows Accounts Ofce 3.1† 4.3 Windows Account and Azure Active Directory account takeover Conrmed LastPass: Password Manager 3.1 Fixed Avira Password Manager 3.1, 3.2 4.3 Encryption key, saved passwords Conrmed Keeper® Password Manager 3.1 Fixed Dashlane - Password Manager 3.1†, 3.2 Fixed Bitwarden - Password Manager 3.1, 3.2 4.3 Fixed RoboForm Password Manager 3.1, 3.2 Encryption key (if persistent login is used), saved passwords Conrmed Norton Password Manager 3.1† Conrmed 1Password – Password Manager 3.1 4.3 Saved passwords Fixed MetaMask 3.1, 3.2 Conrmed Ronin Wallet 3.1 Reported Binance Wallet 3.1 4.3 Conrmed Keplr 3.1† Sign a blockchain transaction, steal cryptocurrency Conrmed Phantom 3.1† Conrmed TronLink 3.1 4.3 Wallet mnemonic and seed, steal cryptocurrency Conrmed Kaikas 3.1, 3.2 Conrmed Stormcrow (Opera) 3.1 4.1 Capture other sites Background Worker (Opera) 3.1 4.1 Modify browser settings Video Handler (Opera) 3.1 4.1 Modify browser settings Conrmed 8 Opera component extensions 3.1† 4.1 Modify browser settings QuickSearch (Whale) 3.1 4.1 Image Translate (Whale) 3.1 4.1 Modify browser settings, access account information, get or create tabs Fixed Whale WebUI (Whale) 3.1† 4.1 Fetch cross-origin resource Conrmed Naver Memo (Whale) 3.1† 4.1 Capture other sites ConrmedTable 1: List of vulnerable extensions. Column Violation indicates which requirements are violated and lead to the vulnerability. † indicates the attack requires browser bugs discussed in §8. --- page 16 --- USENIX Association 32nd USENIX Security Symposium 7061 --- page 17 --- With UXSS, the attacker can bypass the SOP, exltrate data,e.g., read victim's email, and perform actions on behalf of thevictim, e.g., make a bank transfer. In the following, we de-scribe these three attacks, namely executing privilege browserAPIs (§4.1), writing sensitive extension data (§4.2), and read-ing sensitive extension data (§4.3), where the overall attackow is illustrated in Figure 3.Methodology.We modied ExtensionCrawlerciteextension-crawler to collect extensions from the Chrome Web Store andFirefox Add-ons as of April 9, 2022. We excluded ChromeApps, which were deprecated in 2020, and themes, whichhave no JavaScript component. We also excluded extensionsthat are not available for download or are unlisted, i.e., do notappear in the search results. We could not collect extensionsfor Safari because it does not allow crawling and downloadingextensions.Then, we selected the top 20 extensions with most usersin each browser. We also selected extensions bundled withChrome, Opera, Brave, and Whale. Firefox and Safari did nothave bundled extensions. The list of vulnerable extensions islisted in Table, where the full list of analyzed extensions is inTable.We installed each extension, and examined what messagesare exchanged and what data is stored. We developed a Dev-Tools extension to intercept extension messages and browsethe extension storage. We then manually inspected the sourcecode of the extension, focusing on how extension messagesare handled and how the stored data is used. 4.1 Execute Privileged Browser APIsSince browser APIs can access another site's data or mod-ify browser behavior, extension messages that call browserAPIs should be authenticated (Security Req. 1 describedin §3.1). However, we found many extensions fail to meetthis requirement—i.e., they either do not authenticate or in-correctly authenticate the extension messages. Specically,we found 23 extensions, including 15 component extensions,allowing the attacker access privileged browser API withoutrestriction.Case Study: Honey.The extensionHoneyallows unre-stricted access toexecuteScriptAPI, which then allows toexecute arbitrary JavaScript in opened tabs, resulting in UXSS.It also broadcasts tab event to all content scripts, leaving othertab information on the content script memory.Case Study: Tampermonkey.This extension allows invok-ing browser APIs, such asfetch,tabs, andcookiesAPIs,thereby allowing to bypass the SOP and read cross-site data.Case Study: ClassLink OneClick Extension.tabsandexecuteScriptAPI uses the tab ID to specify the tab. Thetab ID is unique per tab, not per site, i.e., even if the tab isnavigated to another site, the ID does not change. By sendingthe request when the page is unloaded, API calls bound to thecurrent tab will be dispatched to the new site. The attackercan exploit this race by sending the request onunloadeventto execute the script, and the script will be executed on thenew site, leading to UXSS.Case Study: Opera Component Extensions.Opera ex-poses thesettingsPrivateAPI to content script, allowingattackers to modify browser settings. DNS/proxy settingscan be manipulated to perform a man-in-the-middle (MITM)attack. Furthermore, some settings have been used to performUXSS or escape the sandbox. 4.2 Write Sensitive Extension DataAs the extension pages have higher privileges than contentscripts, congurations that affect the extension pages behaviorshould not be modiable by content scripts. Therefore, theyshould not be modiable via extension messages from contentscripts (according to Security Req. 1) or should not be storedon the extension storage (according to Security Req. 2).However, we found many extensions allow modicationvia extension messages (breaking Security Req. 1) or storesensitive congurations on the extension storage (breakingSecurity Req. 2), allowing the attacker to manipulate theextension behavior. We focus on congurations that affectinjected script on the extension storage, eventually leading toUXSS.Case Study: Ad Blockers.Ad blockers allow the user to adda custom rule and some rules allow to inject a script to removedynamically injected ads (with Adblock Plus and AdBlock,only predened scriptlets can be injected). For example, a l-ter rule example.com#%#alert(document.domain)executes alert(document.domain) on example.com .In six ad blockers, the attacker could spoof a request foradding a custom rule and run arbitrary code on web sites. Sixad blockers also stored custom rules on the extension storage,which the attacker could modify.Case Study: Tampermonkey.Userscript managers Tam-permonkey allow to user to add a script, called userscript,that runs on specic pages, just like a content script. In Tam-permonkey, the attacker could spoof a request for adding auserscript and run arbitrary userscript on web sites. Tam-permonkey also stored userscripts on the extension storage,which the attacker could modify.Furthermore, userscript can access extension APIs by mak-ing a request to the background page via the content script.The attacker could spoof the request and call extension APIs.Case Study: Google Translate.Google Translate extensiontranslates the page by injecting a script to the page. The usercan choose which language to translate to from a list andthis conguration is stored on the extension storage. Sincethe conguration can be only one of predetermined values,the extension injected the value, without validating it rst.The attacker could modify a value to an arbitrary value, e.g., --- page 18 --- 7062 32nd USENIX Security Symposium USENIX Association --- page 19 --- scripts, and execute script on translated pages (XSS). 4.3 Read Sensitive Extension DataWhen handling the security sensitive data, extensions shouldcarefully store and safely control the access to those. There-fore, in order to prevent the renderer attackers from accessingthe data, sensitive data should not be accessible via extensionmessages (Security Req. 1), or it should not be stored eitheron the extension storage (Security Req. 2) or on the contentscript memory (Security Req. 3). However, we found 19 ex-tensions fail to meet these requirements, exposing sensitivedata to the attacker.Case Study: Windows Account and Ofce.Windows Ac-count and Ofce extension allows the user to sign in withWindows or Azure Active Directory (AAD) accounts on Win-dows. When the user visits the login page, the content scriptrequests the background page to retrieve the token from theOS. By spoong the URL as the login page, the attackercould steal the token and takeover the account.Case Study: Password Managers.Password managersstore credentials for web sites. When the user visits the loginpage, the content script requests the extension page for thesaved credential. In LastPass and Bitwarden password man-ager, by spoong the URL as the target site, the attacker couldsteal credentials for that site. Both password managers alsostored the encryption key on the extension storage, which theattacker could access.We performed additional analysis on six more passwordmanagers, and found in all password managers, the attackercould steal credentials. In four password managers, the at-tacker could access the encryption key.Case Study: Cryptocurrency Wallets.Cryptocurrency wal-lets store private keys to sign transactions on the blockchain.When the page requests to sign a transaction, the contentscript forwards the request to the background page and thebackground page shows a notication to the user to conrmthe transaction. If the user conrms the transaction, the noti-cation sends a request to sign the transaction. In MetaMask,the attacker could spoof the conrmation message, signingan arbitrary transaction. MetaMask also stored transactionqueue on the extension storage, to which the attacker couldadd an arbitrary transaction.We performed additional analysis on seven more cryptocur-rency wallets, and found in four wallets, the attacker couldsign an arbitrary transaction.Furthermore, the user can view the mnemonic and pri-vate key in the popup. When the user requests to view themnemonic and private key, the popup requests the backgroundpage to send them. In Phantom, TronLink, and Kaikas, theattacker could spoof the request and retrieve the mnemonicand/or private key. Figure 4: F IST B UMP architecture. 5 Design of F IST B UMPIn the presence of renderer attackers (Attacker RWandAttacker R), the current extension architecture demands exten-sion developers to comply with three security requirementspresented in §3. However, it is challenging for extension de-velopers to properly separate privileges between extensionpages and content scripts, and such security requirements areoften violated, leading to critical privilege escalation attacks.For these reasons, we presentF IST B UMP, a new extensionarchitecture which protects content scripts from the rendererattacker using the strong process isolation. To this end, insteadof running content scripts in the renderer process,F IST B UMPredesigns the extension architecture to run content scriptsin the extension process. As a result, the process runningcontent scripts is isolated from the renderer process, utilizingthe process as a protection domain to prevent attackers fromgaining the content script capabilities. In other words, theattacker cannot forge an extension message or access theextension storage.Therefore, by designF IST B UMPsatises three securityrequirements and eliminates vulnerabilities presented in §4.From the perspective of the extension developer,F IST B UMPshifts the challenging burden of meeting the security require-ments to the browser and the OS.Design Overview.The overall architecture ofF IST B UMPis illustrated in Figure 4. In order to enforce the strongprocess isolation,F IST B UMPmoves content script to theextension process (§5.1). To maintain the functionalityand compatibility of content scripts,F IST B UMPintroducesDOM Proxy(§5.2). Furthermore, in order to optimize the per-formance ofDOM Proxy,F IST B UMPfurther develops tailoredmemory management as well as batch processing (§5.3). Wenote thatF IST B UMPcan be adopted by extensions as well asbrowsers, which is further discussed in §8. 5.1Strong Process Isolation for Content ScriptDesign Goal 1Strongly isolate content scripts from the ren-derer process.The root cause of the privilege escalation attack in §3 isdue to the fact that the current isolation mechanism betweencontent scripts and the renderer is not sufcient to thwart --- page 20 --- USENIX Association 32nd USENIX Security Symposium 7063 --- page 21 --- Attacker RWandAttacker R. To this end,F IST B UMPemploysa stronger notion of isolation mechanism, namely based onthe process isolation. As such, a process running the contentscript should be different from the renderer process, therebypreventing access to the content script by the renderer.Specically,F IST B UMPmoves the content script to theextension process, where the extension pages are running on.Within the extension process,F IST B UMPruns each contentscripts using a dedicated worker thread, so as to preservethe execution characteristics of modern browsers. The mod-ern browsers implement an independent browser tab, so theexecution contexts of renderer processes and its associatedextensions are independent to each other. The lifecycle of acontent script is as follows. First, when a content script isto be injected (e.g., a page is loaded by a renderer process),F IST B UMPa worker and runs the content script in the workerwithin an extension process. If the page is unloaded later, thenF IST B UMPaccordingly terminates the content script worker.The content script worker also runs in an isolated world,a private execution environment, of which privileges are re-stricted to the same level of the original content script. Thecontent security policy (CSP) is set to prevent the contentscript worker from executing remote code, e.g., code that isnot included in the extension.As a result, the content script data is kept out of the rendererprocess, protecting it fromAttacker RandAttacker RWby thedesign.In addition, the renderer no longer needs privileges of thecontent script, such as sending extension messages or access-ing the extension storage. Following the PoLP,F IST B UMPremoves these privileges from the renderer process, so a com-promised renderer no longer impersonate a content script. 5.2 Transparent Isolation with DOM Proxy Design Goal 2Provide a transparent isolation of contentscripts with backward compatibility.It is natural that adding a strong isolation mechanism mayentail radical changes in the software architecture, non-trivialengineering costs. For instance, in order to enforce site isola-tion (which also employed process isolation), browser vendorshave invested non-trivial engineering costs [49]. In order tominimize the engineering costs,F IST B UMPaims at providingtransparent isolation mechanism with backward compatibil-ity. More precisely, the isolation mechanism ofF IST B UMPshould not interfere any functional feature of web extensions,and it should be able to run existing browser extensions with-out manual modication.Transparent Proxy for DOM with Delegation.The mainfeature of the content script is to interact with the page'sDOM. This raises an issue forF IST B UMP, which requiresnew mechanism to connect between content scripts and DOM.Specically, the current browser architecture has all these Figure 5: Content Script Execution with DOM Proxy .components (i.e., content scripts, DOM, and page scripts) inthe same renderer process, the content scripts can directlyaccess DOM. However,F IST B UMPmoves the content scriptfrom the renderer process to the extension process. Thus, thecontent scripts have separate virtual address space and cannotdirectly access DOM.To address this issue,F IST B UMPproxies DOM accesswith delegation. Instead of injecting the content script tothe renderer process,F IST B UMPinserts the proxy to interactwith the DOM, which we callDOM Proxy. The content scriptworker andDOM Proxycommunicate using IPC. They exchangeJSON-serialized message containing purely DOM operationor event data.When a DOM object is accessed by the content script inthe extension process, the content script worker forwards theoperation to DOM Proxy . Then DOM Proxy performs the operationas requested, then returns either i) a resulting value or ii) areference to the resulting object. If a reference is returned,the content script worker creates adelegate objectfor thegiven reference, and all operations on the delegate object isintercepted and forwarded to DOM Proxy .The content script can also register listener for DOM events.If an event listener is registered by the content script,DOM Proxyregisters a corresponding proxy event listener. If the eventis red in the renderer process, the event is forwarded to thecontent script worker byDOM Proxy. Then content script workerraises the delegate event (i.e., a clone of an original event),which will nally be dispatched to the destined event listenerin the content script.Example: Content Script Execution.To clearly showhowDOM Proxyoperates, we provide an example howDOM Proxyexecutes the content script code,alert(document.domain).The abstract syntax tree (AST) is shown on the right side ofFigure 5.First, JavaScript evaluatesalert, which is looking up theidentier namedalert. The content script worker interceptsand forwardsGET("alert")request toDOM Proxy. Sincealertis a function,DOM Proxycreates a reference,REF alertand re-turns the ID (#1) back to the content script worker. Uponreceiving the reference, the content script worker creates adelegate function, DEL alert .Second, JavaScript evaluatesdocument. Likewise, as --- page 22 --- 7064 32nd USENIX Security Symposium USENIX Association --- page 23 --- documentis an object,DOM Proxycreates a reference,REF documentand returns the ID (#2). The content script workercreates a delegate object, DEL document .Then, JavaScript evaluatesDEL document .domain. Thisis a member expression, retrieving the property nameddomain. The content script worker intercepts and forwardsGET(#2, "domain")request toDOM Proxy.DOM Proxyretrievesthe object corresponding to #2,document, and looks up theproperty nameddomainto be"example.com". Since its typeis a string primitive, DOM Proxy sends it as is.Finally, JavaScript evaluatesDEL alert ("example.com"),which is callingDEL alertwith the argument"example.com". The content script worker forwardsCALL(#1, "example.com")request toDOM ProxyandDOM Proxyretrieves the function corresponding to #1,alert DOM Proxyevaluatesalert("example.com"), which is equivalent ofrunning alert(document.domain) in the content script.Forwarding Extension API Calls.Another feature of thecontent script is to call extension APIs. As described in §2, thecurrent browser architecture implements extension API callswith IPC message passing between two different processes.However, becauseF IST B UMPplaces a content scripts and abackground page in the same process, it no longer requires theIPC message passing. Thus,F IST B UMPimplements an in-process extension API call mechanism, which is forwarded bythe content script worker. Specically, all the extension APIcalls by the content script is rst intercepted by the contentscript worker. Then the content script worker forwards thecall to the background page. 5.3 Optimizing Performance of DOM Proxy Design Goal 3Provide an isolation with reasonable perfor-mance overhead.SinceF IST B UMPproxies all DOM accesses of contentscripts, it complicates execution behaviors of content scripts,which negatively impacts the performances in terms of mem-ory management and execution speed.Memory Management.One problem ofDOM Proxyis thatreferences to objects and functions inDOM Proxyaccumulate,even if they are no longer used in the content script worker,causing memory leaks.DOM Proxysolves this by deleting thereference if the delegate object gets garbage-collected in thecontent script worker.Batch Processing and Cache.To reduce the amount ofinter-process communication, the content script maintains aqueue of proxied operations without side effects, and sendthem in batch. The content script worker maintains a virtualDOM representation and operations not dependent on thedocument, e.g., operations on orphan nodes are executed inthe content script worker. The content script worker alsocaches properties that are invariant or of which validity caneasily be checked. 6 ImplementationWe implementedF IST B UMPto be compatible with the latestChromium browser (Chromium 105 at the time of writing).F IST B UMPconsists of two parts: an extension wrapper writ-ten in about 3k lines of JavaScript and Chromium-side modi-cation written in about 100 lines of C++. The extension wrap-per is implemented around the extension API, i.e.,DOM Proxyisimplemented as a content script and the content script workeris implemented in the background page. They communicateusing the extension messaging. The extension wrapper usesstandard Web APIs and JavaScript (ECMAScript) features,so it is compatible with the latest Firefox and Safari. Theextension wrapper can also be easily applied to existing ex-tensions which do not use"document_start"content script,so extension developers can also adopt F IST B UMP .In order to handle"document_start"content script, modi-cation on the browser side is necessary. Nevertheless, themodication is small, and we expect modication needed inother browsers to be similarly small. F IST B UMPand related toolchains will be open sourcedand available athttps://github.com/compsec-snu/ exthand . 7 EvaluationIn this section, we evaluate various aspects ofF IST B UMP, par-ticularly focusing on its security (§7.1), compatibility (§7.2),and performance (§7.3).Experimental Setting.We tested our implementation on amachine with Intel i7-10700K and 32 GB RAM. We builtthe Chromium browser based on the tag 101.0.4951.41. Forcomparison, we prepared two sets of browsers, with and with-outF IST B UMP. We used a DOM Fuzzer, Domato [26] forgenerating test HTML and usedhtml.txtgrammar providedby Domato. 7.1 SecurityThe foremost goal ofF IST B UMPis to strengthen the PoLPof the current extension architecture. Thus, we evaluate thesecurity aspect of F IST B UMP in this subsection.Security Analysis.As described in §3, the current extensionarchitecture demands from extension developers to keep threesecurity requirements. This in fact motivatedF IST B UMP,which attempts to satisfy all such security requirements by de-sign. In the following, we describe and reason about how thedesign ofF IST B UMPindeed meets each security requirement.First, extension messages underF IST B UMPcannot be sentby the renderer process, because the content script is moved tothe extension process inF IST B UMP. Therefore, the messagecan only come from the extension process (which is secureagainstAttacker RW), and thus all sender information can be --- page 24 --- USENIX Association 32nd USENIX Security Symposium 7065 --- page 25 --- trusted. Thus,F IST B UMPdoes not impose the responsibilityof Security Req. 1 on extension developers, and accordinglyeliminate all the corresponding vulnerabilities.Second, the extension storage cannot be accessed by therenderer process underF IST B UMP, because the extensionstorage is only accessible from the extension process. There-fore, all the data saved in the extension storage is secureagainstAttacker RW, eliminating all the vulnerabilities corre-sponds to Security Req. 2.Lastly, the memory footprints of content scripts cannotbe accessed by the renderer process, because the contentscript runs in separate virtual address space inF IST B UMP.Therefore,Attacker RandAttacker RWcannot fetch any datafrom the content script, and thusF IST B UMPdoes not imposeSecurity Req. 3 and mitigate all corresponding vulnerabilities.Moving the content script to the extension process mayexpose additional attack surfaces.Attacker RWcan spoof amessage fromDOM Proxy, but messages betweenDOM Proxyandcontent script worker use existing extension message imple-mentation and contain purely structured data. They do notexchange JavaScript code or pointer andDOM Proxycannot di-rectly alter the control ow of content script worker.Furthermore, the content script worker runs with contentscript privileges and cannot run remote code, e.g., code pro-vided by the attacker. Therefore, for the attacker to exploitthe extension process, they need to nd either: •an arbitrary code execution vulnerability in the contentscript and a CSP-bypass vulnerability, or •a gadget in content script to trigger and a gadget to ex-ploit a memory corruption.We believe these vulnerabilities are difcult to be found,and if found, they would allow more serious attacks with-out the need of the extension. There were no CSP bypassvulnerabilities reported in 2022 and all memory corruptionbugs required passing invalid argument or specic user in-teractions [18], which are highly unlikely in normal contentscripts.Exploit Mitigation.In order to check ifF IST B UMPstopsthe concrete attacks that we demonstrated in §4, we tried toreproduce the attack while running the Chromium browserwithF IST B UMP. For each extension, we rst installed it inF IST B UMP-enabled Chrome, and then launched a rendererremote code execution (RCE) attack based on a type confu-sion vulnerability CVE-2022-1134 [42]. Then we executedprivilege escalation attacks PoC we created in §4. The re-sult showed that the same privilege escalation attack againstall tested extensions are no longer working, indicating thatthe security design and its implementation ofF IST B UMPiseffective as expected.Figure 6:Mean runtime of each operation in original Chrome(baseline) andF IST B UMP-enabled Chrome. Runtime ofdom.insertis normalized to a unit operation. Error bars represent one standarddeviation. 7.2 Backward CompatibilityUnit Test.We ran a Chromium unit test suite, which includes75 unit test on the content script API [17]. We found all 75unit tests passed, showing the content script implementationof F IST B UMP is correct and backward compatible.Limitation.JavaScript uses an event loop, which waits andprocesses a message on a message queue. Each messageis a function call and runs to completion, i.e., is processedcompletely before processing the next message. In otherword, the message processing blocks the runtime. However,withDOM Proxy, each expression or statement is evaluated inseparate messages. This allows other message such as anevent handler to be processed in the middle of running a codeblock and cause inconsistency.We tested all analyzed extensions how this limitation af-fect their operation. We installed the extension on bothF IST B UMP-enabled browser and original browser and com-pared their behavior, while performing their functionality. Forexample, with a password manager extension, we saved apassword and checked that it gets successfully lled onto thelogin form.We did not nd instances where this limitation alters theextension behavior. Nonetheless, to ensure consistency,DOM Proxycan be implemented synchronously to block theevent loop until the content script worker runs to completion.7.3 PerformanceThe runtime performance of browsers is always critical, asit signicantly impacts user experiences. Because the con-tent script worker uses the same JavaScript engine, there isno additional overhead running pure JavaScript. However, --- page 26 --- 7066 32nd USENIX Security Symposium USENIX Association --- page 27 --- sinceF IST B UMPintroduces non-trivial changes in the exten-sion architecture, we measured the performance overheadof DOM operations and extension API calls inF IST B UMP.Figure 6shows mean runtime of each operation compared tothe original browser.The IPC overhead betweenDOM Proxyand content scriptintroduces approximately 235 ns latency in a single DOMoperation such as reading a content (dom.read) or settingthe value of an element (dom.write). However, commonDOM operations such as inserting elements (dom.insert)consist of multiple operation without side effects. With batchprocessing, these operations can be processed with a singleIPC, effectively reducing the overhead to approximately 7 ns(13 %).We saw approximately 28 % performance improvementin calls to basic extension APIs such as retrieving metadata(api.metadata), as the extension process can process therequest directly. We also observed approximately 87 % im-provement in extension messaging (message.cs/ep) as it isprocessed in the extension process rather than via IPC. How-ever, there is approximately 9 % overhead in storage access(storage.get/set), presumably because the content scriptworker has to go through the background page to access theextension storage.As a result,F IST B UMPshows up to 13 % runtime over-head in extensions with heavy DOM or storage operationsand may show performance improvement in message-heavyextensions.Memory.To measure the memory overhead, we took asnapshot of memory using Chrome DevTools.DOM Proxyanda content script worker add approximately 3.4 MB memoryoverhead with additional 1.2 KB each time the delegate objectand the corresponding reference is created. We observedreferences of delegate objects that are no longer used aresuccessfully garbage-collected, when the memory pressure ishigh. 8 DiscussionExtension Vulnerabilities due to Browser Implementa-tions.During our research, we found several vulnerabilitieson the browser extension implementation. For example, inChrome, Firefox, and Safari,Attacker RWcould spoof a mes-sage from or access the storage of extension that has notinjected a content script. This was an independently knownissue in Chrome, and they have deployed the ContentScript-Tracker in Chrome 103 for message passing and 105 for stor-age [13,15]. Safari has conrmed and xed the issue, andassigned CVE-2022-32784 [2]. The issue is conrmed byFirefox but not yet xed.In Chrome, Firefox, and Safari,Attacker RWcould alsospoof the URL or origin of the sender. This was also an in-dependently known issue in Chrome but not yet xed. Theissue has been conrmed by Firefox but not yet xed. Fire-fox also does not provide the origin of the sender, and wesubmitted a patch to add support for the origin. The issuehas been conrmed and xed by Safari, and assigned withCVE-2022-32784 [2].In Chrome and Firefox, there are several instancesAttacker RWcould send message to other extension compo-nents which content scripts normally cannot send messageto. Finally, we found several bugs where the sender infor-mation is not available or incorrect (some bugs were knownissues) [12, 14, 16].Responsible Disclosure and Vendor Response.We re-sponsibly disclosed our ndings to extension developers andbrowser vendors through the vulnerability reporting processor email. However, many extension developers did not ac-knowledge or x the issue. In these cases, we reported theissue to Chrome Web Store. Furthermore, some cases wereimpossible to x, and we learned that most extension devel-opers do not have (or do not need) deep understanding ofthe browser security architecture. This supports our analysisin §3 and rationalizes our approach to redesign the extensionarchitecture in §5, which satises the security requirementsby design.Motivated by our ndings, the Chromium team is dis-cussing to limit the access to extension storage from contentscripts in their next extension API version. We note thatcompared toF IST B UMP, this approach only mitigates thevulnerabilities due to Security Req. 2.Large-Scale Analysis.We nd that 18,432 (about 15 %) outof collected extensions insert a content script to all pages anduse the messaging or storage API. We could not automate theanalysis as JavaScript supports dynamic function invocation,and les are usually bundled and minimized, making staticcode analysis difcult. Furthermore, understanding high-levelfunctionality is needed to properly identify vulnerabilities.We believe a large-scale analysis would help identify morevulnerabilities and leave it for future work.Potential Bypass Attacks againstF IST B UMP.F IST B UMPrelies on the process isolation boundary provided by thebrowser and operating system. Such cross-process or ker-nel attacks are out of scope of this paper, andF IST B UMPmust be combined with mitigation on the hardware and OSlevel.Improving Performance ofF IST B UMPJavaScript engineand rendering engine have multiple optimizations for DOMoperations. However,F IST B UMPseparates DOM code fromwhere the operations actually happen, reducing opportunitiesfor optimizations. Making JavaScript engine and renderingengine aware ofDOM Proxyand optimizing them forDOM Proxy may improve performance. --- page 28 --- USENIX Association 32nd USENIX Security Symposium 7067 --- page 29 --- 9 Related workThe security of browser plugins and extensions has been ma-jor concern in web security. Research works can be classiedinto categories: (i) protecting browser from malicious exten-sion and (ii) protecting browser from web pages exploitingbenign-but-buggy extensions. Both goals are orthogonal, butprotecting from malicious extension may also help protectingfrom benign-but-buggy extensions, as if what the extensioncan do is limited in the rst place, the compromised extensionis also limited.Earlier works focused on execution monitoring. Janus [25]proposed a sandbox environment for browser helper appli-cations. Louw et al. [57] proposed code integrity check andruntime policy monitoring for Firefox add-ons. Many re-search prototype browsers including OP [27], Gazelle [61],IBOS [56], and OP2 [28] also proposed isolating web princi-pals using the OS process domain.Barth et al. [3] found most Firefox extensions request ex-cess permissions and designed the Chrome extension archi-tecture with the PoLP and privilege separation. However, Feltet al. [22], Guha et. al [29], and Carlini et al. [6] showedmany extensions still request excess permissions, renderingprivilege separation useless and increasing the attack surface.They concluded that privilege separation is rarely needed (buteffective) and developers accidentally or intentionally makeprivilege separation ineffective, which supports our nding.Guha et. al [29] proposed IBEX, a static verication andne-grained access control using Datalog for provably secureextension.Calzavara et al. [5] performed a formal analysis on privi-lege escalation via message passing interface. Some [54] andFass et al. [21] performed data-ow analysis to detect mes-sage ows that attackers can exploit to elevate their privilege.However, they focused messaging interfaces which normalweb page can access, not considering renderer attacker. Tothe best of our knowledge, our work is the rst to compre-hensively analyze threats against real-world extensions byrenderer attackers.Furthermore, since the extension storage was introducedfairly recently in 2014, to the best of our knowledge, our workis the rst to analyze the security implication of the extensionstorage.Extension Fingerprinting.There are also several works onngerprinting, i.e., identifying which extensions are installed.Sjösten et al. [53], Sanchez-Rola et al. [51], and Gulyás etal. [30] used web accessible resources (WAR) to detect thepresence of specic browser extensions. XHOUND [55] andLaperdrix et al. [36] proposed using DOM modications andstylesheets injected by extension, respectively. Carnus [32]suggested a behavior-based ngerprinting by monitoring com-munication patterns.Identifying which extensions are installed would helplaunch the attack described in our paper, as it allows targetedattacks.Principle of Least Privilege.PoLP and privilege separa-tion are fundamental principle in software engineering [50].The web browser is analogous to operating system where thebrowser process is kernel, web pages are normal applicationand extensions are privileged application or kernel extensions.10 ConclusionThis paper identied the design issues of the current extensionarchitecture, which imposes strict security requirements fromextension developers. We further demonstrated the criticalityof these issues through analyzing popular extensions, whichdiscovered 59 vulnerabilities from 40 extensions. Recogniz-ing the pressing security needs on this problem, we furtherpresentF IST B UMP, the new extension architecture to elimi-nate all such vulnerabilities by design. AcknowledgmentsThe authors would like to thank our anonymous reviewersand shepherd for their insightful and valuable feedback. Thiswork was supported by Institute for Information & commu-nications Technology Promotion (IITP) grant funded by theKorean government (MSIT) (No.2020-0-01840, Analysis ontechnique of accessing and acquiring user data in smartphone).This work was supported by National Research Foundation ofKorea (NRF) grant funded by the Korean government (MSIT)(NRF-2019R1C1C1006095). The Institute of EngineeringResearch (IOER) and Automation and Systems Research In-stitute (ASRI) at Seoul National University provided researchfacilities for this work. References [1]Apple Developer Documentation. Safari app extensions.URLhttps://developer.apple.com/documentation/ safariservices/safari_app_extensions . [2]Apple Support. About the security content of safari 15.6, 2022. URLhttps://support.apple.com/en-us/HT213341 . [3]A. Barth, A. P. Felt, P. Saxena, and A. Boodman. Pro-tecting browsers from extension vulnerabilities. InNDSS,2010. URLhttps://www.ndss-symposium.org/ndss2010/ protecting-browsers-extension-vulnerabilities/ . [4]D. Callahan. The “why” of electrolysis, 2016. URLhttps://blog.mozilla.org/addons/2016/04/11/the-why- of-electrolysis/ . [5]S. Calzavara, M. Bugliesi, S. Crafa, and E. Stefnlongo. Fine-graineddetection of privilege escalation attacks on browser extensions. InJ. Vitek, editor,Programming Languages and Systems, pages 510–534, Berlin, Heidelberg, 2015. Springer Berlin Heidelberg. ISBN978-3-662-46669-8. [6]N. Carlini, A. P. Felt, and D. Wagner. An evaluation of the googlechrome extension security architecture. In21st USENIX SecuritySymposium (USENIX Security 12), pages 97–111, Bellevue, WA,Aug. 2012. USENIX Association. ISBN 978-931971-95-9. URL --- page 30 --- 7068 32nd USENIX Security Symposium USENIX Association --- page 31 --- https://www.usenix.org/conference/usenixsecurity12/ technical-sessions/presentation/carlini . [7]Chrome Developers. Sandbox, . URLhttps://chromium. googlesource.com/chromium/src/+/master/docs/design/ sandbox.md . [8]Chrome Developers. Content scripts, . URLhttps://developer. chrome.com/docs/extensions/mv3/content_scripts/ . [9]Chrome Developers. Message passing, . URLhttps://developer. chrome.com/docs/extensions/mv3/messaging/ . [10]Chrome Developers. chrome.storage, . URLhttps://developer. chrome.com/docs/extensions/reference/storage/ . [11]Chrome Developers. Cross-origin xmlhttprequest, . URLhttps: //developer.chrome.com/docs/extensions/mv3/xhr/ . [12]Chromium Bug Tracker. Issue 626926: sender.url is undened whentabs.sendmessage sends to an extension page, 2016. URLhttps: //crbug.com/626926 . [13]Chromium Bug Tracker. Issue 982361: Compromised web renderershould be unable to spoof messagesender.id if it never run a contentscript from the given extension, 2019. URLhttps://crbug.com/ 982361 . [14]Chromium Bug Tracker. Issue 1050254: Messagesender.origin mightnot be available in messages from service workers, 2020. URLhttps: //crbug.com/1050254 . [15]Chromium Bug Tracker. Issue 1183604: Compromised web rendererthat *hasn't* run any content scripts can spoof chrome.storage (andother api calls) for any extension, 2021. URLhttps://crbug.com/ 1183604 . [16]Chromium Bug Tracker. Issue 1197803: Messages sent from anextension context have an incorrect `"null"` origin, 2021. URLhttps: //crbug.com/1197803 . [17]Chromium Contributors. chrome/browser/extensions/content_-script_apitest.cc. URLhttps://source.chromium.org/ chromium/chromium/src/+/refs/tags/101.0.4951.41: chrome/browser/extensions/content_script_apitest.cc . [18]cvedetails.com. Google chrome : Security vulnerabilitiespublished in 2022, 2022. URLhttps://www.cvedetails. com/vulnerability-list/vendor_id-1224/product_id- 15031/year-2022/Google-Chrome.html . [19]S. DeVaney. Firefox's most popular and innovative browser extensionsof 2021, 2021. URLhttps://addons.mozilla.org/blog/ firefoxs-most-popular-innovative-browser-extensions- of-2021/ . [20]S. DeVaney. The pandemic changed everything – eventhe way we use browser extensions, 2022. URLhttps: //addons.mozilla.org/blog/the-pandemic-changed- everything-even-the-way-we-use-browser-extensions/ . [21]A. Fass, D. F. Somé, M. Backes, and B. Stock. Doublex: Staticallydetecting vulnerable data ows in browser extensions at scale. InProceedings of the 2021 ACM SIGSAC Conference on Computer andCommunications Security, CCS '21, pages 1789–1804, New York,NY, USA, 2021. Association for Computing Machinery. ISBN9781450384544. doi: 10.1145/3460120.3484745. URLhttps: //doi.org/10.1145/3460120.3484745 . [22]A. P. Felt, K. Greenwood, and D. Wagner. The effectiveness of applica-tion permissions. In2nd USENIX Conference on Web Application De-velopment (WebApps 11), Portland, OR, June 2011. USENIX Associ-ation. URLhttps://www.usenix.org/conference/webapps11/ effectiveness-application-permissions . [23]Firefox Site Compatibility. Plug-in support has been droppedother than ash. URLhttps://www.fxsitecompat.com/en- CA/docs/2016/plug-in-support-has-been-dropped-other- than-flash/ . [24]A. Gakhokidze. Introducing refox's new site isolation securityarchitecture, 2021. URLhttps://hacks.mozilla.org/2021/ 05/introducing-firefox-new-site-isolation-security- architecture/ . [25]I. Goldberg, D. Wagner, R. Thomas, and E. A. Brewer. A secureenvironment for untrusted helper applications conning the wily hacker.InProceedings of the 6th Conference on USENIX Security Symposium,Focusing on Applications of Cryptography - Volume 6, SSYM'96,page 1, USA, 1996. USENIX Association. [26]Google Inc. Domato, 2017. URLhttps://github.com/ googleprojectzero/domato . [27]C. Grier, S. Tang, and S. T. King. Secure web browsing with the opweb browser. In2008 IEEE Symposium on Security and Privacy (sp2008) , pages 402–416, 2008. doi: 10.1109/SP.2008.19. [28]C. Grier, S. Tang, and S. T. King. Designing and implementingthe op and op2 web browsers.ACM Trans. Web, 5(2), may 2011.ISSN 1559-1131. doi: 10.1145/1961659.1961665. URLhttps: //doi.org/10.1145/1961659.1961665 . [29]A. Guha, M. Fredrikson, B. Livshits, and N. Swamy. Veried securityfor browser extensions. In2011 IEEE Symposium on Security andPrivacy, pages 115–130, 2011. doi: 10.1109/SP.2011.36. URLhttps://ieeexplore.ieee.org/document/5958025 . [30]G. G. Gulyas, D. F. Some, N. Bielova, and C. Castelluccia. Toextend or not to extend: On the uniqueness of browser extensions andweb logins. InProceedings of the 2018 Workshop on Privacy in theElectronic Society, WPES'18, pages 14–27, New York, NY, USA,2018. Association for Computing Machinery. ISBN 9781450359894.doi: 10.1145/3267323.3268959. URLhttps://doi.org/10.1145/ 3267323.3268959 . [31]J. Jang-Jaccard and S. Nepal. A survey of emerging threats in cy-bersecurity.Journal of Computer and System Sciences, 80(5):973–993, 2014. ISSN 0022-0000. doi: https://doi.org/10.1016/j.jcss.2014.02.005. URLhttps://www.sciencedirect.com/science/ article/pii/S0022000014000178. Special Issue on Dependableand Secure Computing. [32]S. Karami, P. Ilia, K. Solomos, and J. Polakis. Carnus: Exploring theprivacy threats of browser extension ngerprinting. InNDSS, 2020.URLhttps://www.ndss-symposium.org/ndss-paper/carnus- exploring-the-privacy-threats-of-browser-extension- fingerprinting/ . [33]P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Ham-burg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom.Spectre attacks: Exploiting speculative execution. In2019 IEEESymposium on Security and Privacy (SP), pages 1–19, 2019. doi:10.1109/SP.2019.00002. URLhttps://ieeexplore.ieee.org/ document/8835233 . [34]M. Kosaka. Inside look at modern web browser (part 1), 2018.URLhttps://developer.chrome.com/blog/inside-browser- part1/ . [35]A. Laforge. Moving forward from chrome apps. URLhttps://blog.chromium.org/2020/01/moving-forward- from-chrome-apps.html . [36]P. Laperdrix, O. Starov, Q. Chen, A. Kapravelos, and N. Nikiforakis.Fingerprinting in style: Detecting browser extensions via injected stylesheets. In30th USENIX Security Symposium (USENIX Security 21),pages 2507–2524. USENIX Association, Aug. 2021. ISBN 978-1-939133-24-3. URLhttps://www.usenix.org/conference/ usenixsecurity21/presentation/laperdrix . [37]M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh,J. Horn, S. Mangard, P. Kocher, D. Genkin, Y. Yarom, and M. Ham-burg. Meltdown: Reading kernel memory from user space. In27thUSENIX Security Symposium (USENIX Security 18), pages 973–990,Baltimore, MD, Aug. 2018. USENIX Association. ISBN 978-1-939133-04-5. URLhttps://www.usenix.org/conference/ --- page 32 --- USENIX Association 32nd USENIX Security Symposium 7069 --- page 33 --- usenixsecurity18/presentation/lipp . [38]L. Liu, X. Zhang, G. Yan, and S. Chen. Chrome extensions:Threat analysis and countermeasures. InNDSS, 2012. URLhttps://www.ndss-symposium.org/ndss2012/ndss-2012- programme/chrome-extensions-threat-analysis-and- countermeasures/ . [39]MDN Web Doc. Background scripts, . URLhttps: //developer.mozilla.org/en-US/docs/Mozilla/Add- ons/WebExtensions/Background_scripts . [40]MDN Web Doc. Same-origin policy, . URLhttps: //developer.mozilla.org/en-US/docs/Web/Security/Same- origin_policy . [41]MDN Web Doc. Webextensions. Technical report,. URLhttps://developer.mozilla.org/ko/docs/Mozilla/ Add-ons/WebExtensions . [42]M. Y. Mo. The chromium super (inline cache) type confusion,2022. URLhttps://github.blog/2022-06-29-the-chromium- super-inline-cache-type-confusion/ . [43]M. Moroz and S. Glazunov. Analysis of uxss exploits and mitigationsin chromium. Technical report, 2019. [44]C. Morris and J. Rossi. A break from the past, part 2:Saying goodbye to activex, vbscript, attachevent... URLhttps://blogs.windows.com/msedgedev/2015/05/06/a- break-from-the-past-part-2-saying-goodbye-to- activex-vbscript-attachevent/ . [45]Mozilla Security Blog. Mitigations landing for new class of timingattack. URLhttps://blog.mozilla.org/security/2018/01/ 03/mitigations-landing-new-class-timing-attack/ . [46]K. Needham. The future of developing refox add-ons. URLhttps://blog.mozilla.org/addons/2015/08/21/ the-future-of-developing-firefox-add-ons/ . [47]Y. Oren, V. P. Kemerlis, S. Sethumadhavan, and A. D. Keromytis.The spy in the sandbox: Practical cache attacks in javascript and theirimplications. InProceedings of the 22nd ACM SIGSAC Conference onComputer and Communications Security, CCS '15, page 1406–1418,New York, NY, USA, 2015. Association for Computing Machinery.ISBN 9781450338325. doi: 10.1145/2810103.2813708. URLhttps: //doi.org/10.1145/2810103.2813708 . [48]C. Reis. Multi-process architecture, 2008. URLhttps://blog. chromium.org/2008/09/multi-process-architecture.html . [49]C. Reis, A. Moshchuk, and N. Oskov. Site isolation: Processseparation for web sites within the browser. In28th USENIX Se-curity Symposium (USENIX Security 19), pages 1661–1678, SantaClara, CA, Aug. 2019. USENIX Association. ISBN 978-1-939133-06-9. URLhttps://www.usenix.org/conference/ usenixsecurity19/presentation/reis . [50]J. Saltzer and M. Schroeder. The protection of information in computersystems.Proceedings of the IEEE, 63(9):1278–1308, 1975. doi:10.1109/PROC.1975.9939. [51]I. Sanchez-Rola, I. Santos, and D. Balzarotti. Extension break-down: Security analysis of browsers extension resources con-trol policies. In26th USENIX Security Symposium (USENIXSecurity 17), pages 679–694, Vancouver, BC, Aug. 2017.USENIX Association. ISBN 978-1-931971-40-9. URLhttps://www.usenix.org/conference/usenixsecurity17/ technical-sessions/presentation/sanchez-rola . [52]J. Schuh. Saying goodbye to our old friend npapi. URLhttps://blog.chromium.org/2013/09/saying-goodbye-to- our-old-friend-npapi.html . [53]A. Sjösten, S. Van Acker, and A. Sabelfeld. Discovering browserextensions via web accessible resources. InProceedings of the SeventhACM on Conference on Data and Application Security and Privacy,CODASPY '17, pages 329–336, New York, NY, USA, 2017. As-sociation for Computing Machinery. ISBN 9781450345231. doi:10.1145/3029806.3029820. URLhttps://doi.org/10.1145/ 3029806.3029820 . [54]D. F. Somé. Empoweb: Empowering web applications with browserextensions. In2019 IEEE Symposium on Security and Privacy (SP),pages 227–245, 2019. doi: 10.1109/SP.2019.00058. URLhttps: //ieeexplore.ieee.org/document/8835286 . [55]O. Starov and N. Nikiforakis. Xhound: Quantifying the ngerprintabil-ity of browser extensions. In2017 IEEE Symposium on Security andPrivacy (SP), pages 941–956, 2017. doi: 10.1109/SP.2017.18. URLhttps://ieeexplore.ieee.org/document/7958618 . [56]S. Tang, H. Mai, and S. T. King. Trust and protection in the illinoisbrowser operating system. InProceedings of the 9th USENIX Con-ference on Operating Systems Design and Implementation, OSDI'10,page 17–31, USA, 2010. USENIX Association. [57]M. Ter Louw, J. S. Lim, and V. N. Venkatakrishnan. Extensible webbrowser security. InProceedings of the 4th International Conferenceon Detection of Intrusions and Malware, and Vulnerability Assessment,DIMVA '07, page 1–19, Berlin, Heidelberg, 2007. Springer-Verlag.ISBN 9783540736134. doi: 10.1007/978-3-540-73614-1_1. URLhttps://doi.org/10.1007/978-3-540-73614-1_1 . [58]The Chromium Authors. What are extensions?, 2013. URLhttps: //developer.chrome.com/docs/extensions/mv3/overview/ . [59]The Chromium Projects. Site isolation. URLhttps: //sites.google.com/a/chromium.org/dev/Home/chromium- security/site-isolation . [60]J. Wagner. Trustworthy chrome extensions, by default, 2018. URLhttps://blog.chromium.org/2018/10/trustworthy-chrome- extensions-by-default.html . [61]H. Wang, C. Grier, A. Moshchuk, S. T. King, P. Choudhury,H. Venter, and S. King. The multi-principal os constructionof the gazelle web browser. Technical Report MSR-TR-2009-16, February 2009. URLhttps://www.microsoft.com/en- us/research/publication/the-multi-principal-os- construction-of-the-gazelle-web-browser/. MSRTechnical Report. [62]S. Weinig, M. Stachowiak, D. Bates, S. Fraser, A. Roben, A. Kling,and C. A. L. Perez. Webkit2, 2010. URLhttps://trac.webkit. org/wiki/WebKit2 . [63]Y. Weiss and E. Kitamura. Aligning timers with cross origin isola-tion restrictions. URLhttps://developer.chrome.com/blog/ cross-origin-isolated-hr-timers/ . [64]A. Zeigler. IE8 and loosely-coupled IE (LCIE), 2008.URLhttps://learn.microsoft.com/en-us/archive/blogs/ ie/ie8-and-loosely-coupled-ie-lcie . [65]R. Zhao, C. Yue, and Q. Yi. Automatic detection of information leakagevulnerabilities in browser extensions. InProceedings of the 24thInternational Conference on World Wide Web, WWW '15, pages 1384–1394, Republic and Canton of Geneva, CHE, 2015. International WorldWide Web Conferences Steering Committee. ISBN 9781450334693.doi: 10.1145/2736277.2741134. URLhttps://doi.org/10.1145/ 2736277.2741134 . A List of Analyzed Extensions Table 2 lists analyzed extensions on Chrome Web Store. --- page 34 --- 7070 32nd USENIX Security Symposium USENIX Association --- page 35 --- Extension ID Name Version Usersaapbdbdomjkkjkaonfhkkikfgjllcleb Google Translate 2.0.12 10M+ bgnkhhnnamicmpeenaelnjfhikgbkllg AdGuard AdBlocker 4.0.161 10M+ bmnlcjabgnpnenekpadlanbbkooimhnj Honey 14.8.0 10M+ cfhdojbkjhnklbpkdaibdccddilifddb Adblock Plus - free ad blocker 3.12 10M+ cjpalhdlnbpafiamejdnhcphjbkeiagm uBlock Origin 1.42.4 10M+ cmedhionkhpnakcndndgjdbohmhepckk Adblock for Youtube™ 5.1.7 10M+ dhdgffkkebhmkfjojejmpbldmpobfkfo Tampermonkey 4.16 10M+ ecnphlgnajanjnkcmbpancdjoidceilk Kami for Google Chrome™ 2.0.15049 10M+ efaidnbmnnnibpcajpcglclefindmkaj Adobe Acrobat: PDF edit & convert & sign tools 15.1.3.10 10M+ gighmmpiobklfepjocnamgkkbiglidom AdBlock – best ad blocker 4.44.0 10M+ hdokiejnpimakedhajhdlcegeplioahd LastPass: Free Password Manager 4.92.0.1 10M+ inoeonmfapjbbkmdafoankkfajkcphgd Read&Write for Google Chrome™ 2.0.1 10M+ inomeogfingihgjfjlpeplalcfajhgai Chrome Remote Desktop 1.5 10M+ jgfbgkjjlonelmpenhpfeeljjlcgnkpe ClassLink OneClick Extension 10.6 10M+ jlhmfgmfgeifomenelglieieghnjghma Cisco Webex Extension 1.17.0 10M+ kbfnbcaeplbcioakkpcpgfkobkghlhen Grammarly for Chrome 14.1056.0 10M+ mmeijimgabbpbgpdklnllpncmdofkcpn Screencastify - Screen Video Recorder 2.67.0.4291 10M+ nkbihfbeogaeaoehlefnkodbefgpgknn MetaMask 10.12.4 10M+ nopfnnpnopgmcnkjchnlpomggcdjfepo Clever 1.17.1 10M+ oocalimimngaihdkbihfgmpkcpnmlaoa Netix Party is now Teleparty 3.4.0 10M+ ppnbnpeolgkicgegkbkbjmhlideopiji Windows Accounts 1.0.6 10M+ pbjikboenpfhbbejgkoklgkhjpfogcam Amazon Assistant for Chrome 10.2107.7.11654 8M+ caljgklbbfbcjjanaijlacgncafpegll Avira Password Manager 2.18.5.3877 5M+ fdjamakpfbbddfjaooikfcpapjohcfmg Dashlane - Password Manager 6.2212.2 5M+ admmjipmmciaobhojoghlmleefbicajg Norton Password Manager 7.5.1.48 4M+ ndjpnladcallmjemlbaebfadecfhkepb Ofce 2.2.9 4M+ aeblfdkhhhdcdjpifhhbdiojplfjncoa 1Password – Password Manager 2.3.2 2M+ bfnaelmomeimhlpmgjnjophhpkkoljpa Phantom 22.3.29 2M+ fnjhmkhhmkbjkkabndcnnogagogbneec Ronin Wallet 1.7.0 2M+ hnmpcagpplmpfojmgmnngilcnanddlhb Windscribe - Free Proxy and Ad Blocker 3.4.0 2M+ mlomiejdfkolichcflejclcbmpeaniij Ghostery – Privacy Ad Blocker 8.6.3 2M+ nngceckbapebfimnlniiiahkandclblb Bitwarden - Free Password Manager 1.57.0 2M+ fhbohimaelbohpjbbldcngcnapndodjp Binance Wallet 2.12.2 1M+ hnfanknocfeofbddgcijnmhnfnkdnaad Coinbase Wallet extension 2.12.2 1M+ kacljcbejojnapnmiifgckbafkojcncf Ad-Blocker 1.5 1M+ lgblnfidahcdcjddiepkckcfdhpknnjh Fair AdBlocker 1.524 1M+ pkehgijcmpdhfbdbbnkijodmdjhbjlgp Privacy Badger 2021.11.23.1 1M+ ohahllgiabjaoigichmmfljhkcfikeof AdBlocker Ultimate 3.7.16 0.9M+ aiifbnbfobpmeekipheeijimdpnlpgpp Terra Station Wallet 2.7.0 0.7M+ pnlccmojcmeohlpggmfnbbiapkmbliob RoboForm Password Manager 9.3.2.0 0.6M+ bfogiafebfohielmmehodmfbbebbbpei Keeper® Password Manager & Digital Vault 16.4.0 0.5M+ dmkamcknogkgcdfhhbddcghachkejeap Keplr 0.10.0 0.5M+ ibnejdfjmmkpcnlpebklmnkoeoihofec TronLink 3.26.4 0.5M+ ffnbelfdoeiohenkjibnmadjiehjhajb Yoroi 4.11.500 0.4M+ fhmfendgdocmcbmfikdcogofphimnkno Sollet 0.3.1 0.2M+ jblndlipeogpafnldhgmapagcccfchpi Kaikas 1.10.1 0.2M+Table 2: List of analyzed extensions on Chrome Web Store. --- page 36 --- USENIX Association 32nd USENIX Security Symposium 7071 --- page 37 --- d o m . r e ad d o m . w rit e d o m . in s e r t api . me t adat a mes s a ge . cs mes s a ge . ep s t o ra ge . ge t s t o ra ge . s et0 100 200 300 400Runtime [ns]BaselineFistBump(normalized) --- page 38 --- DOMPage ScriptContent ScriptBrowser APIMessage PassingStorageRenderer process Extension process Browser processExtension PageIsolated World --- page 39 --- DOMPage ScriptContent ScriptExtension Storage [Credentials]Renderer process Admin pageExtension process Browser processExtension PageFrom: C, admin page To: E, extension page Message: get credsFrom: E, extension page To: C, admin page Message: [Credentials] Page Script Renderer process Attacker's pageFrom: C, attacker's page To: E, extension page Message: get credsNot checked![Credentials] --- page 40 --- Violated requirementExtension StorageContent Script§4.1 Execute Browser APIExtension Page§4.2 /3 Write /Read SensitiveData§ 3.1 Extension Message Auth.§ 3.2 Non-sensitive Data in Extension StorageAttackerRWAttackerRMessage Passing§ 3.3 Non-sensitive Data in Content Script --- page 41 --- DOMPage ScriptBrowser APIStorageRenderer process Extension process Browser processIsolated World Content ScriptDOM ProxyExtension PageNew or modified componentsMessage Passing --- page 42 --- Content Script WorkerCallExpression alert( document.domain)Identifier Name: aler t Arguments( MemberExpression ) Identifier Name: document Identifier Name: domai n.GET("alert")CALL(#1, "example.com")windowdocument aler t#1#2domain example.comDOM DOMProxy#1 --- page 43 ---