XSnare: Application-specific client-side cross-site ...

XSnare Application-specific client-side cross-sitescripting protection

Jose Carlos PazosDepartment of Computer ScienceUniversity of British Columbia

Vancouverjpazoscsubcca

Jean-Sebastien LegareDepartment of Computer ScienceUniversity of British Columbia

Vancouverjslegarecsubcca

Ivan BeschastnikhDepartment of Computer ScienceUniversity of British Columbia

Vancouverbestchaicsubcca

AbstractmdashWe present XSnare a client-side Cross-Site Script-ing (XSS) solution implemented as a Firefox extension Theclient-side design of XSnare can protect users before applicationdevelopers release patches and before server operators applythem

XSnare blocks XSS attacks by using previous knowledge ofa web applicationrsquos HTML template content and the rich DOMcontext XSnare uses a database of exploit descriptions whichare written with the help of previously recorded CVEs It singlesout injection points for exploits in the HTML and dynamicallysanitizes content to prevent malicious payloads from appearingin the DOM XSnare displays a secured version of the site evenif is exploited

We evaluated XSnare on 81 recent CVEs related to XSSattacks and found that it defends against 938 of these exploitsTo the best of our knowledge XSnare is the first protectionmechanism for XSS that is application-specific and based onpublicly available CVE information We show that XSnarersquosspecificity protects users against exploits which evade other moregeneric XSS defenses

Our performance evaluation shows that our extensionrsquos over-head on web page loading time is less than 10 for 726 ofthe sites in the Moz Top 500 list

I INTRODUCTION

Cross-Site Scripting (XSS) is still one of the most dom-inant web vulnerabilities A 2017 report showed that 50of websites contained at least one XSS vulnerability [1]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 validationuser-chosen data ldquoescapesrdquo into a pagersquos template and makesits way into the JavaScript engine or modifies the DocumentObject Model (DOM) Consequently many of the XSS de-fenses published so far propose to fix the problem at thesource by properly separating the template from the user dataon the server or by modifying browsers [2] [3] [4] [5] [6]There are also similar solutions that can be implemented inthe front-end code of an application [7] In all cases thesetechnologies must be adopted by the application softwaredevelopers otherwise users are left unprotected

One barrier to adoption of existing XSS defenses is thatdevelopers may not have the necessary expertise or sufficientresources to use the approach Luckily users wishing to gainreassurance over the safety of the sites they visit can installbrowser extensions to filter malicious scripts and content

Unfortunately some of the most popular of these extensionslike NoScript [8] achieve most of their security by disablingfunctionality such as JavaScript which impairs usability1 Astudy by Snyder et al [10] showed that browser securitycan be increased by disabling some rarely used JavaScriptAPIs largely retaining usability Our work builds on this idearetaining website usability after an exploit is disabled

When an XSS vulnerability is disclosed some softwarevendors respond with patches If the affected software isreleased in the form of packages frameworks or librariesand used by several web applications there is delay beforeusers can benefit from the patch Most importantly the patchedsoftware must be re-deployed by site administrators

Unfortunately website administrators will not and oftencannot apply software updates immediately one study foundthat 61 of WordPress websites were running a version withknown security vulnerabilities [11] In another report we learnthat 3095 of Alexarsquos top 1 Million sites run a vulnerableversion of WordPress [12]

Users are at the mercy of developers and administrators ifthey want to access safe up-to-date applications Our solutionXSnare helps with this problem ndash based on information frompast disclosures XSnare patches known page vulnerabilitiesdirectly in the browser

Dev

Server side networking

-Server Firewall-Web Application firewall

Client side networking

-Client firewall-Blacklisted sites-Proxies

User

-XSS Auditor-NoScript-XSnare

1 2 3 4

-Static analysis -Sanitization

Browser

Fig 1 Different web security solutions with XSnare on theclient-side

Each layer of the web application stack (Figure 1) presentsdifferent options to defend against XSS Note that solutions atdifferent layers are often complementary

1) The application logic is the first line of defence Codesafety can be enhanced with third-party vulnerability

1As early as 2012 JavaScript was used by almost 100 of the Alexa top500 sites [9]

scanning solutions and a thorough code-review processTaint and static code analysis tools can detect unsani-tized inputs

2) In the hosting environment network firewalls specif-ically Web Application Firewalls (WAFs) can defendagainst attacks such as DDoS SQL injections and XSS

3) In the clientrsquos environment (residential or commercial)users may install network firewalls network contentfilters and web proxies

4) The last line of defence is the browser Browser havebuilt-in defences such as Chromersquos XSS Auditor [13]Users can also install third-party extensions to blockmalicious requests and responses such as NoScript [8]and XSnare

We make two observations about existing solutions (a)server-side solutions have to be applied independently on eachserver and (b) solutions on the client are typically writtenas generic filters which attempt to catch everything andconsequently do not take full advantage of the specificity ofthe application or the vulnerability

For example a WAF can effectively protect the usersbehind it but users cannot realistically expect every site tobe protected by a WAF At the opposite end in the clientrsquosenvironment a user might configure a network proxy forall website traffic with generic rules achieving maximumcoverage but this will often lead to an elevated rate of falsepositives (FPs)

Similarly browser built-in defences are coarse-grained andwork on just a subset of exploits Chromersquos XSS Auditorfor example only attempts to defend against reflected XSSGoogle recently announced its intention to deprecate XSSAuditor for reasons including ldquoBypasses aboundrdquo ldquoIt pre-vents some legit sites from workingrdquo and ldquoOnce detectedtherersquos nothing good to dordquo [14] Stock et al [15] proposeenhancements to XSS Auditor and cover a wider range ofexploits than the auditor but are limited to DOM-based XSSBy contrast our work covers all types of XSS

Implementing adequate server-side protections [16] [17][18] [19] requires time A 2018 study found that the averagetime to patch a known exploit in the form of a CommonVulnerability and Exposures (CVE) all severities combinedis 38 days increasing to as much as 54 days for low severityCVEs and the oldest unpatched CVE was 340 days old [20]

Server-side defences also do not commonly protect againstclient-only forms of XSS eg reflected XSS or persistentclient-side XSS which use a browserrsquos local storage or cookiesas an attack vector Steffens et al [21] present a study ofpersistent client-side XSS across popular websites and findthat as many as 21 of the most frequented web sites arevulnerable to these attacks To provide users with the meansto protect themselves in the absence of control over serverswe believe that a client-side solution is necessary

A number of existing solutions in this area also suffer fromhigh rates of false-positives and false-negatives For exampleNoScript [8] works via domain white-listing thus by defaultJavaScript scripts and other code will not execute However

not all scripts outside of the whitelist should be assumed to bemalicious Browser-level filters like XSS Auditor use generalpolicies and can therefore incorrectly sanitize non-maliciouscontent

We posit that the DOM is the right place to mitigate XSSattacks as it provides a full picture of the web applicationWhile most of the functionality we provide could be done bya network filter in front of the browser we take advantageof additional browser context Particularly when an exploitoccurs as a result of user interactions like in response to aclick our approach benefits from knowing the initiating tab tofilter the response Previous client-side solutions have optedfor detectors that were generic and site-agnostic [22] [3] [23]Our work goes in the opposite direction and tries to insteadprevent precisely-defined exploits in specific applications

If a patch for a server-side vulnerability can be ldquotranslatedrdquointo an equivalent set of operations to apply on the fullyformed HTML document in the browser then we can seize theopportunity to defend early against exploits of that vulnera-bility Our extension which has access to the userrsquos browsingcontext can identify vulnerable pages based on a databaseof signatures for previous disclosures This way XSnare canprotect users as soon as a patch is implemented and added toits database The client-side patch will remain beneficial untilall server operators running that software have had a chanceto upgrade their deployments

A similar philosophy is adopted by the client-side firewall-based network proxy Noxes [22] However due to theirposition in the stack these policies do not defend againstattacks invisible to the network eg deleting local files

Our systemrsquos signatures are designed to be application-specific both in terms of exploit detection and sanitizationApplication-specific signatures accurately dispose of exploitswhile retaining the web sitersquos usability

We evaluate XSnare by testing it on 81 recent XSS CVEsWe also report XSnarersquos performance overhead on page loadtimes across a wide range of sites and show that it does notsignificantly impact the userrsquos browsing experience

To summarize our contributions includebull XSnare a novel client-side framework that protects users

against XSS vulnerabilities with a database of signaturesfor these vulnerabilities written in a declarative language

bull A mechanism to correctly isolate a vulnerable injectionpoint in a web page and to apply the intended server-sidepatch on the client-side

bull A collection of signatures to protect users against realXSS CVEs (Section V) demonstrating the practicalityof XSnare and the evaluation of its impact on browsing(Section VI)

II XSNARE DESIGN

We now present the design of XSnare and its components(Figure 2) We begin by reviewing our threat model

A Threat modelOur work makes no assumptions about the web server

In particular the server may run out of date and vulnerable

2

HTTP request (eg load examplecom)

Security analyst uploads signature to database

Userrsquos browserRequest processing DOM render

Detector loads pagersquos signatures

Sanitizer deletes malicious injected content

Browser displays clean document

Fig 2 XSnarersquos approach to protect against XSS

software that delivers pages to the userrsquos browser with XSSexploits

We trust the browser and the browserrsquos extension mech-anism to correctly execute XSnare We also depend on thebrowser to disallow malicious tampering with the client-sidesignature database

We trust the analyst who writes the signature definitionsused by XSnare For XSnare to be effective the signaturesmust be correct However a signature that fails to match avulnerability will only impact the page with longer load times

B Overview

We now review the high-level operation of XSnare withFigure 2 A user requests a page examplecom on a browserwith the XSnare extension installed The response may ormay not contain malicious XSS payloads Before the browserrenders the document XSnare analyzes the potentially mali-cious document The extension loads signatures from its localdatabase into its detector The detector analyzes the HTMLstring arriving from the network and identifies the signatureswhich apply to the document These signatures specify oneor more ldquoinjection spotsrdquo in the document which correspondroughly speaking to regions of the DOM where improperlysanitized content could be injected The extensionrsquos sanitizereliminates any malicious content and outputs a clean HTMLdocument to the browser for rendering

C An example application of XSnare

To further explain our approach we present a small exampleof how HTML context can be used to defend against XSStaken from CVE 2018-10309 [24] This is reproducible inan off-the-shelf WordPress installation running the ResponsiveCookie Consent plugin v17 This is a stored XSS vulnera-bility and as such is not caught by some generic client-sideXSS filters including Chromersquos XSS auditor

Consider a website running PHP on the backend whichstores user input from one user and displays it later to anotheruser inside an input element

The PHP code defines the static HTML template (in black)as well as the dynamic input (in red)ltinput id=rcc_settings[border-size]name=rcc-settings[border-size]type=text value=ltphp rcc_value(rsquoborder-sizersquo)

gtgt

ltlabel class=descriptionfor=rcc_settings[border-size]gt

Normally the input might have a value of rdquo0rdquoltinput id=rcc_settings[border-size]name=rcc-settings[border-size]type=text value=0gtltlabel class=descriptionfor=rcc_settings[border-size]gt

However the php code is vulnerable to an injection attackborder-size = gtltscriptgtalert(rsquoXSSrsquo)ltscriptgt

The browser will render this executing the injected scriptltinput id=rcc_settings[border-size]name=rcc-settings[border-size]type=text value=gtltscriptgtalert(rsquoXSSrsquo)ltscriptgtltlabel class=descriptionfor=rcc_settings[border-size]gt

Note that the resulting HTML is well-formed so a meresyntactic check will not detect the malicious injection Letus assume a security analyst knows the original templateie without injected content If the analyst were given afilled-in document they could (in most cases) separate theinjected content from the server-side template and get rid ofthe malicious script entirely using proper sanitization

The injected script is bounded by template elements withidentifiable attributes Assuming (for now) that there is onlyone such vulnerable injection point we can search for theinput element from the top of the document and the labelfrom the bottom to ensnare the injection points in the HTML

This shares goals with the clientserver hybrid approach ofNadji et al [4] They automatically tag injected DOM elementson the server-side using a taint-tracking so that the client (amodified browser) can reliably separate template vs injectedcontent We do not require any server-side modifications butrather opt for a client-side tagging solution based on exploitdefinitions

The injected content once identified must be sanitizedappropriately The appropriate action will depend on theapplication setting but assuming a patch has been writtenit suffices to translate the intention in the server codersquos pathto the client-side This can be straightforward once the fix isunderstood

The developer incorrectly claimed the bug had been fixed inversion 18 of the plugin Other similar vulnerabilities had in-deed been fixed but not this one [25] The built-in WordPressfunction sanitize text field needed to be applied

XSnare does not automatically determine the actions toimplement from a patch We assign this task to a securityanalyst who acts as the signature developer for an exploitThe system automates signature matching and sanitization

D XSnare Signatures

Our signature definitions make two assumptions first aninjection must have a start point and end point that isan element can only be injected between a specific HTMLnode and its immediate sibling in the DOM tree second in awell-formed DOM the dynamic content will not be able to

3

rearrange its location in the document without JavaScriptexecution (eg removing and adding elements) allowing usto isolate it from the template

Pages commonly contain more than one vulnerable injectionpoint We discuss the difficulty of supporting these pages inSection II-G

We believe CVEs are an ideal source of signature defini-tions Previous client-side work does not benefit from our levelof specificity these tools often use less accurate heuristicsto detect exploits Of course XSnare signatures will notwrite themselves Luckily converting the CVE informationinto a signature does not require active participation fromthe application developers ndash security enthusiasts and webdevelopers are sufficiently skilled to compose signatures

In general we do not require the existence of a publiclydisclosed CVE to be able to write a signature for an exploitCVEs have been useful to us as we did not discover the ex-ploits A knowledgeable analyst can write a signature without apublic CVE In fact for security measures many CVEs are notpublicly available until the application developer has patchedits software Our system can help reduce the time betweenzero day attacks and patch deployment an analyst can writea signature for a vulnerability as soon as they know the issue

Long term we imagine that volunteers (or entrepreneurs)would cultivate and maintain the signature database Newsignatures could be contributed by a community of amateuror professional security analysts in a manner not so differentfrom how antispam or antivirus software is managed Thepopular ad blocking extension AdBlock for example relieson filter rules taken from open-source filter lists [26]

The challenge of automatically deriving signatures fromdetailed CVEs is an interesting one albeit outside the scopeof this paper

E Firewall Signature Language

Our signature language needs enough power of expressionfor the signature writer to be precise both for determining thecorrect web application and to identify the affected areas inthe HTML For injection point isolation a language based onregular expressions suffices to express precise sections of theHTML The following is the signature that defends against themotivating example of Section II-C

Listing 1 An XSnare signatureurl

rsquowp-adminoptions-generalphppage=rcc-settingsrsquosoftware rsquoWordPressrsquosoftwareDetails rsquoresponsive-cookie-consentrsquoversion rsquo15rsquotype rsquostringrsquotypeDet rsquosingle-uniquersquosanitizer rsquoregexrsquoconfig rsquoˆ[0-9]([0-9]+)$rsquoendPoints[rsquoltinput id=rcc_settings[border-size]

name=rcc_settings[border-size] type=textvalue=rsquo

rsquoltlabel class=descriptionfor=rcc_settings[border-size]gtrsquo]

In summary a signature will have the necessary informa-tion to determine whether a loaded page has a vulnerabilityand specify appropriate actions for eliminating any maliciouspayloads

Analysts configure their signatures with one function cho-sen from the static set of sanitization functions offered byXSnare (Section III-B) These functions inoculate potentiallymalicious injections based on the DOM context surroundingthe injection The goal of signatures is to provide suchsanitization ideally without ldquobreakingrdquo the user experienceof the page The default function preset is DOMPurifyrsquos [7]default configuration which takes care of common sanitizationneeds [27] However DOMPurifyrsquos defaults can be unneces-sarily restrictive or not restrictive enough in which case theother sanitization methods are preferable

We considered allowing arbitrary sanitization code in signa-tures While it would open complex sanitization possibilitieswe have decided against it principally for security reasonsThe minimal set of functions we settled on also sufficed toexpress all of the signatures defined for this paper

F Browser Extension

Our systemrsquos main component is a browser extension whichrewrites potentially infected HTML into a clean documentThe extension detects exploits in the HTML by using signaturedefinitions and maintains a local database of signatures Weleave the design of an update mechanism to future work butin its current form the database is bundled with each newinstallation of the extension

The extension translates signature definitions into patchesthat rewrite incoming HTML on a per-URL basis accordingto the top-down bottom-up scan described in Section II-C

The extensionrsquos detector acts as an in-network filter Weinitially considered other designs but quickly found out thatapplying the patch at the network level was necessary forsanitization correctness even before any code runs parsingthe HTML into a DOM tree might cause elements to bere-arranged into an unexpected order making our extensionsanitize the wrong spot Consider the following examplewhere an element inside a lttrgt tag is rearranged after parsingthe stringlttable class=wp-list-tablegtlttheadgt

lttrgtltthgtltthgtltimg src=1 onerror=alert(1)gtltthgtltform method=GET action=gt

In this HTML the signature developer might identify theexploit as occurring inside the given table However if we waituntil the string has been parsed into a DOM tree to sanitize theelements are rearranged due to lttrgt not allowing an ltimggtas its childltimg src=1 onerror=alert(1)gtlttable class=wp-list-tablegt

lttheadgtlttrgtltthgtltthgtltthgt

4

ltform method=GET action=gt

Note that the injected ltimggt tag is now outside of thetable simply by virtue of the DOM parsing The extensionwill not find an injection in the expected place creating afalse negative (FN) Similarly elements rearranged inside aninjection point can create false positives This example wouldgenerate a class of circumvention techniques for our detectorso we canrsquot wait until the website has been rendered to analyzethe response

G Handling multiple injections in one page

In Listing 1 the endPoints were listed as two strings in theincoming network response However there are cases wherearbitrarily many injection points can be generated by theapplication code such as a for loop generating table rowsFor these it is hard to correctly isolate each endPoint pair asan attacker could easily inject fake endPoints in between theoriginal ones

b)

a)

Fig 3 Example attacker injection when multiple injectionpoints exist in the page a) a basic injection pattern b) anattempt to fool the detector

In Figure 3a the brackets indicate a template The content inbetween is an injection point (the star) where dynamic contentis injected into the template In the case of a vulnerabilitythe injected content can expand to any arbitrary string Thesignature separates the injection from the rest by matchingfor the start and end points (the endPoints) represented bythe brackets This HTML originally has two pairs of endPointpatterns

In Figure 3b the attacker knows these are being usedas injection end points and decides to inject a fake endingpoint and a fake starting point (the dotted brackets) withsome additional malicious content in between If just lookingfor multiple pairs of end points the detector cannot tell thedifference between the solid and dotted patterns and will notget rid of the content injected in the star Therefore we haveto use the first starting point and the last ending point before astarting one (when searching from the bottom-up) and sanitizeeverything in between

+ +

Fig 4 Example attacker injection when multiple distinctinjection points exist in the page

Figure 4 illustrates a case when there are several injectionpoints in one page but each of them is distinct Now the

filter is only looking for one pair of brackets so the attackercanrsquot fool the extension into leaving part of the injectionunsanitized However they could for example inject an extraending bracket after the opening parenthesis (or an extrastarting brace) The extension will be tricked into sanitizingnon-malicious content the black pluses (+) Since we knowthe order in which the endPoints should appear when thefilter sees a closing endPoint before the next expected startingendPoint or similarly a starting endPoint before the nextexpected closing endPoint this attack can be identified Inthe diagram the order of the solid elements characterizes thepossible malformations in the end points

In both scenarios we have to sanitize the outermost endpoints This might get rid of a substantial amount of validHTML so we defer to the signature developerrsquos judgment ofwhat behavior the detector should follow We expand uponthis further in Section IV-A

Note that these complex cases do not mean that our ap-proach is not applicable as the extension provides a choicefor blocking the page entirely if the signature writer believesa given case is too complex for our signature language

H Dynamic injections

The top-level documents of web pages fetch additionaldynamic content via fetch or AJAX APIs Content fetched inthis way is also vulnerable to XSS and must be filtered Anexample vulnerability is CVE-2018-7747 (WordPress CalderaForms which allows malicious content retrieved from thepluginrsquos database to be injected in response to a click

XSnare allows XHR requests to be filtered with xhr-typesignatures To reduce the number of signatures that need to beconsidered when a browser issues a request we require thatsignatures for XHR be nested inside a signature for a top-leveldocument If a pagersquos main content matches an existing top-level signature description XSnare will then enable all nestedXHR listeners

Listing 2 shows an example of such a signature The idea isextensible to scripts and other objects loaded separately fromthe main document (eg images stylesheets etc)

Listing 2 An example dynamic request signature This patchesCVE-2018-7747listenerData [listenerType rsquoxhrrsquo listenerMethod rsquoPOSTrsquosanitizer rsquoescapersquo type rsquostringrsquolistenerUrl rsquowp-adminadmin-ajaxphprsquotypeDet rsquosingle-uniquersquoendPoints [rsquoltpgtltstronggtrsquo rsquo[AltBody]rsquo]

]

III IMPLEMENTATION

We implemented our system as an extension in Firefox 690Our signatures are stored in a local JavaScript file in the ex-tension package We decided on an extension implementationfor several reasons (1) Privileged execution environment Theextensionrsquos logic lies in a separate environment from the webapplication code This guarantees that malicious code in the

5

Algorithm 1 Network filter algorithm

1 global DBSignatures2 procedure verifyResponse (responseString url)3 loadedProbes = runProbes(responseString url)4 signaturesToCheck larr []5 for probe in loadedProbes do6 signaturesToCheckappend(DBSignatures[probe])7 end8 filteredSignatures larr []9 for signature in signaturesToCheck do

10 if responseString and url match signature then11 filteredSignaturespush(signature)12 end13 versionInfo larr loadVersions(url loadedProbes)14 endPoints larr []15 for signature in filteredSignatures do16 if (signaturesignatureversion) isin versionInfo

then17 endPointspush(signatureendPointPairs)18 end19 indices larr []20 for endPointPair in endPoints do21 indicespush(findIndices(responseString

endPointPair))22 end23 if discrepancies exist in indices then24 Block page load and return25 for endPointPair in endPoints do26 sanitize(responseStringindices)27 end28 end

application cannot affect the extension (2) Web applicationcontext Our solution requires knowledge of the applicationrsquoscontext The extension naturally retains this context (3) Inter-position abilities As it lies within the browser the extensioncan run both at the network level eg rewrite an incomingresponse and at the web application level eg interpose onthe applicationrsquos JavaScript execution

A Filtering process

Algorithm 1 describes our network filtering process once arequestrsquos response comes in through the network we processit and sanitize it if necessary

Loading signatures Our detector loads signatures and findsinjection points in the document However not all signaturesneed to be loaded for a specific website since not all sites runthe same frameworks When loading signatures we proceed ina manner similar to a decision tree The detector first probesthe page (line 3) to identify the underlying framework (thesoftware in our signature language) We currently providea number of static probes However as more applicationsare required to be included we believe it would be betterto cover this task in the signature definitions The widely

popular network mapping tool Nmap [28] uses probes ina similar manner kept in a modifiable file As mentionedin Section V we currently only have signatures for CMSapplications Our probes use specific identifiers related to theapplication as well as the particular site that is affected by theexploit WordPress pages for example have several elementsin the page that identify it as a WordPress page While thismight seem easier for CMS style pages and we acknowledgethat application fingerprinting is a hard problem in generalwe believe other web apps will also have similar identifyinginformation like headers element IDrsquos scriptCSS sourcesclasses etc Previous work has shown that DOM elementboundaries can be effectively identified given some previousknowledge of the DOM structure [29]

After running these probes the detector loads correspondingframeworksrsquo signatures and filters out checks whether theinformation of each loaded signature matches the page (lines5-12)

Version identification We then apply version identification(lines 13-16) Our objective for versioning is to preventsignatures from triggering false positives on websites runningpatched software We found this to be one of the harder aspectsof signature loading In many Content Management Systems(CMSs) for example file names are not updated with the latestversion and versioning information is often unavailable on theclient-side

We have observed that even if we load a signature whenthe application has already been patched on the server itwill often preserve the pagersquos functionality Motivated by thisobservation our mechanism follows a series of increasinglyaccurate but less precise version identifiers If versioning isunavailable in the HTML the patch is applied as we cannotbe sure the page is running patched software

Injection point search and sanitization Once we havethe correct signatures we find the indices for the endpointsusing our top-down bottom-up scan and need to check forpotential malformations in the injection points (lines 19-24)as described in Section II-G If this occurs the page loadis blocked and a message is returned to the user or ifthe signature developer specifies so sanitization proceeds onthe new endpoints Finally if all endPoint pairs are in theexpected order we sanitize each injection point (lines 25-27)

B Sanitization methodsWe provide different types of sanitization rdquoDOMPurifyrdquo

rdquoescaperdquo and rdquoregexrdquo DOMPurify works well as an out-of-the-box solution Escaping can be useful when only a fewcharacters need to be filtered Regex Pattern matching can beparticularly effective when the expected value has a simplerepresentation (eg a field for only numbers)

IV WRITING SIGNATURES

We expect a signature developer to have a solid understand-ing of the principles behind XSS as well as web applicationsHTML CSS and JavaScript so they can identify preciseinjection points In this section we aim to show that minoreffort is required from an analyst when writing a signature

6

A Case Study CVE-2018-10309

Going back to our example in Section II-C we describe theprocess for writing a signature using one of our studied CVEs

Identifying the exploit An entry in Exploit Database [30]describes a persistent XSS vulnerability in the WordPressplugin Responsive Cookie Consent for versions 171615This entry describes the Cookie Bar Border Bottom Sizeparameter as vulnerable We run a local WordPress installationwith this plugin

Establishing the separation between dynamic and staticcontent We insert the string rdquogtscriptgtalert(rsquoXSSrsquo)ltscriptgtin the Cookie Bar Border Bottom Size (rcc settings[border-size] in the HTML) input field as a proof of concept (PoC)This results in an alert box popping up in the page

In general the analyst can find the vulnerable HTML fromthe server-side code without reproducing the exploit Since wedid not discover the exploit we had to do this extra step

In the example the input element is the injection startingpoint and the label tag is the end point Identification ofcorrect endpoints is extremely important and in particularwhen a page has multiple injection points the signaturedeveloper must ensure the elements do not overlap with otherinnocuous ones In some cases the developer might think itbest to stop the page from loading due to the complexity of theinjection points We believe that if sanitization is impracticalcompromising usability for security is preferable

Collecting other required page information andwriting the signature The next step is to gatherthe remaining information to determine whether thesignature applies to the page loaded The full signaturefor this example was previously shown in Listing 1 Thepagersquos HTML includes a link to a stylesheet with hrefrdquohttplocalhost8080wp-contentpluginsresponsive-cookie-consentrdquo rdquowp-contentpluginsplugin-namerdquo is the standardway of identifying that a WordPress page is running a certainplugin in this case rdquoresponsive-cookie-consentrdquo Since theexploit only occurs in this specific spot in the HTML thetypeDet is listed as rdquosingle-uniquerdquo Since the vulnerableparameter is a border-size the sanitizer applied is rdquoregexrdquofurther restricting the pattern to only numbers in config Welist the endPoints as taken from the HTML

Testing the signature Finally we run the extension Weexpect to not have an alert box pop up and we manually lookat the HTML to verify correct sanitization If the exploit is notproperly sanitized the developer is able to use the debuggingtools provided by the browser to check the incoming networkresponse information seen by the extensionrsquos background pageand make sure it matches the signature values

V APPROACH EVALUATION

To verify the applicability of our detector and signaturelanguage we tested the system by looking at several recentCVEs related to XSS We have three objectives to verify thatour signature language provides the necessary functionality toexpress an exploit and its patch to test our detector against

existing exploits and to show that composing signatures takesa reasonable amount of time

A Methodology

We study recent CVEs related to WordPress plugins Wefocus on WordPress for two reasons

1) WordPress powers 347 of all websites according toa recent survey [31] [32] The same study states that303 of the Alexa top 1000 sites use WordPress Thuswe can be confident that our study results will hold truefor the average user

2) WordPress plugins are popular among developers (thereare currently more than 55000 plugins [33]) Due to itsuser popularity WordPress is also heavily analyzed bysecurity experts A search for WordPress CVEs on theMitre CVE database [34] gives 2310 results Pluginsspecifically are an important part of this issue 52 ofthe vulnerabilities reported by WPScan are caused byWordPress plugins [35]

We used a CVE database CVE Details [36] to find the100 most recent WordPress XSS CVEs as of October 2018For each CVE we set up a Docker container with a cleaninstallation of WordPress 52 and installed the vulnerablepluginrsquos version For CVEs that depended on a particularWordPress version we installed the appropriate version Of theCVEs we looked at only one occurred in WordPress core Webelieve it would be harder to precisely sanitize injection pointsin WordPress core as many of the plugins have particularsettings pages where the exploits occur and the HTML ismore identifiable WordPress core on the other hand canbe heavily altered by the use of themes and the userrsquos ownchanges However as evidenced by our investigation the vastmajority of exploits occur in plugins

Next we reproduced the exploit in the CVE and weanalyzed the vulnerable page and wrote a signature to patchthe exploit

B Results

Plugin InstallationsWooCommerce 5+ million

Duplicator 1+ millionLoginizer 900000+

WP Statistics 500000+Caldera Forms 200000+

TABLE I Most popular studied WordPress plugins

Of the initial 100 CVEs we were able to analyze 76 across44 affected pages We dropped 24 CVEs due to reproducibilityissues some of the descriptions did not include a PoC makingit difficult for us to reproduce or the plugin code was nolonger available In some cases it had been removed fromthe WordPress repository due to rdquosecurity issuesrdquo whichemphasizes the importance of being able to defend againstthese attacks

The resulting plugins we studied averaged 489927 instal-lations Table I shows the number of installations for the 5

7

most popular plugins we studied For the vulnerabilities 27(355) could be exploited by an unauthenticated user 56(737) targeted a high-privilege user as the victim 7 (92)had a low-privilege user as the victim the rest affected usersof all types

Many of the studied CVEs included attacks for which thereare known and widely deployed defenses For example manywere cases of Reflected XSS where the URL revealed theexistence of an attack eg http〈target〉amppage-uri=〈script〉alert(rdquoXSSrdquo)〈script〉 While Chromersquos built-in XSS auditorblocked this request Firefox did not and so we still wrotesignatures for such attacks2

We wrote 59 WordPress signatures in total which got rid ofthe PoC exploit when sanitized with one of our three methodsNote that while a PoC is often the most simple form ofan attack our sanitization methods can get rid of complexinjections as well We were able to include several CVEsin some PoCs because they occurred in the same page andaffected the same plugin Overall these signatures represent71 (934) signed CVEs The 5 we were not able to sign weredue to lack of identifiers in the HTML which would result inpotentially large chunks of the document being replaced3

After manual testing the majority of the 71 signaturesmaintained the same layout and core functionality of thewebpage However 12 signatures caused some elements tobe rearranged One caused a table showing user informationto render as blank Most of the responsibility of maintainingfunctionality is left to the signature developer We found thatbeing precise is key to retaining functionality Furthermoreeven if the layout of the page is affected we believe thatapplying the signature is preferable to allowing an exploitAnd unlike the complete blocking approach commonly usedby malware detection software our approach allows the userto access the page

While our goal is to retain as much information of the pageas possible after sanitization we believe that even if a part ofthe page becomes unusable this does not impact the userrsquosexperience as much since many of the exploits occur in smallsections of the HTML A usability study is out of scope forthis paper and we leave it to future work

C Generalizability beyond WordPress

To test the generalizability of our approach to other frame-works we analyzed 5 additional CVEs 2 related to Joomla2 for LimeSurvey and 1 for Bolt CMS We chose Joomlabecause it is another popular CMS Unfortunately we onlyfound 2 CVEs that we were able to reproduce as the softwarefor its extensions is often not available For fairness we lookedfor the most recent CVEs we could reproduce listed in theExploit Database [37] since these have recorded PoCs Wecarried out the same procedure as with the WordPress CVEs

2In practice we found several cases where even XSS auditor did not blocka reflected XSS

3In these cases the signature developer can weigh the trade-offs and decidewhether the added cost is worth it

and were able to patch all of the 5 exploits This brought ourCVE coverage rate up to 938

D Signature writing times

Figure 5 plots a histogram of the times it took one ofthe authors to compose each of the signatures Each timemeasurement includes the time it took to check the HTMLinjection points write the signature and to debug it We do notinclude the time taken to discover and carry out an exploit aswe assume a vulnerability has been discovered already Themedian time is 389 minutes and the standard deviation is 418minutes 72 of signatures were written in under 5 minutesWe believe this to be a reasonable amount of time consideringthe security granted by our extension

The signature which took the longest time to write (25minutes) corresponds to an exploit with 12 HTML injectionpoints Additionally testing this signature proved difficultas some of the injections were a result of a script insertingelements in the DOM after the page had loaded This causedthe initial HTML to look innocuous but with exploits stilloccurring after sanitization As this script was part of the initialrequest we eventually got to the root of the problem Webelieve a more experienced exploit analyst might be able todetect this kind of behaviour more easily

5 10 15 20 25Time taken (minutes)

0

5

10

15

20

Sign

atur

es

Fig 5 Histogram of time taken to write signatures

VI LOAD TIME PERFORMANCE ON TOP WEBSITES

XSnarersquos performance goal is to provide its security guar-antees without impacting the userrsquos browsing experience Wenow briefly report XSnarersquos impact on top website load timesrepresenting the expected behaviour of a userrsquos average webbrowsing experience

In our setup we used a headless version of Firefox 690and Selenium WebDriver for NodeJS with GeckoDriver Allexperiments were run on one machine with an Intel XeonCPU E5-2407 240GHz processor 32 GB DRAM and ouruniversityrsquos 1GiB connection

In our tests we used the top 500 websites as reportedby Mozcom [38] For each website we loaded it 25 times(with a 25 second timeout) and recorded the following valuesrequestStart responseEnd domComplete and decodedBody-Size From the initial set of 500 we only report values for441 the other 59 had consistent issues with timeouts insecure

8

certificates and network errors We believe these to have beencaused by the Selenium web driver as our extension runs aftera response has been delivered to the browser We manuallyloaded each page on a personal computer with our extensionrunning successfully and were not able to reproduce the issues

We ran four test suites No extension cold cache Firefoxis loaded without the extension installed and the web driveris re-instantiated for every page load Extension cold cacheAs before but Firefox is loaded with the extension installedNo extension warm cache Firefox is loaded without theextension installed and the same web driver is used for thepagersquos 25 loads Extension warm cache As before butFirefox is launched with the extension installed

For each set of tests we reduced the recorded values to twocomparisons network filter (responseEnd - requestStart) andpage ready (domComplete - responseStart) The first analyzesthe time spent by the network filter while the second deter-mines the time spent until the whole document has loadedWe calculate the medians for each website for each of thesemeasures as well as the decodedByteSize

40 20 0 20 40Percentage slowdown

00

02

04

06

08

10

Perc

enta

ge o

f site

s

cold network filtercold page readywarm network filterwarm page readyx=[-1010]

Fig 6 Cumulative distribution of relative percentage slow-down with extension installed for top sites

We compare the load times withwithout the extension bycalculating the relative slowdown with the extension installedaccording to the following formula

100 lowast xwith minus xwithout

xwithout

where x is the median withwithout the extension runningFigure 6 plots the results We can see a slowdown of less

than 10 for 726 of sites and less than 50 for 82 ofsites when the extension is running Note that these values arerecorded as percentages and while some are as high as 50the absolute values are in 77 of cases less than a second Thisoverhead should not alter the userrsquos experience significantly

The slowdown increases by at most 5 when we takecaching into account This is likely because the network filtercauses the browser to use less caching especially for theDOM component as it might have to process it from scratchevery time While it may seem counter-intuitive that somepages have shorter loading times with the extension there areseveral variables at play that can affect these measurements

(local network server-side load internal scheduling etc) Wemanually checked the websites for which values were higherthan |40| and verified that our extension did not change thepagersquos contents a possible cause of faster load times We alsochecked the timings for the page as reported by the browserand noted a high variance even within small time windowsThe time spent by our verification function was less than 10msfor 876 of sites (Figure 7) This corroborates our findingsthat the slowdown is mostly negligible

0 40 80 120 160Length (thousands of characters)

0

10

20

30

40

Verif

icatio

n tim

e (m

s) trend line (no probes)trend line (probes)trend line (overall)verification time (no probes)verification time (probes)

Fig 7 Scatter plot of network filter time as a function ofcharacter length for top sites

Figure 7 shows the time spent by the call to our stringverification function in the network filter as a function ofthe length of the string to be verified differentiating betweenwebsites for which some probes tested positive and ones whichno probes did We applied least squares regression to calculatethe shown trend lines Since both our probes and signaturesuse regex matching we expect both trend lines to be linearas seen in the graph We expect the slope of the line to behigher when a probe passes as it performs additional stringverification Around 374 of all web sites use frameworkscovered by our probes [31] thus we expect the impact ofour network filter to be closer to the non-probe values ascorroborated by our overall trend line

False positives on the Web For each website we recordedthe number of loaded signatures We report a 0 FP ratefor these Thus we can infer with confidence that the rateof falsely loaded signatures during an average userrsquos webbrowsing is similarly low This rate could possibly go up aswe cover more frameworks Since many of these pages are notrunning WordPress and are very popular and more prone tofixing their vulnerabilities the rate of false negatives is likelyextremely low as well

Scalability with signatures We tested our system with alarge number of signatures We added 15500 signatures toour database and recorded the time spent by the networkfilter to process these sites4 These were crafted so that theextension would check each one against the loaded siteswithout triggering the injection search and sanitization Thuswe effectively forced our extension to test each site against15500 signatures The mean time spent by the filtering processwas 1930ms with less than 2000ms for 88 of the sites Inpractice we expect a smaller filter time as many frameworks

4There are 15303 CVEs related to XSS in CVE Details [39]

9

would have many signatures For example there are currently200+ CVEs listed for WordPress core and its plugins

VII LIMITATIONS AND FUTURE WORK

Generalizability and scope of study As discussed inSection V-A while many websites share similar structuresto the ones we covered our study only considered 4 othersites apart from those running on WordPress and we onlyconsidered sites using a CMS Not all websites might beidentified as easily Furthermore we only studied 81 CVEsIn the future we intend to study a more diverse set of CVEsand go beyond CMS-based sites

False positives and false negatives It is extremely hard toget completely rid of FPs If the sanitization targets JavaScriptcode for example a FP will likely be triggered Furthermoresince we rely on handwritten signatures vulnerable sites forwhich no signature has been written will be subject to FNsIn the future we intend to study the rate of FPs and FNs inour approach and compare it to previous work

Protection against CSRF We believe that we can adapt ourwork to defend against Cross-Site Request Forgery (CSRF)exploits as well Using a similar signature language as theone for XSS a signature developer could specify pages withpotential vulnerabilities to only allow network requests thatcannot exploit such vulnerabilities

Filtering network data Our filterrsquos design depends onFirefoxrsquos implementation of the WebRequest API FirefoxrsquosfilterResponseData method allows the extension to modify anincoming HTTP request5 This feature has been requested inother browsers like Chrome but it has not been implementedThis design limits our deployability to Firefox users

Design considerations Currently each browser user has toinstall our extension However the same functionality couldbe offloaded to a single processing unit similar to a proxywhich can handle the filtering for all machines in a networkThis deployment model might be more appropriate in certainenvironments such as in enterprises

VIII RELATED WORK

We classify existing work into several categories client-side server-side browser built-in and hybrid a combinationof theseServer-side techniques In addition to existing parametersanitization techniques taint-tracking has been proposed asa means to consolidate sanitization of vulnerable parametersand identify vulnerabilities automatically [2] [16] [17] [18][19] [40] These techniques are complementary to ours andprovide an additional line of defence against XSS

There has also been work on other server-side analysisapproaches to find bugs security vulnerabilities in web ap-plications [41] [42] [43] However these do not target XSSspecificallyClient-side techniques DOMPurify [7] presents a robust XSSclient-side filter The authors argue that the DOM is the ideal

5httpsdevelopermozillaorgen-USdocsMozillaAdd-onsWebExtensionsAPIwebRequestfilterResponseData

place for sanitization to occur While we agree with this viewthis work relies on application developers to adopt the filterand modify their code to use it We have partly automated thisstep by including it as our default sanitization function

Jim et al [3] present a method to defend against injectionattacks through Browser-Enforced Embedded Policies Thisapproach is similar to ours as the policies specify prohibitedscript execution points Similarly Hallaraker and Vigna [23]use a policy language to detect malicious code on the client-side Like XSnare they make use of signatures to protectagainst known types of exploits However unlike our ap-proach their signatures are not application-specific and thereis no model for signature maintenance

Snyder et al [10] report a study in which they disableseveral JavaScript APIs and test the number of websites thatare do not work without the full functionality of the APIsThis approach increases security due to vulnerabilities presentin several JavaScript APIs however we believe disabling APIfunctionality should only be used as a last resort

Additionally client-side taint tracking through the use ofstatic and dynamic analysis has also been applied as a meansto detect XSS either at the browser level or at the extensionlevel [44] [45]Browser built-in defences Browsers are equipped with sev-eral built-in defences We previously described XSS Auditorin Section I another important one is the Content SecurityPolicy (CSP) [46] It has been widely adopted and in manycases provides developers with a reliable way to protect againstXSS and CSRF attacks However CSP requires the developerto identify which scripts might be malicious Previous workhas also highlighted the need for further built-in defences [47]Client and server hybrids XSS-Dec [6] uses a proxy whichkeeps track of an encrypted version of the serverrsquos sourcefiles and applies this information to derive exploits in a pagevisited by the user This approach is similar to ours since weassume previous knowledge of the clean HTML documentFurthermore they use anomaly-based and signature-baseddetection to prevent attacks In a way our system offloadsall this functionality to the client-side without the need forany server-side information

IX CONCLUSION

Users cannot depend on administrators to patch vulnerableserver-side software or for developers to adopt best practicesto mitigate XSS vulnerabilities Instead users should protectthemselves with a client-side solution In this paper we de-scribed the design implementation and evaluation of XSnareone such client-side approach XSnare prevents XSS exploitsby using a database of exploit signatures and by using a novelmechanism to detect XSS exploits in a browser extension Weevaluated XSnare through a study of 81 CVEs in which weshowed that it defends against 938 of the exploits

ACKNOWLEDGMENT

We would like to thank Dr William Aiello who providedcrucial expert advice and insight in the early stages of theproject We miss him dearly

10

REFERENCES

[1] I Muscat (2017 jun) Acunetix vulnerability test-ing report 2017 httpswwwacunetixcomblogarticlesacunetix-vulnerability-testing-report-2017

[2] G Wassermann and Z Su ldquoStatic detection of cross-site scriptingvulnerabilitiesrdquo in Proceedings of the 30th International Conferenceon Software Engineering ser ICSE rsquo08 New York NY USAAssociation for Computing Machinery 2008 p 171ndash180 [Online]Available httpsdoiorg10114513680881368112

[3] T Jim N Swamy and M Hicks ldquoDefeating script injection attackswith browser-enforced embedded policiesrdquo in Proceedings of the16th International Conference on World Wide Web ser WWW rsquo07New York NY USA ACM 2007 pp 601ndash610 [Online] Availablehttpdoiacmorg10114512425721242654

[4] Y Nadji P Saxena and D Song ldquoDocument structure integrity Arobust basis for cross-site scripting defenserdquo in NDSS vol 20 2009

[5] P Wurzinger C Platzer C Ludl E Kirda and C Kruegel ldquoSwapMitigating xss attacks using a reverse proxyrdquo in Proceedings of the2009 ICSE Workshop on Software Engineering for Secure Systems serIWSESS rsquo09 Washington DC USA IEEE Computer Society 2009pp 33ndash39 [Online] Available httpdxdoiorg101109IWSESS20095068456

[6] S Sundareswaran and A C Squicciarini ldquoXss-dec A hybrid solutionto mitigate cross-site scripting attacksrdquo in Proceedings of the 26thAnnual IFIP WG 113 Conference on Data and Applications Securityand Privacy ser DBSecrsquo12 Berlin Heidelberg Springer-Verlag2012 pp 223ndash238 [Online] Available httpdxdoiorg101007978-3-642-31540-4 17

[7] M Heiderich C Spath and J Schwenk ldquoDompurify Client-sideprotection against xss and markup injectionrdquo in Computer Security ndashESORICS 2017 S N Foley D Gollmann and E Snekkenes EdsCham Springer International Publishing 2017 pp 116ndash134

[8] Noscript homepage httpsnoscriptnet[9] B Stock M Johns M Steffens and M Backes ldquoHow the web

tangled itself Uncovering the history of client-side web (in)securityrdquo inProceedings of the 26th USENIX Conference on Security Symposiumser SECrsquo17 Berkeley CA USA USENIX Association 2017pp 971ndash987 [Online] Available httpdlacmorgcitationcfmid=32411893241265

[10] P Snyder C Taylor and C Kanich ldquoMost websites donrsquotneed to vibrate A cost-benefit approach to improving browsersecurityrdquo in Proceedings of the 2017 ACM SIGSAC Conferenceon Computer and Communications Security ser CCS rsquo17 NewYork NY USA ACM 2017 pp 179ndash194 [Online] Availablehttpdoiacmorg10114531339563133966

[11] (2016) Hacked website report 2016q3 httpssucurinetreportsSucuri-Hacked-Website-Report-2016Q3pdf

[12] (2019) Statistics show why wordpress is a popular hacker tar-get httpswwwwpwhitesecuritycomstatistics-70-percent-wordpress-installations-vulnerable

[13] (2019) Xss auditor httpswwwchromiumorgdevelopersdesign-documentsxss-auditor

[14] (2019) Intent to deprecate and remove Xssauditor httpsgroupsgooglecomachromiumorgforummsgblink-devTuYw-EZhO9gblGViehIAwAJ

[15] B Stock S Lekies T Mueller P Spiegel and M Johns ldquoPrecise client-side protection against dom-based cross-site scriptingrdquo in Proceedingsof the 23rd USENIX Conference on Security Symposium ser SECrsquo14Berkeley CA USA USENIX Association 2014 pp 655ndash670[Online] Available httpdlacmorgcitationcfmid=26712252671267

[16] W Xu S Bhatkar and R Sekar ldquoTaint-enhanced policy enforcementA practical approach to defeat a wide range of attacksrdquo in Proceedingsof the 15th Conference on USENIX Security Symposium - Volume 15ser USENIX-SSrsquo06 Berkeley CA USA USENIX Association 2006[Online] Available httpdlacmorgcitationcfmid=12673361267345

[17] A Nguyen-Tuong S Guarnieri D Greene J Shirley and D EvansldquoAutomatically hardening web applications using precise taintingrdquo inSecurity and Privacy in the Age of Ubiquitous Computing IFIP TC1120th International Conference on Information Security (SEC 2005) May30 - June 1 2005 Chiba Japan 2005 pp 295ndash308

[18] T Pietraszek and C V Berghe ldquoDefending against injection attacksthrough context-sensitive string evaluationrdquo in Proceedings of the 8thInternational Conference on Recent Advances in Intrusion Detection

ser RAIDrsquo05 Berlin Heidelberg Springer-Verlag 2006 pp 124ndash145[Online] Available httpdxdoiorg10100711663812 7

[19] P Bisht and V N Venkatakrishnan ldquoXss-guard Precise dynamicprevention of cross-site scripting attacksrdquo in Proceedings of the 5thInternational Conference on Detection of Intrusions and Malwareand Vulnerability Assessment ser DIMVA rsquo08 Berlin HeidelbergSpringer-Verlag 2008 pp 23ndash43 [Online] Available httpdxdoiorg101007978-3-540-70542-0 2

[20] (2018) Security report for in-production web applicationshttpswwwrapid7comresourcessecurity-report-for-in-production-web-applications

[21] M Steffens C Rossow M Johns and B Stock ldquoDonrsquot trust the localsInvestigating the prevalence of persistent client-side cross-site scriptingin the wildrdquo in 26th Annual Network and Distributed System SecuritySymposium NDSS 2019 San Diego California USA February 24-272019 2019

[22] E Kirda N Jovanovic C Kruegel and G Vigna ldquoClient-side cross-sitescripting protectionrdquo Comput Secur vol 28 no 7 pp 592ndash604 Oct2009 [Online] Available httpdxdoiorg101016jcose200904008

[23] O Hallaraker and G Vigna ldquoDetecting malicious javascript code inmozillardquo in Proceedings of the 10th IEEE International Conferenceon Engineering of Complex Computer Systems ser ICECCS rsquo05Washington DC USA IEEE Computer Society 2005 pp 85ndash94[Online] Available httpdxdoiorg101109ICECCS200535

[24] (2018) Wordpress plugin responsive cookie consent 17 16 15- (authenticated) persistent cross-site scripting httpswwwexploit-dbcomexploits44563

[25] (2019) Responsive cookie consent 18 patches httpspluginstracwordpressorgbrowserresponsive-cookie-consenttags18includesadmin-pagephp

[26] (2018 aug) How does adblock work httpshelpgetadblockcomsupportsolutionsarticles6000087914-how-does-adblock-work-

[27] (2019) Safely inserting external content into a page httpsdevelopermozillaorgen-USdocsMozillaAdd-onsWebExtensionsSafely inserting external content into a page

[28] (2019) nmap network mapper httpsnmaporg[29] C-P Bezemer A Mesbah and A van Deursen ldquoAutomated security

testing of web widget interactionsrdquo in Proceedings of the 7thJoint Meeting of the European Software Engineering Conference andthe ACM SIGSOFT Symposium on The Foundations of SoftwareEngineering ser ESECFSE rsquo09 New York NY USA Associationfor Computing Machinery 2009 p 81ndash90 [Online] Availablehttpsdoiorg10114515956961595711

[30] (2019) Wordpress plugin responsive cookie consent 17 16 15- (authenticated) persistent cross-site scripting httpswwwexploit-dbcomexploits44563

[31] (2019) Usage of content management systems for websites httpsw3techscomtechnologiesoverviewcontent managementall

[32] P Kocher D Genkin D Gruss W Haas M Hamburg M LippS Mangard T Prescher M Schwarz and Y Yarom ldquoSpectre attacksExploiting speculative executionrdquo CoRR vol abs180101203 2018[Online] Available httparxivorgabs180101203

[33] (2019) Wordpress Plugins httpswordpressorgplugins[34] (2019) Wordpress cves httpscvemitreorgcgi-bincvekeycgi

keyword=wordpress[35] (2019) Wpscan httpswpscanorg[36] (2019) Wordpress Vulnerability statistics httpswwwcvedetailscom

product4096Wordpress-Wordpresshtmlvendor id=2337[37] (2019) Exploit database httpswwwexploit-dbcom[38] Moz top 500 websites httpsmozcomtop500[39] (2020) Cve details vulnerabilities by type httpswwwcvedetailscom

vulnerabilities-by-typesphp[40] A Kieyzun P J Guo K Jayaraman and M D Ernst ldquoAutomatic

creation of sql injection and cross-site scripting attacksrdquo in 2009 IEEE31st International Conference on Software Engineering 2009 pp 199ndash209

[41] G Wassermann D Yu A Chander D Dhurjati H Inamura andZ Su ldquoDynamic test input generation for web applicationsrdquo inProceedings of the 2008 International Symposium on Software Testingand Analysis ser ISSTA rsquo08 New York NY USA Associationfor Computing Machinery 2008 p 249ndash260 [Online] Availablehttpsdoiorg10114513906301390661

[42] S Artzi A Kiezun J Dolby F Tip D Dig A Paradkar and M DErnst ldquoFinding bugs in web applications using dynamic test generation

11

and explicit-state model checkingrdquo IEEE Transactions on SoftwareEngineering vol 36 no 4 pp 474ndash494 2010

[43] X Xiao A Paradkar S Thummalapenta and T Xie ldquoAutomatedextraction of security policies from natural-language softwaredocumentsrdquo in Proceedings of the ACM SIGSOFT 20th InternationalSymposium on the Foundations of Software Engineering ser FSE rsquo12New York NY USA Association for Computing Machinery 2012[Online] Available httpsdoiorg10114523935962393608

[44] J Pan and X Mao ldquoDetecting dom-sourced cross-site scripting inbrowser extensionsrdquo in 2017 IEEE International Conference on SoftwareMaintenance and Evolution (ICSME) 2017 pp 24ndash34

[45] F Sun L Xu and Z Su ldquoClient-side detection of xss worms bymonitoring payload propagationrdquo in Computer Security ndash ESORICS2009 M Backes and P Ning Eds Berlin Heidelberg Springer BerlinHeidelberg 2009 pp 539ndash554

[46] (2019) Same-origin policy httpsdevelopermozillaorgen-USdocsWebSecuritySame-origin policy

[47] E Abgrall Y L Traon S Gombault and M Monperrus ldquoEmpiricalinvestigation of the web browser attack surface under cross-site scriptingAn urgent need for systematic security regression testingrdquo in 2014 IEEESeventh International Conference on Software Testing Verification andValidation Workshops 2014 pp 34ndash41

12