UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

XSnare : application-specific, cross-site scripting protection Pazos, Jose Carlos 2019

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Notice for Google Chrome users:
If you are having trouble viewing or searching the PDF with Google Chrome, please download it here instead.

Item Metadata

Download

Media
24-ubc_2019_november_pazos_josecarlos.pdf [ 1.09MB ]
Metadata
JSON: 24-1.0384040.json
JSON-LD: 24-1.0384040-ld.json
RDF/XML (Pretty): 24-1.0384040-rdf.xml
RDF/JSON: 24-1.0384040-rdf.json
Turtle: 24-1.0384040-turtle.txt
N-Triples: 24-1.0384040-rdf-ntriples.txt
Original Record: 24-1.0384040-source.json
Full Text
24-1.0384040-fulltext.txt
Citation
24-1.0384040.ris

Full Text

XSnare: application-specific, client-side cross-sitescripting protectionbyJose Carlos PazosB.Sc., The University of British Columbia, 2016a thesis submitted in partial fulfillmentof the requirements for the degree ofMaster Of Scienceinthe faculty of graduate and postdoctoralstudies(Computer Science)The University of British Columbia(Vancouver)October 2019c© Jose Carlos Pazos, 2019The following individuals certify that they have read, and recommend tothe Faculty of Graduate and Postdoctoral Studies for acceptance, the thesisentitled:XSnare: application-specific, client-side cross-site scriptingprotectionsubmitted by Jose Carlos Pazos in partial fulfillment of the requirementsfor the degree of Master Of Sciencein Computer Science.Examining Committee:Ivan Beschastnikh, Computer ScienceSupervisorNorm Hutchinson, Computer ScienceSupervisory Committee MemberiiAbstractWe present XSnare, a fully client-side Cross-site Scripting (xss) solution,implemented as a Firefox extension. Our approach takes advantage of avail-able previous knowledge of a web application’s Hypertext Markup Lan-guage (html) template content, as well as the rich context available inthe Document Object Model (dom) to block xss attacks. XSnare preventsxss exploits by using a database of exploit descriptions, which are writtenwith the help of previously recorded Common Vulnerabilities and Expo-suress (cves). cves for xss are widely available and are one of the mainways to tackle zero-day exploits. XSnare effectively singles out potentialinjection points for exploits in the html and sanitizes content to preventmalicious payloads from appearing in the dom.XSnare can protect application users before application developers re-lease patches and before server operators apply them.We evaluate our approach by studying 105 recent cves related to xss at-tacks, and find that our tool defends against 94.2% of these exploits. To thebest of our knowledge, XSnare is the first protection mechanism for xss thatis application-specific, and based on publicly available cve information. Weshow that XSnare’s specificity protects users against exploits which evadeother, more generic, anti-xss approaches.Our performance evaluation shows that our extension’s overhead on webpage loading time is less than 10% for 72.6% of the sites in the Moz Top500 [2] list.iiiLay SummaryToday’s websites are often the target of hackers’ exploits due to vulnera-bilities in their code bases. This work presents a client-side framework forprotecting against a specific type of exploit: cross-site scripting, by usingpre-defined descriptions of known exploits. This allows web users to defendthemselves without having to wait for application developers to fix their owncode.XSnare is implemented as a Firefox extension, which a user can installand immediately protect themselves against known vulnerabilities in web-sites. The evaluation of this work consists of showing that this tool candefend against a large number of exploits, improving a user’s security whenbrowsing the web; as well as showing that having this extension runningdoes not make web pages load much slower than they already do.ivPrefaceThis dissertation is an original intellectual product of the author, Jose CarlosPazos.The work presented here has a modified version which has been submit-ted to The Web Conference 2020, with Ivan Beschastnikh, Jean-Se´bastienLe´gare´, and William Aiello as co-authors. The implementation and eval-uation of the tool described in this dissertation was solely carried out byJose Carlos Pazos. The mentioned co-authors have served as advisors andproofreaders for the work in this document.vTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiLay Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . viList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . xi1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 XSnare Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1 An example application of XSnare . . . . . . . . . . . . . . . 72.2 XSnare Signatures . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Firewall Signature Language . . . . . . . . . . . . . . . . . . 92.4 Firefox Extension . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Handling multiple injections in one page . . . . . . . . . . . . 122.6 Dynamic injections . . . . . . . . . . . . . . . . . . . . . . . . 14vi3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1 Filtering process . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.1 Loading signatures . . . . . . . . . . . . . . . . . . . . 163.1.2 Version identification . . . . . . . . . . . . . . . . . . . 183.1.3 Injection point search and sanitization . . . . . . . . . 193.2 Sanitization methods . . . . . . . . . . . . . . . . . . . . . . . 204 Writing Signatures . . . . . . . . . . . . . . . . . . . . . . . . 214.1 Case Study: CVE-2018-10309 . . . . . . . . . . . . . . . . . . 215 Approach Viability . . . . . . . . . . . . . . . . . . . . . . . . 255.1 Test methodology . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.3 Generalizability . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . 306.1 Top websites load times . . . . . . . . . . . . . . . . . . . . . 316.2 Wordpress websites load times . . . . . . . . . . . . . . . . . 367 Limitations and Future Work . . . . . . . . . . . . . . . . . . 408 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.1 Server-side techniques . . . . . . . . . . . . . . . . . . . . . . 438.2 Client-side techniques . . . . . . . . . . . . . . . . . . . . . . 438.3 Browser built-in defences . . . . . . . . . . . . . . . . . . . . 448.4 Client and server hybrids . . . . . . . . . . . . . . . . . . . . 459 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52viiList of TablesTable 5.1 Most popular studied WordPress plugins . . . . . . . . . . 27viiiList of FiguresFigure 1.1 Different web security solutions with XSnare on the client-side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Figure 2.1 XSnare’s approach to protect against XSS. . . . . . . . . 6Figure 2.2 Example attacker injection when multiple injection pointsexist in the page. a) a basic injection pattern. b) anattempt to fool the detector. . . . . . . . . . . . . . . . . 12Figure 2.3 Example attacker injection when multiple distinct injec-tion points exist in the page. . . . . . . . . . . . . . . . . 13Figure 6.1 The Navigation Timing API’s timestamps1 . . . . . . . . 31Figure 6.2 Cumulative distribution of relative percentage slowdownwith extension installed for top sites . . . . . . . . . . . . 32Figure 6.3 Density histogram of network filter slowdown for top sites 33Figure 6.4 Scatter plot of network filter time as a function of stringlength for top sites . . . . . . . . . . . . . . . . . . . . . . 34Figure 6.5 Scatter plot of network filter time as a function of decodedbyte size for top sites . . . . . . . . . . . . . . . . . . . . 35Figure 6.6 Cumulative distribution of relative percentage slowdownwith extension installed for WordPress sites . . . . . . . . 37Figure 6.7 Density histogram of network filter slowdown for Word-Press sites . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figure 6.8 Scatter plot of network filter time as a function of stringlength for WordPress sites . . . . . . . . . . . . . . . . . . 39ixGlossaryapi Application programming interfacecms Content Management Systemcsp Content Security Policycsrf Cross-Site Request Forgerycve Common Vulnerabilities and Exposuresddos Distributed Denial of Servicedom Document Object Modelhtml Hypertext Markup Languagepoc Proof of Conceptsql Structured Query Languagewaf Web Application Firewallxhr XMLHttpRequestxss Cross-site ScriptingxAcknowledgmentsI want to thank my family for their enduring support throughout my studies.Thanks to the people of Network, Systems and Security (NSS) for makingthe lab a great place to work at. In particular, thanks to Jean-Se´bastienLe´gare´, who helped me throughout this whole project and gave me greatadvise and insight into my work and for life in general.Last, but not least, I’d like to thank the late William A. Aiello, whoalways pushed me to reach greater depths of understanding and knowledgeabout my work, and was always a very kind and understanding person.xiChapter 1IntroductionCross-site Scripting (xss) is still one of the most dominant web vulnerabili-ties. A 2017 report showed that 50% of websites contained at least one xssvulnerability [35]. Countermeasures exist, but many of them lack widespreaddeployment, and so web users are still mostly unprotected.Informally, the cause of xss is a lack of input sanitization: user-chosendata “escapes” into a page’s template and makes its way into the JavaScriptengine, or modifies the Document Object Model (dom) unintendedly. Con-sequently, many of the xss defenses published so far propose to fix theproblem at the source, by properly separating the template from the userdata on the server, or by modifying browsers [32, 36, 43, 44]. There arealso similar solutions that can be implemented in the front-end code of anapplication [31]. In all cases, these technologies must be adopted by the ap-plication software developers, otherwise users are completely unprotected.One hindrance to their adoption is that developers may not have theexpertise necessary, or sufficient resources to implement necessary precau-tions. The viability of services centered around vulnerability detection, andthe existence of a flourishing security-consulting economy is a testament tothis.Luckily, users wishing to gain reassurance over the safety of the sites theyvisit can install browser extensions to filter malicious scripts and content.Unfortunately, these extensions achieve most of their security by disabling1functionality in the applications, which can severely damage the usability ofthe sites [1, 39]. Most sites rely heavily on JavaScript1. Some sites can offeralternate versions without scripts, albeit with a level of interactivity belowwhat users have come to expect.Some software vendors respond to xss when a vulnerability is disclosed,with patches. When the software affected is released in the form of packages,frameworks, or libraries, and used by several web applications, there areextra delays before users can benefit from the patch – the updated softwarehas to first be deployed by service administrators.Unfortunately, website administrators will not, and often cannot, applysoftware updates immediately: one study found that 61% of WordPresswebsites were running a version with known security vulnerabilities [4]. Inanother report, we learn that 30.95% of Alexa’s top 1 Million sites run avulnerable version of WordPress [27].Users are in effect at the mercy of developers and administrators if theyneed to browse safe, up-to-date, applications. Our solution XSnare, helpsremedy this problem – based on information from past disclosures, it aimsto patch known page vulnerabilities received by the user’s browser.DevServer side networking-Server Firewall-Web Application          firewallClient side networking-Client firewall-Blacklisted sites-ProxiesUserBuilt-in:-XSS AuditorExtensions:-NoScript-XSnare1 2 3 4-Static analysis-Manual input                                      sanitizationBrowserFigure 1.1: Different web security solutions with XSnare on the client-side.Each layer of the web application stack (Figure 1.1) opens different de-fence options against xss:1As early as 2012, it is used by almost 100% of the Alexa top 500 sites [42]21. The application logic is the first line of defence. Code safety canbe enhanced with third-party vulnerability scanning solutions, and athorough code-review process. Taint, and static code analysis toolscan detect unsanitized inputs.2. In the hosting environment, network firewalls, specifically Web Appli-cation Firewalls (wafs) can defend against attacks such as DistributedDenial of Service (ddos), Structured Query Language (sql) injectionsand xss.3. In the client’s environment (residential or commercial), users may in-stall network firewalls, network content filters, and web proxies.4. The last line of defence is the browser. Browser have built-in de-fences, such as Chrome’s xss Auditor [28]. Users can also installthird-party extensions to block malicious requests and responses, suchas NoScript [1], and XSnare.We draw two observations from existing solutions, a) server-side solutionshave to be applied independently on each server, and b) solutions on theclient are typically written as generic filters which catch everything, andconsequently do not take full advantage of the specificity of an applicationor vulnerability.For example, a waf can effectively protect the deployment placed behindit, but users cannot realistically expect that every site they visit be protectedby one. At the opposite end, in the client’s environment, a user mightconfigure a network proxy for all website traffic, with generic rules achievingmaximum coverage, but this will often lead to an elevated rate of falsepositives (FPs).Similarly, browser built-in defences are very coarse, and will only workon a subset of exploits. Chrome’s XSS Auditor, for example, only attemptsto defend against reflected xss. Google recently announced its intentionto deprecate XSS Auditor, for reasons including “Bypasses abound”, “Itprevents some legit sites from working”, and “Once detected, there’s nothinggood to do” [13]. Stock et al. [41] propose enhancements to XSS Auditor3and cover a wider range of exploits than the auditor, but are limited todom-based xss. Our work covers all types of xss.Implementing adequate server-side protections [29, 37, 38, 45] through-out a codebase could arguably qualify as a colossal task, considering thehigh turnaround times for resolving simpler bugs. A 2018 study found thatthe average time to patch a Common Vulnerabilities and Exposures (cve),all severities combined, is 38 days, increasing to as much as 54 days for lowseverity ones, and the oldest unpatched cve was 340 days old [5].Server-side defences also do not protect against client-only forms of xss,e.g., reflected xss, or persistent client-side xss, which use a browser’s localstorage or cookies as an attack vector. Steffens et al. [40] present a study ofpersistent client-side xss across popular websites and find that as many as21% of the most frequented web sites are vulnerable to these attacks. Toprovide users with the means to protect themselves in the absenceof control over servers, we strongly believe that a novel client-sidesolution is necessary.A number of existing solutions in this area also suffer from high ratesof false-positives and false-negatives. For example, NoScript [1] works viadomain white-listing, thus by default, JavaScript scripts and other codewill not execute. However, not all scripts outside of the whitelist shouldbe assumed to be malicious. Browser-level filters like XSS Auditor workbased on general policies and can therefore incorrectly sanitize non-maliciouscontent.We posit that the dom is the right place to mitigate XSS attacksas it provides a full picture of the web application. While most ofthe functionality we provide could be done by a network filter in front of thebrowser, we take advantage of additional context provided by the browser.Particularly, when an exploit occurs as a result of user interactions, like onresponse to a click, we benefit from knowledge of the initiating tab to filterthe response. Previous client-side solutions have opted for detectors thatwere generic and site-agnostic [30, 32, 33]. Our work goes in the oppositedirection, and tries rather to prevent precisely-defined exploits in specificapplications.4If a patch for a server-side vulnerability can be “translated” into anequivalent set of operations to apply on the fully formed Hypertext MarkupLanguage (html) document in the browser, then we can seize the oppor-tunity to defend early against exploits of that vulnerability. Our extension,which has access to the user’s browsing context, can identify vulnerablepages based on a database of signatures for previous disclosures. This way,XSnare can protect users as soon as a patch is implemented and added to itsdatabase. The client-side patch will remain beneficial until all server opera-tors running that software have had a chance to upgrade their deployments.A similar philosophy is adopted by the client-side firewall-based networkproxy Noxes [33]. Unlike XSnare, however, Noxes only applies generic poli-cies based on information available at the network layer. Namely, it doesnot protect against attacks invisible to the network, e.g., deleting local files.We believe additional contextual knowledge also offers more accurate vul-nerability detection.We evaluate our system, by testing its efficacy against recent xss CVEs.CVE databases are well-maintained and widely available sources of real-world vulnerabilities. Furthermore, we measure its performance overheadon page load times, on a wide array of sites and show that it does notsignificantly affect browsing experience.Our contributions include:• XSnare: a novel client-side framework that protects users against XSSvulnerabilities with a database of signatures for these vulnerabilities,written in a declarative language.• A mechanism to correctly isolate a vulnerable injection point in a webpage and to apply the intended server-side patch on the client-side.• A collection of signatures to protect users against real XSS CVEs(Chapter 5), demonstrating the practicality of XSnare; and the evalu-ation of its impact on browsing (Chapter 6).5Chapter 2XSnare DesignHTTP request (e.g., load example.com)Security analyst uploads signature to databaseUser’s browserRequest processing DOM renderDetector loads page’s signaturesSanitizer deletes malicious injected contentBrowser displays clean documentFigure 2.1: XSnare’s approach to protect against XSS.We now present the design of XSnare and its components. We beginwith a high-level view of its operation (see Figure 2.1): A user requestsa page, example.com, on a browser with the XSnare extension installed.The response may or may not contain malicious xss payloads. Before thebrowser renders the document, XSnare analyzes the potentially maliciousdocument. The extension loads signatures from its local database into itsdetector. The detector analyzes the html string arriving from the network,and identifies the signatures which apply to the document. These signaturesspecify one or more “injection spots” in the document, which correspond,6roughly speaking, to regions of the dom where improperly sanitized con-tent could be injected. The extension’s sanitizer eliminates any maliciouscontent and outputs a clean html document to the browser for rendering(Algorithm 1).2.1 An example application of XSnareTo further explain our approach, we present a small example of how domcontext can be used to defend against xss, taken from cve 2018-10309 [6].This is reproducible in an off-the-shelf WordPress installation running theResponsive Cookie Consent plugin, v1.7. This is a stored xss vulnerability,and as such is not caught by some generic client-side xss filters, includingChrome’s XSS auditor.Consider a website running PHP on the backend which stores user inputfrom one user, and displays it later to another user, inside an input element.The PHP code defines the static html template (in black), as well asthe dynamic input (in red):< i n pu t i d = ‘ ‘ r c c s e t t i n g s [ border−s i z e ] ”name= ‘ ‘ rcc−s e t t i n g s [ border−s i z e ] ”type = ‘ ‘ t e x t ” v a l u e=“<?php rcc value(‘border-size’); ?>”/>< l a b e l c l a s s = ‘ ‘ d e s c r i p t i o n ”f o r = ‘ ‘ r c c s e t t i n g s [ border−s i z e ]”>Under normal circumstances, the input might have a value of “0”:< i n pu t i d = ‘ ‘ r c c s e t t i n g s [ border−s i z e ] ”name= ‘ ‘ rcc−s e t t i n g s [ border−s i z e ] ”type = ‘ ‘ t e x t ” v a l u e=“0”>< l a b e l c l a s s = ‘ ‘ d e s c r i p t i o n ”f o r = ‘ ‘ r c c s e t t i n g s [ border−s i z e ]”>However, the php code is vulnerable to an injection attack, e.g.:border−s i z e = ‘‘”>< s c r i p t >a l e r t ( ‘XSS’)</ s c r i p t >The browser will render this, executing the injected script:< i n pu t i d = ‘ ‘ r c c s e t t i n g s [ border−s i z e ] ”7name= ‘ ‘ rcc−s e t t i n g s [ border−s i z e ] ”type = ‘ ‘ t e x t ” v a l u e=“”><script>alert(‘XSS’)</script>< l a b e l c l a s s = ‘ ‘ d e s c r i p t i o n ”f o r = ‘ ‘ r c c s e t t i n g s [ border−s i z e ]”>Note that the resulting html is well-formed, so a mere syntactic checkwill not detect the malicious injection. Let us assume a security analystknows the original template, i.e., without injected content. If the analystwere given a filled-in document, they could (in most cases) separate theinjected content from the server-side template, and get rid of the maliciousscript entirely, using proper sanitization.The injected script is bounded by template elements with identifiable at-tributes. Assuming (for now) that there is only one such vulnerable injectionpoint, we can search for the input element from the top of the document,and the label from the bottom to ensnare the injection points in the html.This shares goals with the client/server hybrid approach of Nadji etal. [36]. They automatically tag injected dom elements on the server-sideusing a taint-tracking, so that the client (a modified browser) can reliablyseparate template vs injected content. We do not require any server-sidemodifications, but rather opt for a client-side tagging solution based onexploit definitions.The injected content, once identified, must be sanitized appropriately.The appropriate action will depend on the application setting, but assuminga patch has been written, it suffices to translate the intention in the servercode’s path to the client-side. This can be straightforward, once the fix isunderstood.The developer incorrectly claimed the bug had been fixed in version 1.8of the plugin. Other similar vulnerabilities had indeed been fixed, but notthis one [19]. The built-in WordPress function ‘sanitize text field’ neededto be applied.XSnare does not automatically determine the relevant actions to imple-ment from a patch. We assign this task to a security analyst, who will actas the signature developer for a given exploit. The system will howeverautomate the signature matching and sanitization.82.2 XSnare SignaturesOur signature definitions make two assumptions: first, an injection musthave a start point and end point, that is, an element can only beinjected between a specific html node and its immediate sibling in the domtree; second, in a well-formed dom, the dynamic content will not beable to rearrange its location in the document without JavaScriptexecution (e.g., removing and adding elements), allowing us to isolate itfrom the template.Pages commonly contain more than one vulnerable injection point. Wediscuss the difficulty of supporting these pages in Section 2.5.We believe cves are an ideal growing source of signature definitions.Since previous client-side work does not focus on application-specific pro-tection, these tools often use less accurate heuristics to detecting exploits.Furthermore, once new vulnerabilities are found, these systems often lackthe maintainability obtained by leveraging active cve development.We are conscious that XSnare signatures will not write themselves, andthat this task represents a new step in the workflow. Luckily, converting thecve information into a signature does not require active participation fromthe application developers – Security enthusiasts and web developers havethe skills to fulfill this role satisfactorily.Long term, we imagine that volunteers (or entrepreneurs) would cultivateand maintain the signature database. New signatures could be contributedby a community of amateur or professional security analysts, in a mannernot so different from how antispam or antivirus software is managed.The challenge of automatically deriving signatures from detailed cvesis an interesting one, albeit outside the scope of this paper.2.3 Firewall Signature LanguageOur signature language needs to be such that it has enough power of expres-sion for the signature writer to be precise, both for determining the correctweb application and to identify the affected areas in the html. For injectionpoint isolation, a language based on regular expressions suffices to express9precise sections of the html. The following is the signature that defendsagainst the motivating example of Section 2.1:Listing 2.1: An XSnare signatureu r l : ‘wp−admin/ op t i on s−g e n e r a l . php? page=rcc−s e t t i n g s ’ ,s o f twa r e : ‘WordPress ’ ,s o f t w a r eD e t a i l s : ‘ r e s p on s i v e−cook i e−consent ’ ,v e r s i o n : ‘ 1 . 5 ’ ,t ype : ‘ s t r i n g ’ ,typeDet : ‘ s i n g l e ’ ,s a n i t i z e r : ‘ r egex ’ ,c o n f i g : ‘/ˆ [0−9](\ . [0−9]+) ?$ / ’ ,endPo in t s :[ ‘< i n pu t i d = ‘ ‘ r c c s e t t i n g s [ border−s i z e ] ” name= ‘ ‘r c c s e t t i n g s [ border−s i z e ] ” type = ‘ ‘ t e x t ” v a l u e =” ’ ,‘< l a b e l c l a s s = ‘ ‘ d e s c r i p t i o n ”f o r = ‘ ‘ r c c s e t t i n g s [ border−s i z e ]”> ’ ]A description of the development process for this signature is given inSection 4.1. In summary, a signature will have the necessary information todetermine whether a loaded page has a vulnerability, and specify appropriateactions for eliminating any malicious payloads.Analysts configure their signatures with one function chosen from thestatic set of sanitization functions offered by XSnare. These functions inoc-ulate potentially malicious injections based on the dom context surroundingthe injection. The goal of signatures is to provide such sanitization, ideallywithout “breaking” the user experience of the page. The default functionpreset is DOMPurify’s [31] default configuration, which takes care of com-mon sanitization needs [21]. However, DOMPurify’s defaults can be unnec-essarily restrictive, in which cases the other sanitization methods are moredesirable.We considered allowing arbitrary sanitization code in signatures. Whileit would open complex sanitization possibilities, we have decided against it,principally for security reasons. The minimal set of functions we settled onalso sufficed to express all of the signatures defined for this paper.102.4 Firefox ExtensionOur system’s main component is a browser extension which rewrites poten-tially infected html into a clean document. detects exploits in the html byusing signature definitions and maintains a local database of signatures. Weleave the design of an update mechanism to future work, but in its currentform, the database is bundled with each new installation of the extension.The extension translates signature definitions into patches that rewriteincoming html on a per-URL basis, according to the top-down, bottom-upscan described in Section 2.1.The extension’s detector acts as an in-network filter. We initially con-sidered other designs but quickly found out that applying the patch at thenetwork level was necessary for sanitization correctness: even before anycode runs, parsing the html into a dom tree might cause elements to be re-arranged into an unexpected order, making our extension sanitize the wrongspot. Consider the following example, where an element inside a <tr> tagis rearranged after parsing the string:<t a b l e c l a s s = ‘ ‘wp− l i s t −t a b l e ”><thead><t r><th></th><img src=“1” onerror=“alert(1)”><th><form method= ‘ ‘GET” a c t i o n =‘‘”>. . .In this html, the signature developer might identify the exploit as oc-curring inside the given table. However, if we wait until the string has beenparsed into a dom tree to sanitize, the elements are rearranged due to <tr>not allowing an <img> as its child:<img src=“1” onerror=“alert(1)”><t a b l e c l a s s = ‘ ‘wp− l i s t −t a b l e ”><thead><t r><th></th>11<th><form method= ‘ ‘GET” a c t i o n =‘‘”>. . .Note that the injected <img> tag is now outside of the table, simplyby virtue of the dom parsing. Now, the extension will search past theinjection, as it occurs before the table element, creating a false negative(FN). Similarly, elements rearranged inside an injection point can create falsepositives. This example would generate a class of circumvention techniquesfor our detector, so we can’t wait until the website has been rendered toanalyze the response. This guarantees that a knowledgeable attacker cannot take advantage of this behavior.2.5 Handling multiple injections in one pageIn Listing 2.1, the endPoints were listed as two strings in the incomingnetwork response. However, there are cases where arbitrarily many injectionpoints can be generated by the application code, such as a for loop generatingtable rows. For these, it is hard to correctly isolate each endPoint pair, asan attacker could easily inject fake endPoints in between the original ones.**b)a)Figure 2.2: Example attacker injection when multiple injection pointsexist in the page. a) a basic injection pattern. b) an attemptto fool the detector.In Figure 2.2a, the brackets indicate a template. The content in betweenis an injection point (the star), where dynamic content is injected into thetemplate. In the case of a vulnerability, the injected content can expand to12any arbitrary string. The signature separates the injection from the rest bymatching for the start and end points (the endPoints), represented by thebrackets. This html originally has two pairs of endPoint patterns.In Figure 2.2b, the attacker knows these are being used as injection endpoints and decides to inject a fake ending point and a fake starting point(the dotted brackets), with some additional malicious content in between.If just looking for multiple pairs of end points, the detector cannot tell thedifference between the solid and dotted patterns, and will not get rid of thecontent injected in the star. Therefore, we have to use the first startingpoint and the last ending point before a starting one (when searching fromthe bottom-up) and sanitize everything in between. This might get rid of asubstantial amount of valid html, so we defer to the signature developer’sjudgment of what behavior the detector should follow. We expand upon thisfurther in Section 4.1.* + +Figure 2.3: Example attacker injection when multiple distinct injec-tion points exist in the page.Figure 2.3 illustrates a case when there are several injection points inone page, but each of them is distinct. Now, the filter is only looking forone pair of brackets, so the attacker can’t fool the extension into leavingpart of the injection unsanitized. However, they could, for example, injectan extra ending bracket after the opening parenthesis (or an extra startingbrace). The extension will be tricked into sanitizing non-malicious content,the black pluses (+). This behavior can be detected by noting that we knowthe order in which the endPoints should appear, and so if the filter sees aclosing endPoint before the next expected starting endPoint, or similarly,a starting endPoint before the next expected closing endPoint, this attackcan be identified. In the diagram, the order of the solid elements charac-13terizes the possible malformations in the end points. As with the previousscenario, we have to sanitize the outermost end points, potentially deletingnon-malicious content. The signature developer specifies the behavior.2.6 Dynamic injectionsThe top-level documents of web pages fetch additional dynamic contentvia fetch or AJAX Application programming interfaces (apis). Contentfetched in this way is also vulnerable to xss, and must be filtered. Anexample vulnerability is cve-2018-7747 (WordPress Caldera Forms, whichallows malicious content retrieved from the plugin’s database to be injectedin response to a click.XSnare allows XMLHttpRequest (xhr) requests to be filtered with xhr-type signatures. To reduce the number of signatures that need to be consid-ered when a browser issues a request, we require that signatures for xhr benested inside a signature for a top-level document. If a page’s main contentmatches an existing top-level signature description, XSnare will then enableall nested xhr listeners.Signatures for dynamic requests are specified in the listenerData key,which includes a listener type and method. The idea is extensible to scriptsand other objects loaded separately from the main document (e.g., images,stylesheets, etc.).Listing 2.2: An example dynamic request signature. This patchesCVE-2018-7747.. . .l i s t e n e r D a t a : [{l i s t e n e r T y p e : ‘ xhr ’ , l i s t e n e rMe t hod : ‘POST’ ,s a n i t i z e r : ‘ escape ’ , t ype : ‘ s t r i n g ’ ,l i s t e n e r U r l : ‘wp−admin/admin−a j a x . php ’ ,typeDet : ‘ s i n g l e−unique ’ ,endPo in t s : [ ‘<p><s t rong > ’ , ‘ [ AltBody ] ’ ]} ]14Chapter 3ImplementationWe have implemented our browser extension in Firefox 69.0. Our signaturesare currently stored in a local JavaScript file in the extension package. Wehave decided to implement this tool as an extension due to the followingmain benefits:• Ease of deployment and adoption. Most modern browsers providea convenient way to upload extensions to their respective official sites(Firefox Add-Ons in the case of Firefox). This eases deployment forthe extension developer, and also eases installation for an user, as theycan install the tool within the browser in one click, without having toinstall additional third-party software. Previous client-side work oftenapplies browser modifications. Most users might not be willing toadopt new browsers, since it might affect usability for them.• Privileged execution environment. The extension’s logic can liein a separate environment from the web application code. This is im-portant for security, as it guarantees that any malicious code in theapplication can not affect the extension’s behaviour. If the extensionneeds to run code within the application, it can maintain security byinstalling the code before the application’s code runs. A web appli-cation, on the other hand, can not achieve this level of security ingeneral, as it can not guarantee that its own code will run before any15malicious code.• Web application context. Our solution requires knowledge of theapplication’s context to perform several of its tasks. For example, it’suseful to know which tab generated a network request to determinewhether the response content is safe or not. The extension naturallyretains this context.• Ability to interpose at the network level and the web applica-tion level. As it lies within the browser, the extension can run bothat the network level, e.g., rewrite an incoming response or outgoingrequest; and at the web application level, e.g., keeping track of clickevents, or interpose on the application’s JavaScript execution. Othertypes of solutions often have to choose between one or the other. Inparticular, Firefox provides the filterResponseData method throughthe webRequest. This allows the extension’s background page to anal-yse and modify incoming network traffic.3.1 Filtering processAlgorithm 1 describes our network filtering process. In particular, once arequest’s response comes in through the network, we process it and sanitizeit if necessary. Throughout this section, line numbers refer to this algorithm.3.1.1 Loading signaturesOur detector loads signatures and finds injection points in the document.However, there might be a large number of signatures which don’t needto be loaded for a specific website. For example, if several signatures aredesigned for pages running a WordPress plugin, then the extension need notcheck any of these for a site which is not running WordPress at all. Onthe other hand, if a site is running WordPress, we might have to check allsignatures meant for WordPress, but not others. Therefore, when loadingsignatures, we proceed in a manner similar to a decision tree. In line 3,the detector first probes the page to identify the underlying framework (we16Algorithm 1: Network filter algorithm1 //global DBSignatures2 procedure verifyResponse (responseString, url)3 loadedProbes = runProbes(responseString, url)4 signaturesToCheck ← []5 for probe in loadedProbes do6 signaturesToCheck.append(DBSignatures[probe])7 end8 loadedSignatures ← []9 for signature in signaturesToCheck do10 if responseString and url match signature then11 loadedSignatures.push(signature)12 end13 versionInfo = loadVersions(url, loadedProbes)14 endPoints ← []15 for signature in loadedSignatures do16 if (signature,signature.version) ∈ versionInfo then17 endPoints.push(signature.endPointPairs)18 end19 indices ← []20 for endPointPair in endPoints do21 indices.push(findIndices(responseString, endPointPair))22 end23 if discrepancies exist in indices then24 Block page load and return25 for endPointPair in endPoints do26 sanitize(responseString,indices)27 end28 end17call this the software in our signature language), which is usually foundby hints in the document html). These probes are framework-specific, andas such, need to be encoded in some way so that the detector can runthem. There are two approaches for this: the detector completely takescare of this, and needs to be maintained for changes in frameworks andfuture technologies, or, the signature developer additionally specifies a morespecialized version detector as part of a probe file. We chose to go with thefirst option, as this provides a greater ease of use for signature developers.In our prototype implementation, hard-coding probes into the detector didnot imply a substantial amount of work.As more signatures are written and more applications are required to beincluded, this can become an arduous task. We believe the second option canbe desirable and would not be a terrible burden for signature developers: forexample, the widely popular network mapping tool Nmap [17] uses probesin a similar manner, and these are kept in a modifiable file so that advancedusers can have more expressibility. After running these probes, the detectorloads signatures for the specific software (e.g., all signatures for WordPressweb sites). In line 4-7, the signatures for the given framework are added forfurther processing.In lines 8-12, we filter out the ones that do not apply to the current pageby iterating through the list of signatures sequentially. The detector checkswhether the identifying information of the signature matches the given htmlstring and/or URL.3.1.2 Version identificationWe then apply version identification (lines 13-16). Our objective for ver-sioning is that our signatures don’t trigger any false positives on websitesrunning patched software. We found this to be one of the harder aspects ofsignature loading. In WordPress, for example, many of the plugins do notupdate their file names with the latest versions, or do not include them atall, and thus, this information is often hard to come by from the client-sideperspective. In the case of WordPress, the wp-admin/plugins.php subpath18contains information about all currently active plugins on the site. Unfor-tunately, this information is only available to admins of the site. While thismight not be the bulk of users, it is, on the other hand, the bulk of disclosedcves, as described in Chapter 4.Furthermore, we believe that even if we load a signature when the ap-plication has already been fixed at the server-side, it will often preserve thepage’s functionality, as many of the cves describe xss which happens asa result of unsanitized input that was not meant to be JavaScript code re-gardless. Motivated by this observed behaviour, our mechanism follows aseries of increasingly accurate but less applicable version identifiers: first, weapply general-purpose version probes, like the one described for WordPress(these are maintained in a similar way to software probes, hard-coded in thedetector logic). If these are not successful, the signature language providesfunctionality for version identification in the html through regex. If thesignature developer considers version information to be unavailable throughthe html, the version in the signature is left blank and the detector appliesthe signature patch regardless of version, as we can not be sure the pageis running patched software. As long as the database is maintained, sig-natures will evolve in parallel with the software, and can retain backwardscompatibility with past versions. Our tool takes advantage of having perfectknowledge of an exploit’s conditions, which reduces the rate of false positivescompared to a software-agnostic approach.3.1.3 Injection point search and sanitizationOnce we have the correct signatures, we find the indices for the endpointsusing our top-down, bottom-up scan, and need to check for potential mal-formations in the injection points, as described in Section 2.5 (lines 19-24).The page load is blocked and a message is returned to the user, or if thesignature developer specifies so, sanitization proceeds on the new endpoints.Finally, if all endPoint pairs are in the expected order, we sanitize eachinjection point (lines 25-27).While our prototype’s signature database is currently encoded entirely19in the extension software, we envision that a trusted entity can maintain thisdatabase, such as those that currently maintain cves databases, and willhave to be audited so that it is not filled with false signatures and existingones are not compromised.3.2 Sanitization methodsWe provide different types of sanitization: “DOMPurify”, “escape”, and“regex”. Regex Pattern matching can be particularly effective when theexpected value has a simple representation (e.g., a field for only numbers).For each of these approaches, the signature can specify a correspondingconfig value. DOMPurify provides a rich API for additional configuration.When escaping, defining specific characters to escape via regex can be useful.For pattern matching via regex, config specifies the value the injected shouldmatch.20Chapter 4Writing SignaturesWe envision the process of signature development to be part of the vulnera-bility discovery work flow and cve creation. As such, we expect a signaturedeveloper to have a solid understanding of the principles behind xss so thatthey can properly identify the minimal section of the dom which acts asan injection point. Similarly, it is important that they can identify uniquetraits of elements (e.g., html id’s, classes, etc.) and the page overall in orderto reduce the rate of false positives. In this section, we aim to show thatminor effort is required from a knowledgeable security analyst when writinga signature for our extension.4.1 Case Study: CVE-2018-10309Going back to our example in Section 2.1, we describe the process by whicha signature is written after a vulnerability has been discovered by using oneof our studied cves as an example. A full specification of our signaturelanguage is explained in the Appendix.Identifying the exploit. An entry in Exploit Database [22] describesa persistent xss vulnerability in the WordPress plugin Responsive CookieConsent for versions 1.7/1.6/1.5. This particular entry (as most do) comeswith a proof of concept (PoC) for the exploit:1. Access WordPress control panel.212. Navigate to the Responsive Cookie Consent plugin page.3. Select one of the input fields. For example, ”Cookie Bar Border Bot-tom Size”.4. Insert the script you wish to inject.5. Save the plugin settings.6. Injected script will run in the victim’s browser. Depending on whichinput field you inserted the script, the script may also run everytimeyou load the Responsive Cookie Consent plugin page.Establishing the separation between dynamic and static con-tent. As further described in Section 5.1, in order to test this vulnera-bility, we find a link to the affected plugin code, and launch a local in-stallation of WordPress 5.2 with the plugin downloaded. After this, weactivate the plugin and proceed to reproduce the given PoC, inserting thestring ‘”><script>alert(‘XSS’)</script>’ in the rcc settings[border-size] in-put field, resulting in the following html displayed on the page, as well asan alert box popping up in the page:< i n pu t i d = ‘ ‘ r c c s e t t i n g s [ border−s i z e ] ”name= ‘ ‘ rcc−s e t t i n g s [ border−s i z e ] ”type = ‘ ‘ t e x t ” v a l u e=“”><script>alert(‘XSS’)</script>< l a b e l c l a s s = ‘ ‘ d e s c r i p t i o n ”f o r = ‘ ‘ r c c s e t t i n g s [ border−s i z e ]”>In general, the cve writer is able to find the vulnerable html from theserver-side code without having to reproduce the exploit and see its client-side rendering. Since we did not write the cve, we had to do this extrastep.In this case, it is clear that the input element is the injection startingpoint, and we use the label element as the end point, since it is the imme-diate element after the input. We must emphasize that the identificationof correct endpoints is extremely important. In particular, when multipleinjection points exist in the same page, the signature developer must be cau-tious with the chosen elements, and ensure that these do not overlap with22other innocuous ones. In some cases, the developer might find it best tocompletely stop the page from loading if they think the sanitization wouldaffect the user experience too greatly. While one of our main goals is tomaintain the page’s usability, there are cases where a large portion of thedocument would be affected by the sanitization, and we believe compromis-ing usability for security is preferable in this case. Furthermore, developerhas to identify whether the exploit comes in from an external source (suchas a response to an Ajax request or an external script) or is embedded inthe document’s mainframe html. This will result in a different signaturelayout.Collecting other required page information and writing the sig-nature. Once we have the proper end points for the injections, we cangather the remaining information to determine whether the loaded page isthe correct one to apply the signature to. The full signature for this exam-ple was previously shown in Listing 2.1. The URL is acquired by notingthat this exploit occurs on the plugin’s settings page, which is in a spe-cific subdomain of the web site. The software running is WordPress in thiscase. The settings page’s html includes a link to a stylesheet with href http://localhost:8080/wp-content/plugins/responsive-cookie-consent/..., in partic-ular, for a WordPress page, “wp-content/p-lugins/plugin-name” is the stan-dard way of identifying that it is running a certain plugin. In this case,“responsive-cookie-consent”, set as softwareDetails. While the entry onlylists versions 1.7, 1.6, and 1.5 as vulnerable, we apply the signature for allversions less than or equal to 1.7. Since, the exploit only occurs in thisspecific spot in the html, the typeDet is listed as ‘single’. We list theendPoints as taken from the html.Testing the signature Finally, we load up our extension and reloadthe web page. In this example, we expect to not have an alert box pop up,and we manually look at the html to verify correct sanitization. Note thatthere’s nothing else in between the input and label elements now:< i n pu t v a l u e = ‘ ‘” type = ‘ ‘ t e x t ”name= ‘ ‘ r c c s e t t i n g s [ border−s i z e ] ”i d = ‘ ‘ r c c s e t t i n g s [ border−s i z e ]”>23< l a b e l c l a s s = ‘ ‘ d e s c r i p t i o n ”f o r = ‘ ‘ r c c s e t t i n g s [ border−s i z e ]”>In practice, it might be the case that the endPoints (or other parts ofa signature) are incorrectly written, for example, due to small discrepanciesbetween server-side and client-side representations of the html string. Theordering of an element’s attributes might switch around after the stringhas been parsed and displayed on the client, leading to bugs if the signaturedeveloper used the parsed html as a reference. If the exploit is not properlysanitized, the developer is able to use the debugging tools provided by thebrowser to check the incoming network response information seen by theextension’s background page and make sure it matches the signature values.24Chapter 5Approach ViabilityIn order to verify the applicability of our detector and signature language,we tested the system by looking at several recent cves related to xss. Ourobjective is two-fold: to verify that our signature language provides thenecessary functionality to express an exploit and its patch, and to test ourdetector against existing exploits.5.1 Test methodologyOur work focuses on WordPress as a study platform: we look at recentcves related to WordPress plugins. While this may seem restrictive, thereare several reasons why this is a worthwhile endeavour:• WordPress powers 25% of all websites according to a recent survey[24]. The same study states that 30.3% of the Alexa top 1000 sitesuse WordPress. Thus, we can be confident that our study results willhold true for the average user.• WordPress plugins are very popular among developers (there are cur-rently more than 55,000 plugins [25]). Due to its user popularity,WordPress is also heavily analysed by security experts. A search forWordPress cves on the Mitre cve database [12] gives 2310 results.Plugins, specifically, are an important part of this issue, 52% of the25vulnerabilities reported by WPScan are caused by WordPress plugins[26].• Due to the open source nature of WordPress plugins, we can easilyanalyze both the client-side html, as well as the server-side code thatgenerated it, and use this to reach conclusions about the design of oursolution.• Using one framework, we can install many different plugins for the ver-sion we want, reproduce attacks, and investigate the conditions underwhich they happen, without having to install additional software.In order to achieve a comprehensive test suite, we looked at the 100 mostrecent WordPress xss cves, as of October 2018. We have chosen to use acve database, cve Details [11], as opposed to other databases that includevulnerabilities or exploits, mainly because of reliability. We have been ableto find hundreds of verified attacks on WordPress and its plugins using acve database, which also usually contain information on how to reproducethem. This provides the perfect platform to analyze xss attacks and decidewhether they can be countered by our approach.For each cve, we set up a Docker container with a clean installationof WordPress 5.2 and installed the vulnerable plugin’s version. A few ofthe cves depended on the WordPress version as well, and so we used therequired WordPress version for those. We then tried to reproduce the exploitas described by the cve author. Finally, we analyzed the vulnerable pageand wrote a signature to patch the exploit.5.2 ResultsOf the initial 100 cves, we were able to analyze 76 across 40 affected pages.We dropped 24 cves due to reproducibility issues: some of the descriptionsdid not include a PoC of the exploit, and as such, was difficult for us to repro-duce; or, the plugin code was no longer available. In some cases, it had beenremoved from the WordPress repository due to “security issues”, which em-phasizes the importance of being able to defend against these attacks. This26Plugin InstallationsWooCommerce 5+ millionDuplicator 1+ millionLoginizer 900,000+WP Statistics 500,000+Caldera Forms 200,000+Table 5.1: Most popular studied WordPress pluginsis not to say, however, that our detector would not work for such a cve, asthe author would have a better idea of how the exploit manifests itself, andwould therefore be in a better position to write a signature. The pluginswe studied averaged 489,927 installations; Table 5.1 shows the number ofinstallations for the 5 most popular studied plugins. For the vulnerabilities,27 (35.5%) could be exploited by an unauthenticated user; 56 (73.7%) tar-geted a high-privilege user as the victim, 7 (9.2%) had a low-privilege useras the victim, the rest affected users of all types.Many of the studied cves included attacks for which there are knownand widely deployed defenses. For example, many were cases of Reflectedxss, where the URL reveals the existence of an attack e.g:http://[pathtoWordPress]/wp-admin/admin.php?page=wps pages page&p-age-uri=〈script〉alert(”XSS”)〈/script〉While Chrome’s built-in xss auditor blocked this request, Firefox didnot, and so we still wrote signatures for such attacks. We wrote 59 Word-Press signatures in total, which got rid of the PoC exploit when sanitizedwith one of our three methods. We were able to include several cves insome of them because they occurred in the same page and affected the sameplugin. Overall, these signatures represent 71 (93.4%) signed cves. The 5we were not able to sign were due to lack of identifiers in the html, whichwould result in potentially large chunks of the document being replaced. Forcases like these, the signature developer can weigh the trade-offs and decidewhether the added cost is worth it.The majority of the 71 signatures maintained the same layout and core27functionality of the webpage. However, 12 signatures caused some elementsto be rearranged, modifying the page’s visual aspect. One caused a smallpart of the page to become unusable, due to the sanitization method used(e.g. a table showing user information is now rendered as blank). As with thecase of unsigned cves, most of the responsibility of maintaining functionalityis left to the signature developer, being as precise as possible is key: A fullsanitization of the whole html string will most likely get rid of any exploits,but will also make the page completely unusable in most scenarios.While our goal with the signature language is to retain as much infor-mation of the webpage as possible after sanitization, we believe that even ifa part of the page is now useless, this does not impact the user’s experienceas much, since most of these exploits manifest themselves in small sectionsof the html. A thorough study with regards to usability is out of scope forthis work, but we provide a study on false positives and false negatives inlater sections, which is related to this issue.5.3 GeneralizabilityTo test the generalizability of our approach to other frameworks, we analysed5 additional cves, 2 related to Joomla!, 2 for LimeSurvey, and 1 for BoltCMS. We chose Joomla! because it is another popular Content ManagementSystem (cms), more than 2.5 million sites use it [15]. Unfortunately, we onlyfound 2 cves for it that we were able to reproduce, as the software for itsextensions is often not available. The first affects base Joomla!, so all sitesrunning it were vulnerable to the exploit. The attacker requires access to theadmin panel, and targets high-privileged users. The second affects a Joomla!extension, for which usage information is not available. This exploit doesnot require authentication to be carried out, and targets all types of users.For fairness, we looked for the most recent cves we could reproduce listedin the Exploit Database [14], since these have recorded Proof of Concepts(pocs). According to the their webpage, LimeSurvey is downloaded 10,000times every month [16]. One of its cves required an authenticated user tobe exploited, while the other one did not. One of the exploits targets high-28privilege users, while the other one targets all users. There are currently6,125 sites running Bolt CMS [10]. For its cve, the exploits requires anauthenticated user to be carried out, and targets high-privilege users.We carried out the same procedure as with the WordPress cves, andwere able to patch all of the 5 exploits. This brought our cve coverage rateup to 94.2%.29Chapter 6Performance EvaluationThe extension’s performance goals are to provide our security guaranteeswithout being a detriment to the end user’s browsing experience. To thisend, we take several timestamps throughout our code’s execution. Thesewere recorded using the Performance Web api. Note that while this apinormally reports values as doubles, due to recent security threats, such asSpectre [34], several browser developers have implemented countermeasuresby reducing the precision of the DOMHighResTimeStamp resolution [7, 20].In particular, Firefox reports these values as integer milliseconds. For ourtests, we re-enabled higher precision values.While our extension’s functionality only applies at the network level,there is potential slowdown at the dom processing level due to the opti-mization techniques the browser applies throughout several levels of theweb page load pipeline. Figure 6.1 shows the different timestamps providedby the Navigation Timing api [18], as well as a high-level description of thebrowser processing model. Since our filter listens on the onBeforeRequestevent, none of the previous steps before Request are affected. In this section,we refer to the difference in time between responseEnd and requestStart asthe “network filter time”.30Figure 6.1: The Navigation Timing API’s timestamps16.1 Top websites load timesWe first report our extension’s impact on top website load times, represent-ing the expected behaviour of an user’s average web browsing experience.For these tests, we first took the top 500 websites as reported by Moz.com[2]. For each website, we loaded it 25 times (with a 25 second timeout) andrecorded the following values: requestStart, responseStart, responseEnd,domContentLoadedEventEnd, domComplete, duration, and decodedBody-Size. From the initial 500, we only report values for 441 of them. The other59 had consistent issues with timeouts, insecure certificates, and networkerrors. For our setup, we used a headless version of Firefox 6.90, and Sele-nium WebDriver for NodeJS, with GeckoDriver. All experiments were runon one machine with an Intel Xeon CPU E5-2407 2.40GHz processor, 32 GBDRAM, and our university’s 1GiB connection. We ran four test suites:• No extension cold cache: Firefox is loaded without the extension in-stalled and the web driver is re-instantiated for every page load.• Extension cold cache: Firefox is loaded with the extension installedand the web driver is re-instantiated for every page load.• No extension warm cache: Firefox is loaded without the extensioninstalled and the same web driver is used for the page’s 25 loads.1This image was taken from the w3 spec: https://www.w3.org/TR/navigation-timing-2/31• Extension warm cache: Firefox is loaded with the extension installedand the same web driver is used for the page’s 25 loads.For each set of tests, we reduced the recorded values to two comparisons:network filter (responseEnd - requestStart), and page ready (domComplete- responseStart). The first analyzes the time spent by the network filter,while the second determines the time spent until the whole document hasloaded. We calculate the medians for each website for each of these measuresas well as the decodedByteSize.40 20 0 20 40Percentage slowdown0.00.20.40.60.81.0Percentage of sitescold network filtercold page readywarm network filterwarm page readyx=[-10,10]Figure 6.2: Cumulative distribution of relative percentage slowdownwith extension installed for top sitesWe compare the load times with and without the extension running bycalculating the relative slowdown with the extension installed according tothe following formula:100∗ x˜with− x˜withoutx˜without32where x˜ is the median with/without the extension running.Figure 6.2 shows the computed results. We have zoomed in on the[−50%,50%] range, as this is where the grand majority of values lie. Thegraph shows a slowdown of less than 10% for 72.6% of sites, and less than50% for 82% of sites when the extension is running. Note that these valuesare recorded as percentages, and while some are as high as 50%, the absolutevalues are in the order of seconds, and in many cases tens or hundreds ofmilliseconds, especially for the network component. Such values should notalter the user’s experience significantly. The slowdown increases by at most5% when we take caching into account. We expect this to be the case becausethe network filter probably causes the browser to use less caching, especiallyfor the dom component, as it might have to process it from scratch everytime.20 15 10 5 0 5 10 15 20Slowdown percentage0.0000.0250.0500.0750.1000.1250.1500.1750.200ProbabilityFigure 6.3: Density histogram of network filter slowdown for top sites33Figure 6.3 shows a closer look at the distribution for the cold networkfilter slowdown on the top sites (same values as in Figure 6.2). We filteredout any values above —100—%, as these were mostly due to timeouts andother network delays or errors. For this component, 87.6% of the slowdownvalues are less than 10%.0 40 80 120 160Length (thousands of characters)0510152025303540Verification time (ms)trend line (no probes)trend line (probes)trend line (overall)verification time (no probes)verification time (probes)Figure 6.4: Scatter plot of network filter time as a function of stringlength for top sitesFigure 6.4 shows the time spent by the call to our string verificationfunction in the network filter as a function of the length of the string tobe verified. We loaded the same websites 25 times each and calculated themedian times and lengths. The blue dots are the pages for which the frame-work probes tested negative, and the green dots are the pages for which theprobes tested positive: 55 in total. We applied least squares regression tocalculate the shown trend lines. The Spearman’s rank correlation values forno probes, probes, and overall are 0.91, 0.91, and 0.72 respectively, demon-strating positive correlation. Since both our probes and signatures use regex34matching, we expect both trend lines to be linear, as seen in the graph. Re-call that once a probe for a certain software passes, we perform a linear scanover the signatures for that specific software and check whether it appliesto the given html string or not. Thus, we expect the slope of the line tobe higher when the WordPress probe passes. Around 37.4% of all web sitesuse frameworks covered by our probes [23], thus, we expect the impact ofour network filter to be closer to the non-probe values, as corroborated byour overall trend line.0 200000 400000 600000 800000 1000000 1200000Size (bytes)05001000150020002500Network time (ms)trend linenetwork timeFigure 6.5: Scatter plot of network filter time as a function of decodedbyte size for top sitesWhen factoring in the rest of the network component, additional noise isintroduced in the measurements. Figure 6.5 shows the network filter time asa function of the page’s decoded byte size. Applying least squares regressionshows an upwards trend. However, the Spearman’s rank correlation for thisset of data is −0.054; we believe this to be due to the number of factorsaffecting this measurement. The data demonstrates that the size of the35page being processed has a smaller impact than expected (see Figure 6.4)on the network filter time when the whole page load process is accountedfor.Additionally, for each website we recorded the number of loaded signa-tures (i.e., signatures whose endpoints were found in the html). We reporta 0% false positive rate for loaded signatures. Thus, we can infer with confi-dence that the rate of false positives for loaded signatures during an averageuser’s web browsing is similarly low. This rate could possibly go up as thenumber of signatures and covered frameworks increases. While we can notbe sure that any of the sites is free of vulnerabilities described in our currentsignatures, this is very unlikely, as many of these websites are not runningWordPress to begin with, and being some of the most popular, they wouldlikely be updated relatively quickly if any vulnerability is found; thus, therate of false negatives is likely extremely low as well.6.2 Wordpress websites load timesWe ran similar experiments as in Section 6.1, but with the WordPress sitesdescribed in Section 5.1. Thus, all of these have either one or multipleinjection points in their html, and the network filter will spend an additionalamount of time sanitizing these as defined by the signatures. Note that thedata set is smaller here, and some of the trends might be harder to infer.As before, Figure 6.6 shows the results for slowdown with the extensionrunning. Recall that the only difference between a page which passes theWordPress probe and one that matches a signature is that the latter has toreplace a portion of the original string by its sanitized version. In this casewe see a slowdown of less than 10% for 60% of sites, and less than 40% for96.25% of them. The warm network filter curve suffers from a particularlyhigh slowdown. We believe this to be the case because the locally hostedpages decrease the network component time, causing any overhead to beseen as relatively high. However, as 48% of the original values were below60ms, conclude a small impact on user experience as well.Figure 6.7 shows the probability density of the cold network filter slow-3660 40 20 0 20 40 60Percentage slowdown0.00.20.40.60.81.0Percentage of sitesx=[-10,10]cold network filtercold page readywarm network filterwarm page readyFigure 6.6: Cumulative distribution of relative percentage slowdownwith extension installed for WordPress sitesdown. In this case, we see that the distribution is skewed more towards ahigher slowdown. As it is harder to discern the trend for this data set thanits top site counterpart, we have also plotted the normal distribution of thedata between 3 standard deviations. 65% of values are less than 10%.Finally, as in Figure 6.4, we report the string verification time as afunction of its length, for the WordPress sites, shown in Figure 6.8. TheSpearman’s rank correlation for this set of data is 0.630.3710 5 0 5 10 15 20 25 30Slowdown percentage0.000.020.040.060.080.100.120.140.16ProbabilityNormal distributionFigure 6.7: Density histogram of network filter slowdown for Word-Press sites380 40 80 120 160Length (thousands of characters)0.02.55.07.510.012.515.017.520.0Verification time (ms)Trend LineFigure 6.8: Scatter plot of network filter time as a function of stringlength for WordPress sites39Chapter 7Limitations and Future WorkGeneralizability. Our study has mostly covered WordPress websites andonly 5 other sites. While many websites, in particular ones that use any kindof cms might share similar structures to the ones we studied, it is clear thatthe open source nature and availability of WordPress code and its pluginsmight have made our assumption of full knowledge of the html too strong.We acknowledge that this assumption will not always hold true, however, asshown by our other cves, our tool is not limited to WordPress sites.Scope of study. Our current cve study has only covered 100 cves,23 of which had to be discarded in our result analysis. We intend to covermore in the future to have a better representation of WordPress websitesand plugins and the web as a whole.Current implementation. There are several aspects of injections thatwe have not been able to test as a result of the cves not exploiting these,like attacks through images. Our prototype implementation lacks severalperformance enhancements which would greatly lower the overhead causedby the extension, like parallelizing signature loading and sanitization, as wellas using more efficient data structures to store signatures.False positives and false negatives. Due to the nature of our ap-proach, it is nigh impossible to completely get rid of false positives. Whilewe concluded that the rate of false positives is very low for loaded signa-tures, these can still occur when a signature is correctly loaded, since the40sanitization might erroneously delete valid elements. We aim to reproducethe developer’s intention with regards to when scripts should be able to run,however, this won’t always be possible, as there will be cases where thereare injection points where non-malicious JavaScript is allowed. If the san-itization applied targets JavaScript code, for example, a false positive willlikely be triggered.Furthermore, since we rely on handwritten signatures to defend againstattacks, exploits for which no signature has been written are not defendedagainst, so it is possible that not every single injection point of every websitewill be covered, and there might also be false negatives. In the future, weintend to study the rate of false positives and negatives in our approachand compare it to previous work. Faulty sanitization could be reduced byimplementing our sanitization methods as a lexer instead of the declarativeversion we currently have: The signature developer would ideally provide theallowed behaviour in a given injection point, and the detector would checkthe injection content against the signature-specified behaviour, providing aproof of whether the content could have been generated by following therules. If the sanitizer determines that the content could not have beenproduced via the allowed set of rules, it would proceed to eliminate eitherthe whole content itself, or the part of the content which is invalid.Usability. A main aspect of our work is its increased potential forusability and adoption from both a user’s perspective that installs the ex-tension to defend themselves against xss, and a signature developer thathas to write the database descriptions according to a known cve. Futurework could focus on usability studies related to both of these components.Protection against CSRF. While our work has only focused on xss,we believe we can easily adapt our network filter to defend against Cross-Site Request Forgery (csrf) exploits as well. Using a similar signaturelanguage as the one for xss, a signature developer could specify pages withpotential vulnerabilities and enforce that network requests do not exploitsuch vulnerabilities. In some scenarios, it might be useful to track domevents, e.g., user clicks to protect against clickjacking attacks. This kind ofinformation is not available to the network; however, the extension could41install a script on the page to monitor these actions.Dealing with an increasing amount of signatures. Our naive ap-proach at signature filtering, once a probe for a framework passes, has beeneffective with our current amount of signatures. However, as the number ofsignatures increases, and more types of sites are covered, the performanceimpact may increase drastically. As of September 2019, cve Details had14894 xss vulnerabilities in its database [3]. This means that our currentsignatures only cover 0.5% of all existing xss vulnerabilities. More efficientapproaches at searching and filtering, as well as for the data structures usedin the signature database could be applied to maintain a low performanceoverhead. The task of signature filtering, for example, is embarrassinglyparallel in the number of signatures. Most users will visit the same pagesnumerous times. Caching certain aspects of the filtering process can resultin a improved performance over several loads: for example, if a page doesnot run WordPress, it is unlikely to suddenly start running WordPress inthe near future. In this case, we could cache the probing component andskip it entirely for the next load.Design considerations. Our current design allows a single filter to beused to protect multiple users. In our current implementation, each browseruser has to install our extension. However, the same functionality could beoffloaded to a single processing unit in the form of a proxy, which handlesthe filtering for all machines in a network. This deployment model might bemore feasible for certain environments.While any user could alter their local signature database, most will nothave the technical expertise to do so. However, a trusted community ofusers could flag websites as being potentially malicious as part of a separatedatabase, saving time for others.We continue working on the system to make it more robust, both in termsof being able to defend against a myriad of attacks, as well as providing easeof development for signatures.42Chapter 8Related WorkIn the following sections, we discuss related work and how it compares withour own. We highlight the similarities and how our work improves uponthese previous ideas. We classify existing work into multiple categories:client-side, server-side, browser built-in, and hybrid: a combination of these.8.1 Server-side techniquesIn addition to existing parameter sanitization techniques, taint-tracking hasbeen proposed as a means to consolidate sanitization of vulnerable param-eters [29, 37, 38, 45]. These techniques are complementary to ours and,provide an additional line of defence against xss. However, many of themrely on the client-side rendering to maintain the server-side properties, whichwill not always be the case.8.2 Client-side techniquesDOMPurify [31] presents a robust xss filter that works purely on the client-side. The authors argue that the dom is the ideal place for sanitizationto occur. While we agree with this view, their work relies on applicationdevelopers to adopt their filter and modify their code to use it. This is aproblem because developers might not be aware of vulnerable points in theirapplication beforehand. In our study, we saw many instances of input pa-43rameters lacking basic sanitization. Thus, this technique is complementaryto ours, and we have decided to use the DOMPurify filter for our injectionpoints. We also believe the api is straightforward and simple to use, andwon’t require much signature developer effort to use effectively.Jim et al. [32] present a method to defend against injection attacksthrough Browser-Enforced Embedded Policies. This approach is similar toours, as the policies specify places where script execution should not occur.However, policies are defined by the application developers, and this againrelies on them to know where their code might be vulnerable. Furthermore,browser modifications are required to benefit from it, and issues of cross-portability and backwards compatibility arise.Hallaraker and Vigna [30] use a policy language to detect malicious codeon the client-side. Similarly to us, they make use of signatures to pro-tect against known types of exploits. However, unlike our approach, theirsignatures are not application-level, and there is no model for signaturemaintenance. Furthermore, there is no evaluation on the efficacy of theirsignatures.Although not solely related to xss, Snyder et al. [39] report a study inwhich they disable several JavaScript apis and test the number of websitesthat are clearly non-functional without the full functionality of the apis.They present a novel technique to interpose on JavaScript execution via theuse of ES6 Proxies, allowing for efficient trapping of function calls. Thisapproach increases security due to the number of vulnerabilities present inseveral JavaScript apis, however, we believe disabling whole aspects of apifunctionality should only be used as a last resort.8.3 Browser built-in defencesBrowsers are equipped with several built-in defences. We previously de-scribed XSS Auditor in Chapter 1, the other two important ones are ContentSecurity Policy and the same-origin policy:• Content Security Policy (csp) [8] has been widely adopted and in manycases provides developers with a reliable way to protect against xss44and csrf attacks. However, csp requires the developer to identifywhich scripts might be malicious. This is particularly hard in the caseof inline scripts, like the ones used in many xss exploits.• Same-origin policy [9] is another useful security mechanism for pro-tection against xss and csrf. This policy restricts how a documentor script loaded from one origin can interact with a resource fromanother origin. This is useful in many attack scenarios, particularlyagainst csrf in cross-origin attacks. As with csp, if the attack is in-jected in the same website the attacker intends to compromise, thiswill not defend against it.As with other approaches these browser defences are complementary toours.8.4 Client and server hybridsXSS-Dec [43] employs a hybrid solution, mainly via the use of a proxy, whichkeeps track of an encrypted version of the server’s source files, and uses thisinformation to derive exploits in a page visited by the user. This approachis similar to ours, in the sense that we assume previous knowledge of theclean html document. Furthermore, they use both anomaly-based detectionand signature-based detection to calculate the likelihood of an attack takingplace, and prevent it from happening. However, there is no mention ofsignature maintenance. In a way, our system offloads all this functionalityto the client-side, without the need of any server-side information.45Chapter 9ConclusionWe have presented XSnare, a fully client-side protection mechanism againstxss. This approach has many benefits over currently existing systems, aswell as being complementary to many of them. Our firewall architecturemakes it so that users can protect themselves in the face of an ever-increasingnumber of potential attacks and attack vectors, with little additional effortrequired for a knowledgeable security analyst when taking into considerationthe existing vulnerability detection work flow. The cve study we conductedshowed that the provided api for sanitization and injection point detectionis effective, as 94.2% of these vulnerabilities could be defended against withour tool. Our prototype implementation meets the required performancegoals to not be detrimental to an user’s web browsing experience, as webpage load times are affected by less than 10% overhead on 72.6% of sites.46Bibliography[1] Noscript homepage. URL https://noscript.net/. → pages 2, 3, 4[2] Moz top 500 websites. URL https://moz.com/top500. → pages iii, 31[3] Vulnerabilities by type. URLhttps://www.cvedetails.com/vulnerabilities-by-types.php. → page 42[4] Hacked website report – 2016/q3, 2016. URLhttps://sucuri.net/reports/Sucuri-Hacked-Website-Report-2016Q3.pdf.→ page 2[5] Security report for in-production web applications, 2018. URLhttps://www.rapid7.com/resources/security-report-for-in-production-web-applications/. → page 4[6] Wordpress plugin responsive cookie consent 1.7 / 1.6 / 1.5 -(authenticated) persistent cross-site scripting, 2018. URLhttps://www.exploit-db.com/exploits/44563. → page 7[7] Reducing the precision of the domhighrestimestamp resolution, 2018.URL https://github.com/w3c/hr-time/issues/56. → page 30[8] Same-origin policy, 2019. URL https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin policy. → page 44[9] Content security policy (csp), 2019. URLhttps://developer.mozilla.org/en-US/docs/Web/HTTP/CSP. → page 45[10] Bolt cms usage statistics, 2019. URLhttps://trends.builtwith.com/cms/Bolt-CMS. → page 29[11] Wordpress: Vulnerability statistics, 2019. URLhttps://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor id=2337. → page 2647[12] Wordpress cves, 2019. URLhttps://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress. → page 25[13] Intent to deprecate and remove: Xssauditor, 2019. URLhttps://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/TuYw-EZhO9g/blGViehIAwAJ. → page 3[14] Exploit database, 2019. URL https://www.exploit-db.com/. → page 28[15] 30+ joomla statistics for the informed digital marketer in 2019, 2019.URL https://hostingtribunal.com/blog/joomla-statistics/. → page 28[16] Limesurvey, 2019. URL https://www.limesurvey.com/. → page 28[17] nmap network mapper, 2019. URL https://nmap.org/. → page 18[18] Navigation timing level 2, 2019. URLhttps://www.w3.org/TR/navigation-timing-2/. → page 30[19] Responsive cookie consent 1.8 patches, 2019. URLhttps://plugins.trac.wordpress.org/browser/responsive-cookie-consent/tags/1.8/includes/admin-page.php. → page 8[20] Security and privacy considerations for domhighrestimestampresolution, 2019. URL https://github.com/w3c/hr-time/issues/79. →page 30[21] Safely inserting external content into a page, 2019. URLhttps://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Safely inserting external content into a page. →page 10[22] Wordpress plugin responsive cookie consent 1.7 / 1.6 / 1.5 -(authenticated) persistent cross-site scripting, 2019. URLhttps://www.exploit-db.com/exploits/44563. → page 21[23] Usage of content management systems for websites, 2019. URLhttps://w3techs.com/technologies/overview/content management/all.→ page 35[24] Wordpress powers 25% of all websites, 2019. URL https://w3techs.com/blog/entry/wordpress-powers-25-percent-of-all-websites.→ page 2548[25] Wordpress: Plugins, 2019. URL https://wordpress.org/plugins/. →page 25[26] Wpscan, 2019. URL https://wpscan.org/. → page 26[27] Statistics show why wordpress is a popular hacker target, 2019. URLhttps://www.wpwhitesecurity.com/statistics-70-percent-wordpress-installations-vulnerable/. → page 2[28] Xss auditor, 2019. URLhttps://www.chromium.org/developers/design-documents/xss-auditor.→ page 3[29] P. Bisht and V. N. Venkatakrishnan. Xss-guard: Precise dynamicprevention of cross-site scripting attacks. In Proceedings of the 5thInternational Conference on Detection of Intrusions and Malware,and Vulnerability Assessment, DIMVA ’08, pages 23–43, Berlin,Heidelberg, 2008. Springer-Verlag. ISBN 978-3-540-70541-3.doi:10.1007/978-3-540-70542-0 2. URLhttp://dx.doi.org/10.1007/978-3-540-70542-0 2. → pages 4, 43[30] O. Hallaraker and G. Vigna. Detecting malicious javascript code inmozilla. In Proceedings of the 10th IEEE International Conference onEngineering of Complex Computer Systems, ICECCS ’05, pages85–94, Washington, DC, USA, 2005. IEEE Computer Society. ISBN0-7695-2284-X. doi:10.1109/ICECCS.2005.35. URLhttp://dx.doi.org/10.1109/ICECCS.2005.35. → pages 4, 44[31] M. Heiderich, C. Spa¨th, and J. Schwenk. Dompurify: Client-sideprotection against xss and markup injection. In S. N. Foley,D. Gollmann, and E. Snekkenes, editors, Computer Security –ESORICS 2017, pages 116–134, Cham, 2017. Springer InternationalPublishing. ISBN 978-3-319-66399-9. → pages 1, 10, 43[32] T. Jim, N. Swamy, and M. Hicks. Defeating script injection attackswith browser-enforced embedded policies. In Proceedings of the 16thInternational Conference on World Wide Web, WWW ’07, pages601–610, New York, NY, USA, 2007. ACM. ISBN 978-1-59593-654-7.doi:10.1145/1242572.1242654. URLhttp://doi.acm.org/10.1145/1242572.1242654. → pages 1, 4, 44[33] E. Kirda, N. Jovanovic, C. Kruegel, and G. Vigna. Client-sidecross-site scripting protection. Comput. Secur., 28(7):592–604, Oct.492009. ISSN 0167-4048. doi:10.1016/j.cose.2009.04.008. URLhttp://dx.doi.org/10.1016/j.cose.2009.04.008. → pages 4, 5[34] P. Kocher, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp,S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom. Spectre attacks:Exploiting speculative execution. CoRR, abs/1801.01203, 2018. URLhttp://arxiv.org/abs/1801.01203. → page 30[35] I. Muscat. Acunetix vulnerability testing report 2017, jun 2017. URLhttps://www.acunetix.com/blog/articles/acunetix-vulnerability-testing-report-2017/. → page 1[36] Y. Nadji, P. Saxena, and D. Song. Document structure integrity: Arobust basis for cross-site scripting defense., 01 2009. → pages 1, 8[37] A. Nguyen-Tuong, S. Guarnieri, D. Greene, J. Shirley, and D. Evans.Automatically hardening web applications using precise tainting. InSecurity and Privacy in the Age of Ubiquitous Computing, IFIP TC1120th International Conference on Information Security (SEC 2005),May 30 - June 1, 2005, Chiba, Japan, pages 295–308, 2005. → pages4, 43[38] T. Pietraszek and C. V. Berghe. Defending against injection attacksthrough context-sensitive string evaluation. In Proceedings of the 8thInternational Conference on Recent Advances in Intrusion Detection,RAID’05, pages 124–145, Berlin, Heidelberg, 2006. Springer-Verlag.ISBN 3-540-31778-3, 978-3-540-31778-4. doi:10.1007/11663812 7. URLhttp://dx.doi.org/10.1007/11663812 7. → pages 4, 43[39] P. Snyder, C. Taylor, and C. Kanich. Most websites don’t need tovibrate: A cost-benefit approach to improving browser security. InProceedings of the 2017 ACM SIGSAC Conference on Computer andCommunications Security, CCS ’17, pages 179–194, New York, NY,USA, 2017. ACM. ISBN 978-1-4503-4946-8.doi:10.1145/3133956.3133966. URLhttp://doi.acm.org/10.1145/3133956.3133966. → pages 2, 44[40] M. Steffens, C. Rossow, M. Johns, and B. Stock. Don’t trust thelocals: Investigating the prevalence of persistent client-side cross-sitescripting in the wild. In 26th Annual Network and Distributed SystemSecurity Symposium, NDSS 2019, San Diego, California, USA,February 24-27, 2019, 2019. → page 450[41] B. Stock, S. Lekies, T. Mueller, P. Spiegel, and M. Johns. Preciseclient-side protection against dom-based cross-site scripting. InProceedings of the 23rd USENIX Conference on Security Symposium,SEC’14, pages 655–670, Berkeley, CA, USA, 2014. USENIXAssociation. ISBN 978-1-931971-15-7. URLhttp://dl.acm.org/citation.cfm?id=2671225.2671267. → page 3[42] B. Stock, M. Johns, M. Steffens, and M. Backes. How the web tangleditself: Uncovering the history of client-side web (in)security. InProceedings of the 26th USENIX Conference on Security Symposium,SEC’17, pages 971–987, Berkeley, CA, USA, 2017. USENIXAssociation. ISBN 978-1-931971-40-9. URLhttp://dl.acm.org/citation.cfm?id=3241189.3241265. → page 2[43] S. Sundareswaran and A. C. Squicciarini. Xss-dec: A hybrid solutionto mitigate cross-site scripting attacks. In Proceedings of the 26thAnnual IFIP WG 11.3 Conference on Data and Applications Securityand Privacy, DBSec’12, pages 223–238, Berlin, Heidelberg, 2012.Springer-Verlag. ISBN 978-3-642-31539-8.doi:10.1007/978-3-642-31540-4 17. URLhttp://dx.doi.org/10.1007/978-3-642-31540-4 17. → pages 1, 45[44] P. Wurzinger, C. Platzer, C. Ludl, E. Kirda, and C. Kruegel. Swap:Mitigating xss attacks using a reverse proxy. In Proceedings of the2009 ICSE Workshop on Software Engineering for Secure Systems,IWSESS ’09, pages 33–39, Washington, DC, USA, 2009. IEEEComputer Society. ISBN 978-1-4244-3725-2.doi:10.1109/IWSESS.2009.5068456. URLhttp://dx.doi.org/10.1109/IWSESS.2009.5068456. → page 1[45] W. Xu, S. Bhatkar, and R. Sekar. Taint-enhanced policy enforcement:A practical approach to defeat a wide range of attacks. In Proceedingsof the 15th Conference on USENIX Security Symposium - Volume 15,USENIX-SS’06, Berkeley, CA, USA, 2006. USENIX Association. URLhttp://dl.acm.org/citation.cfm?id=1267336.1267345. → pages 4, 4351AppendixWe provide a description of our signature language:• url: If the exploit occurs in a specific URL or subdomain, this is definedas a string, e.g. /wp-admin/options-general.php?page=relevanssi%2Fre-levanssi.php, otherwise null.• software: The software framework the page is running if any, e.g.WordPress. A hand-crafted page might not have any identifiable soft-ware.• softwareDetails: If running any software, this provides further infor-mation about when to load a signature. For WordPress, for example,these are plugin names as depicted in the html of a page running suchplugin.• version: The version number of the software/plugin/page. This isused for versioning of the page’s underlying software, as described inSection 3.1.2.• type: A string describing the signature type. A value of “string” de-scribes a basic signature. A value of “listener” describes a signaturewhich requires an additional listener in the background page for net-work requests.• sanitizer: A string with one of the following values: “DOMPurify”,“escape”, and “regex”. This item is optional, the default is DOMPurify.52• config: The config parameters to go along with the chosen sanitizer, ifnecessary. For “DOMPurify”, the accepted values are as defined by theDOMPurify api (i.e, DOMPurify.sanitize(dirty, config). For “escape”,an additional escaping pattern can be provided. For “regex”, thisshould be the pattern to match with the injection point content.• typeDet: A string with the following pattern: “occurrence-uniqueness”.As described in Section 2.3, this specifies whether there are several in-jection points in the html.• endPoints: An array of startpoint and endpoint tuples.• endPointsPositions: An array of integer tuples. These are optional butuseful when the one of the endPoints html are used throughout thewhole page and appear a fixed number of times. For example: if an in-jection ending point happens on an element <h3 class=‘my-header’>,this element might have 10 appearances throughout the page. How-ever, only the 4th is an injection ending point. The signature wouldspecify the second element of the tuple to be 7, as it would be the 7thsuch item in a regex match array (using 1-based indexing), countingfrom the bottom up. For ending points, we have to count from thebottom up because the attacker can inject arbitrarily many of theseelements before it, and vice versa for starting points.Additionally, if the value of type is ‘listener’, the signature will have anadditional field called listenerData. Similarly to a regular signature, thisconsists of the following pieces of information:• listenerType: The type of network listener as defined by the WebRe-quest api (e.g. ‘script’, ‘xhr’, etc.)• listenerMethod: The request’s HTTP method, for example “GET” or“POST”.• url: the URL of the request target.53

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            data-media="{[{embed.selectedMedia}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.24.1-0384040/manifest

Comment

Related Items