![]() ![]() In an age where we have platforms such as Electron and NW.js, which seem intent on taking the systemic issue of Cross-site Scripting (XSS) to the desktop and turning it all into Remote Code Execution (RCE) without any safeguards Chrome’s extension environment is a solid foundation on an otherwise shaky landscape. Their architecture makes this very clear as I’ll discuss below, and a lot of it is all designed with the core idea of making an environment where developers cannot easily shoot themselves in the foot. To be upfront and explicit: the developers behind Chrome have put a lot of thought into extension security and insecure anti-patterns. This guide attempts to outline extension security anti-patterns, as well as provide a usable service ( tarnish ) to aide developers and security researchers in auditing Chrome extensions.īefore diving into security anti-patterns in Chrome extensions it’s important to get an understanding of how exactly these extensions are structured. Given the incredible popularity of the Chrome browser and its extensions, it seems that this platform is definitely deserving of a closer look into the security pitfalls that can occur. For example, the Steam Inventory Helper extension suffered from a vulnerability that resulted in arbitrary JavaScript execution in the Background Page context, resulting in the ability to hijack all of the accounts of the victim, on every website they were authenticated to. It results in the ability to abuse any of the declared APIs of the extension, such as the ability to access all sites as the victim, modify/edit browser bookmarks, history, and more. In short: vulnerabilities in the Background Pages, the pages with access to all of the privileged extension APIs, are much worse than any regular XSS. This example is not even a worst case scenario, due to the fact this XSS was in a Content Script of the extension and not in a Background Page (this guide will dive into the differences). ![]() For a good summary of that vulnerability, see this write up on it the extension had 1.5 million users at the time. One big example was the case of a Cross-site Scripting (XSS) vulnerability in the Reddit Enhancement Suite (RES) extension that allowed for wormable exploitation. Of course, it’s not as if security issues in Chrome extensions haven’t been found or are particularly rare. Other results appear to be out-of-date, such as this Chrome extension fingerprinting guide, which no longer works for new Chrome extensions. Searching the internet for guides and tools for auditing Chrome extensions yields very little, an academic paper written to describe Chrome’s extension security model and a 2013 blog post on an example of XSS in an intentionally-vulnerable extension. Especially when compared to other platforms such as Electron, which have had extension research on the topic. Kicking the Rims – A Guide for Securely Writing and Auditing Chrome Extensions A Thin Layer of Chrome Extension Security Prior-ArtĬhrome extension security and methodologies for auditing Chrome extensions for vulnerabilities appears to be a topic with shockingly little prior art. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |