Modern web applications are increasingly moving programcode to the client in the form of JavaScript. Meanwhile, moreand more vulnerabilities occurring purely on the client throughinteracting with the Document Object Model (DOM) can bediscovered. The DOM is a treelike structure providing APIs foraccessing, traversing, and mutating the structure and contentof HTML elements at runtime. One prevalent and severeclass of client-side vulnerabilities is DOM-based cross-sitescripting (XSS), which is caused by unsafe data flows fromattacker-controlled sources, such as URLs and form inputs,into security sensitive APIs, resulting in malicious JavaScriptcode injection and execution. In a recent study, it is shownthat approximately 10% of the Alexa Top 5000 websites carryat least one DOM-based XSS vulnerability [1]. In the researchcommunity, DOM-based XSS has attracted much attention [1–7].However, there is a special kind of client-side XSS that hasnot been taken seriously and well-studied. We name it DOM-sourced XSS to distinguish it from conventional DOM-basedXSS. DOM-based XSS emphasizes the vulnerability occursduring manipulating the DOM, whereas DOM-sourced XSSstresses the DOM as a new kind of attack surface. For regularwebsite scripts, they might take the website DOM as an input,but the website DOM could never be controlled by the attacker.Meanwhile, the attacker-controllable website is not able toaccess the resources of the target website due to the Same-Origin Policy (SOP) complied by modern browsers whichconstrains the access to website resources within the samedomain. However, this is not the case for browser extensionscripts. The browser extension mechanism allows third partiesto modify the browser’s behavior, enhance its functionalityand GUI, and integrate it with popular web services byinjecting a piece of script. Such scripts are provided withmany powerful privileges such as violating the SOP. In thisway, a vulnerable browser extension script is able to take theattacker-controllable website DOM as a source, and executethe malicious code injected by the attacker accessing resourcesof the target website across the domain through the privilege,leading to a DOM-sourced XSS. Comparing with conventionalDOM-based XSS, DOM-sourced XSS in browser extensionshas two attacker-favorable features. First, DOM sources aremore trusted by the developer than other sources, resultingin less sanitization. Second, the attacker-injected scripts areequipped with more powerful privileges.In our work, we focus on a more specific kind of DOM-sourced XSS appearing in Greasemonkey. Greasemonkey is avery popular cross-browser extension enabling users to writelightweight JavaScript programs called user scripts (e.g. theexample shown in Fig. 1) to manipulate loaded web pageson the client-side as desired. Large number of user scriptsare created and shared among the community. Unfortunately,besides the convenience, user scripts bring about new securityissues as well. Although Greasemonkey makes use of sandbox-ing to protect the privileged functions from possibly maliciousscripts running on a website, a poorly-written user script canstill introduce unsafe code vulnerable to DOM-sourced XSSin the sandboxed environment by executing a string from amalicious page without performing the proper sanity checks.More specifically, the directive of Greasemonkey specifyingthe target scope might be overly generic, allowing attacker- controlled web page DOM to be taken as the input for theuser script. (e.g. the first wildcard used in line 8 of Fig. 1)Moreover, the Greasemonkey script is privileged with cross-domain requests, allowing attacker-controlled scripts to accessresources from arbitrary domains by sending arbitrary requeststowards any website with the user’s cookies embedded inthem, and reading the corresponding responses. (e.g. theprivileged APIGMxmlhttpRequestgranted in line 10 of Fig.1 has the ability to perform cross-domain requests) Therefore,the DOM-sourced XSS in Greasemonkey is able to affect abroader range of targets, making more severe impact.Unfortunately, there are no existing approaches which areable to discover DOM-sourced XSS in Greasemonkey. In thispaper, we propose a detecting framework employing bothstatic and dynamic techniques. First, a suspicious script isanalyzed by the lightweight static analysis consists of a textfilter and an abstract syntax tree (AST) parser. The textfilter analyses the metadata to check overly generic directivesand granted privileges. The AST parser searches the scriptcode for potential attacker-controllable sources and security-sensitive sinks. If the script remains suspicious after the staticanalysis, the dynamic symbolic execution is then employedto detect potential exploitable flows. To tackle the problemof generating the exploiting hierarchical document (e.g. theone shown in Fig. 2) which is not supported by existingtechniques, we introduce an additional shadow DOM compo-nent maintaining the hierarchical structure during the dynamicsymbolic execution. The shadow DOM is able to avoid errorsdue to accessing non-existent DOM elements. Combining thestructure from the shadow DOM and the values solved fromthe symbolic constraints by the SMT solver, a proof-of-conceptdocument exploiting the vulnerable script can be constructedto demonstrate the presence of DOM-sourced XSS withoutany false positives.To practically validate our approach, we conducted a large-scale experiment. Using a data set of 154,065 Greasemonkeyuser scripts, we successfully discovered 58 DOM-sourced XSSvulnerabilities with total 676,174 installations.To summarize, this paper makes the following contributions:∙The notion of DOM-sourced XSS which emphasizes thehierarchical document source and distinguishes it fromDOM-based XSS.∙An additional shadow DOM component during dynamicsymbolic execution maintaining the hierarchical docu-ment structure, which is helpful in detecting DOM-sourced vulnerabilities.∙A hybrid analysis framework detecting DOM-sourcedXSS in user scripts of the browser extension Greasemon-key.∙An empirical experiment which discovers 58 real-worldvulnerabilities, demonstrating the existence of DOM-sourced XSS and the effectiveness of our detecting ap-proach.The remainder of this paper proceeds as follows: Section IIdescribes the browser extension Greasemonkey. The notion ofDOM-sourced XSS is introduced in Section III. In Section IV, we present our detecting approach aiming at DOM-sourcedXSS. The implementation is illustrated in Section V. Theexperiment setup and results are described in Section VI.Section VII discusses the prevention measures and SectionVIII presents related works. We conclude in Section IX.

DOM-sourced XSS is a noteworthy vulnerability which hasnot been paid much attention to in the research community.In this work, we have proposed the notion and a hybriddetection approach combining lightweight static analysis anddynamic symbolic execution. The shadow DOM technique isintroduced to tackle the problem of hierarchical documentinputs. Experiment results validate the presence of DOM-sourced XSS and the effectiveness of our detecting approach.At present, our technique needs manually analysis assistance.In the future, we plan to automatize it and make it more robust.Moreover, we would like to explore more potential vulnerablebrowser extensions other than Greasemonkey.

source : Detecting DOM-Sourced Cross-Site Scripting inBrowser Extensions by Jinkun Pan


Please enter your comment!
Please enter your name here