Over 100 Bugs in a Row: Security Analysis of the Top-Rated Joomla Extensions
Marcus Niemietz, Mario Korth, Christian Mainka, Juraj Somorovsky
OOver 100 Bugs in a Row:Security Analysis of the Top-Rated Joomla Extensions
Marcus Niemietz, Mario Korth, Christian Mainka, Juraj Somorovsky fi[email protected] GmbH
Abstract
Nearly every second website is using a Content Manage-ment System (CMS) such as WordPress, Drupal, and Joomla.These systems help to create and modify digital data, typicallywithin a collaborative environment. One common feature is toenrich their functionality by using extensions. Popular exten-sions allow developers to easily include payment gateways,backup tools, and social media components.Due to the extended functionality, it is not surprising thatsuch an expansion of complexity implies a bigger attack sur-face. In contrast to CMS core systems, extensions are usu-ally not considered during public security audits. However,a Cross-Site Scripting (XSS) or SQL injection (SQLi) at-tack within an activated extension has the same effect onthe security of a CMS as the same issue within the core it-self. Therefore, vulnerabilities within extensions are a veryattractive tool for malicious parties.We study the security of CMS extensions using the exam-ple Joomla; one of the most popular systems. We discoveredthat nearly every second installation of such a system alsoincludes Joomla’s official top-10 rated extensions as a per serequirement. Moreover, we have detected that every singleextension of the official top-10 rated extensions is vulnerableto XSS and 30% of them against SQLi. We show that ourfindings are not only relevant to Joomla; two of the analyzedextensions are available within systems like WordPress orDrupal, and introduce the same vulnerabilities. Finally, wepinpoint mitigation strategies that can be realized within ex-tensions to achieve the same security level as the core CMS.
More than half of the Alexa top-1 million websites are usinga CMS [31]. Among these systems, WordPress, Joomla, andDrupal are the most popular brands with a combined CMSmarket share of over 69%. It is therefore an important task toanalyze their security.These CMSs are frequently audited by third parties dueto their importance, especially widely deployed software like WordPress and Joomla. There exists a family of toolswhich, inter alia, allow researchers and penetration testers toscan CMS software (e.g., WPScan [4], JoomScan [10]) forwell-known issues. Although community-based projects likeJoomla make use of tools like static source code scanners, itseems to be a non-trivial task to detect well-known vulnerabil-ities such as XSS and SQLi, as shown by security researchesmultiple times [29]. To provide an example, Joomla intro-duced the usage of the code analysis tool RIPS in June 2018[7, 16]. Although RIPS is explicitly designed to detect webvulnerabilities like XSS, Joomla has officially announced 30security vulnerabilities within the first half year of 2019, and12 of them were XSS issues [17].
On the Importance of CMS Extensions.
Nearly everyCMS includes multiple extensions which add new function-ality to the core systems. However, the CMS extensions alsoenlarges the attack surface. As an important aspect, the coreof the CMS and the extension share the same privileges. Dueto the missing isolation, a vulnerability in a popular extensionmight have the same impact as a vulnerability within the CMSitself.Despite their security importance, CMS extensions are, incontrast to the CMS core systems, usually not covered bypublic security audits. To highlight this gap, we analyzed thesecurity of extensions from one of the most popular systemscalled Joomla.
Our Approach.
Due to the high number of nearly 8,500Joomla extensions, we restricted our focus to the top-10 ratedand freely available extensions within Joomla’s official ex-tension directory. Moreover, we concentrated on the two top-rated Open Web Application Security Project (OWASP) in-jection risks namely XSS and SQLi. Our aim is to answer thefollowing research questions:1. How many Joomla installations have deployed the top-10 rated extensions among the Alexa top-1 million web-sites?2. Are Joomla extensions vulnerable to the well-knownattacks XSS and SQLi? If so, what is the root cause of1 a r X i v : . [ c s . CR ] F e b uch security issues and what can we learn from them?3. Can we assume that at least one top-rated and maybevulnerable extension is always activated within Joomlainstallations? If so, does a vulnerability within an exten-sion have the same importance as a vulnerability withinthe CMS core?If extensions are a tool which is always available and acti-vated within a CMS, this would imply that we should alwaysconsider extensions with the same priority as the CMS core.Otherwise, an extension might be the weakest link of a com-plex chain if it is vulnerable against attacks. Empirical Study.
We detected that all analyzed extensionsare vulnerable to XSS and 30% of them are vulnerable toSQLi. We responsibly reported and disclosed 103 vulnerabili-ties across multiple CMS’s whereas 86 vulnerabilities werewithin Joomla extensions. By investigating extensions whichshare the same code and, therefore, the same vulnerabilitiesfor multiple CMSs, we identified 11 vulnerabilities withinWordPress extensions and 6 vulnerabilities within Drupalextensions.
Contributions.
Overall, we make the following contribu-tions:• We detected that all of the top-10 rated Joomla exten-sions are vulnerable to XSS and 30% of them are vulner-able to SQLi.• We show that 40.9% of the Joomla installations withinthe Alexa top-1 million websites include at least one ofour tested top-rated extensions and are, thus, vulnerableto the discovered attacks.• We developed an open-source tool for detecting XSSvulnerabilities in web applications which use metadatawithin media files.• We identify possible root causes of the detected vulnera-bilities and demonstrate generalizability by evaluatingthat extensions which are available for multiple CMSsalso have the same security vulnerabilities.
Artifact Availability.
In the interest of open science, wehave published our tool Metadata-Attacker as open-sourceonline.
We consider all three XSS variants that are mentionedas OWASP top-10 injection threats as relevant: re-flected XSS, stored XSS, and reflective DOM-based XSS(DOMXSS) [20]. We left out persistent DOMXSS [26], because one of its requirements isto have another XSS to write into the persistent client-side storage. This iscovered by seeking for reflective XSS and DOMXSS.
Reflected Cross-Site Scripting.
The first step of a reflectiveXSS attack is usually to send attack vectors defined by theattacker to the server via an HTTP GET or POST request.After analyzing the server response message, the attackerchecks whether the attacker’s code was (partially) displayedand therefore reflected. If this is not the case, the attacker cantry another testing code; otherwise, the attacker will abort theattack on the given resource.The successfully executed testing code can show charactersthat are necessary for the attack, for example if < or " are notfiltered by the server. In the case of an HTTP GET request,the attacker can then prepare a link pointing to the vulnerableweb application with a malicious JavaScript code embeddedin the query string. In the event of an HTTP POST request, aprepared HTML form can be used, which is auto-submittedas soon as the attack page is loaded. Stored Cross-Site Scripting.
As another server-side vulnera-bility, stored XSS occurs when the attack vector can be storedpersistently in the vulnerable web application (e.g., maliciouscode inside a log file or database). Each time a victim visitsthe part of the web application where the vector is saved, it isexecuted.
DOM-based XSS.
Contrary to reflected and stored XSS, thecause for DOMXSS lies in the browser of the user itself; forexample, client-side JavaScript code provided by the server.This JavaScript code takes some input of the client and atsome point uses it at a sink such as innerHTML . This canresult in the injection of arbitrary HTML or JavaScript codeand therefore XSS.
An SQLi occurs when improperly sanitized user input is usedin the construction of SQL queries. The problem arises usu-ally when the whole query which was constructed by theapplication is submitted to the SQL server instead of thequery with placeholders for the parameters (e.g., preparedstatements [13]). Therefore, the SQL server cannot distin-guish between the input of a trusted and a malicious user; forexample, selecting another database although just an integerwas expected. Hence it simply parses the query and executesit, which in the end can lead to an SQLi if an attacker wasable to insert arbitrary statements.
Our tested CMS called Joomla uses a strict Model-View-Controller (MVC) architecture. Joomla’s extensions can be ei-ther a module, component, plugin, template, or language [18].Beyond the applications base directory, there are commonfolder paths for every Joomla installation and its extensions.Additionally, unless explicitly changed or replaced, eachJoomla installation contains a robots.txt and web.config.txt file which contain identifying strings. Some native com-2onents are delivered with identifying eXtensible MarkupLanguage (XML) files. Hence it is possible to identify aJoomla installation by requesting some of those identifyingfiles.
For identifying Joomla installations and their extensions, weconducted a large-scale analysis of the Alexa top-1 millionto find out how many websites use Joomla as a CMS. In thisregard, we wrote a crawler to detect Joomla installations witha standard core system (cf., Section 4). With our crawler, wedetected 19,047 Joomla installations in total.Based on our results, our remaining task was to determinethe number of extensions within the set of our detected instal-lations. Since there are over 8,400 Joomla extensions avail-able, we restricted our research to freely downloadable andthus non-paid extensions. This criteria fits to 3,981 out of8,457 extensions. Among the set of freely downloadable ex-tensions, we took the top-10 rated extensions – according tothe official Joomla extension directory – as a representativeset for further analysis. After choosing the set of extensions,we concentrated the scope of our security analysis on twomain classes of injection bugs called XSS and SQLi.
Reflected & Persistent Cross-Site Scripting.
We used twoapproaches to detect reflected and stored XSS as server-sidevulnerabilities. First, we automatically identified all user in-puts derived from HTTP GET and POST messages. Wemarked each input as secure in case that special characters(e.g., the less than sign) are represented by HTML entities or aUnicode representation when it is returned within a response.Second, we scanned each extension for outputs that are gen-erated by its views. We marked outputs as secure when theywere wrapped by escape functions such as htmlentities , addslashes , and $this->escape . Every input or outputthat was not marked as secure was inspected manually. Weuse an alert(1) as a proof of concept to verify whether wehave found an XSS issue. DOM-based XSS.
Modern applications like Google’sGSuite allow to completely use complex apps within a webbrowser. To provide such a functionality, an enormous amountof JavaScript code is required. With the shift from desktop-to mobile-based applications, the capabilities of JavaScriptcode has also increased, and in this regard, the probability tocarry out attacks as shown by Lekies et al. [19].In contrast to server-side vulnerabilities, DOMXSS allowsa malicious party to attack a victim on the client-side withoutsending any suspicious HTTP requests to the server; thiscan be realized, for example, by using the hashtag within an XSS attack vector. To detect DOMXSS vulnerabilities,we are using the methodology provided by di Paola [8]. Byreusing the provided regular expressions as search patterns,we looked for sources (e.g., document.location ) and sinks(e.g., document.write ) within the Document Object Model(DOM) that could introduce DOMXSS vulnerabilities. Afterfinding a suspicious sink or source, we move forward bygenerating different inputs and observing if, and how, theyare modified. If we detect the reflection of an input value, welater also evaluated its exploitability.
Many extensions add the functionality of providing, display-ing and editing photos and other multimedia files. Prominentexamples in case of Joomla are Phoca Gallery, Ozio Gallery,and Sigplus. Extensions can use metadata to display imagecaptions or position information and it is thus of high im-portance to verify whether malicious and falsely trusted userinput in media files can be used for XSS attacks. We could notidentify any tool which fulfills our requirements of automati-cally putting XSS payloads within metadata fields. Therefore,we have created a dockerized PHP-based open-source toolcalled
Metadata-Attacker .Metadata is usually created by devices such as cameraswhich store information like GPS coordinates within mediafiles (e.g., jpg ). As an example, one specification for savingmetadata within images is provided by the International PressTelecommunications Council (IPTC). The specification al-lows the saving of data within self-descriptive properties like
City or Country . This data is afterwards used by, for example,photographers to get more information about pictures (e.g.,copyright data and the date of creation).Instead of writing harmless data like IPTC properties withina media file, it is also possible to save arbitrary strings likeXSS vectors in metadata fields. For this reason, we providethe penetration testing tool
Metadata-Attacker , which allowsto create an image ( jpg ), audio ( mp3 ), or video ( mp4 ) filecontaining custom metadata or a set of XSS vectors to testany metadata interpreting application. Therefore, we have thepossibility to test Joomla’s gallery extensions against possibleXSS vulnerabilities when displaying unfiltered meta data (e.g.,for detecting DOMXSS).Metadata-Attacker runs in a web browser and allows theselection of all, or just specific metadata fields that shouldbe modified. To test for XSS vulnerabilities, our tool is ableto automatically fill in – by considering the length limit ofeach property – a collection of over 200 well-established testvectors collected from the OWASP XSS Filter Evasion [21]and HTML5 Security Cheat Sheets [15].3igure 1: Our open-source tool Metadata-Attacker allows usto manipulate metadata of media files like images.
Similarly to reflected and stored XSS, we used two approachesto detect SQLi vulnerabilities. First, we automatically iden-tified all possible inputs derived by HTTP GET and POSTmessages. We marked each input as secure if we cannot causean SQL error or any change to the applications response; wehave set the PHP flag error_reporting to on for debuggingpurposes.Second, we scanned the extension for all SQL queriesthat are constructed with user input and potentially executed.We marked inputs as secure if they were properly escapedupon usage with PHP functions such as $db->quote , $db->quoteName , or intval . As in case of XSS, every input thatwas not marked as secure was inspected manually. To identify the number of security issues, we only count avulnerable parameter or variable once even if it might bereflected multiple times within the source code of a PHP file.We reported all the discovered vulnerabilities to Joomla’sVulnerable Extensions List (VEL) team who forwarded our re-ports to the respective extension developers. Whenever it wasexplicitly requested, we worked closely with the developersto verify the correctness of their patches.
Among the Alexa top-1 million, some hosts were offline andthus not reachable. Therefore, we successfully crawled 93.2%of the Alexa top-1 million.During our scan for Joomla installations, we observed thatsome websites do not host Joomla within the standard rootdirectory. Therefore, we also tried to discover the path of theirinstallation. Whenever we could not detect an installation within the base directory, we sent a baseline request and fol-lowed all redirects. Afterwards, we extracted the path of thefinal destination and prepended it to our test paths. Addition-ally, we detected that some websites behave very differentlyif the user agent doesn’t belong to a browser. Therefore, weused the user agent of Google Chrome 74 for our script. Toaccommodate for network latency we set timeouts as highas ten seconds for a connection and 20 seconds for reading,while allowing up to ten retries in total.All together, our crawler detected that over 2% of thereachable Alexa websites use Joomla. Popular examplesfor websites with an active Joomla installation are the Na-tional University of Singapore ( nus . edu . sg ), the Govern-ment of India ( uidai . gov . in ), and the Canadian Immigration( canadavisa . com ). In order to detect if an extension was installed within a de-fault setup of Joomla, we verified the existence of specificstatic files within predictable installation paths (cf., Table 1).For every extension except Sigplus, we scanned for an ex-tension specific file (e.g., manifest.xml ) within the path /administrator/components/[identifier] ; the identi-fier was replaced with the component’s name listed in Table 1.Every file contains strings with content – such as the exten-sion’s name – with which we were able to clearly fingerprinteach extension.Sigplus is not a component and therefore, we had to ver-ify the availability of the JavaScript file initialization.js within the path /media/sigplus/js/ . Analogously toour fingerprinting approach for components, the detectedJavaScript file also contains unique strings to identify theextension.In total, we detected 7,797 Joomla installations with exten-sions. As listed in Table 1, the most popular extension AkeebaBackup was included in 4,646 detected installations; it is thusavailable in nearly 59.6% of our scanned Joomla installations.AcyMailing is the second most popular extension with a mar-ket share of 34.4% within our tested installations. Amongthe top-10 rated extensions, Ozio Gallery and Sigplus are themost unpopular extensions with an availability of less than2%.Our results also show that the top-10 rated extensions arenot equal to the top-10 of the most popular extensions. Joomladoes not collect data about the number of installation andtherefore, there is no official list about the most popular ex-tensions.
As displayed in Table 1, our evaluation revealed that we canidentify XSS vulnerabilities in every single extension. In mostof the cases, our methodology allowed us to find reflected XSS4oomla! Extension Identifying Path Installations rXSS sXSS DOMXSS SQLiAkeeba Backup com_akeeba com_acymailing com_advancedmodules com_jevents com_extplorer com_phocagallery com_comprofiler com_arkeditor com_oziogallery3 /media/sigplus boxplus and slide-plus , which are shipped with Sigplus, are also affected.Over 44% of our discovered XSS vulnerabilities can beused to attack a victim which does not have any special privi-leges. Our detected SQLi vulnerabilities can be only exploitedwith an account which has administrative privileges. For ex-ample, ArkEditor’s SQLi vulnerability can be only used inthe event that the attacker can edit plugins; AcyMailing’sSQLi vulnerability requires access to the statistics page of theAcyMailing management interface.
Case
Reflected XSS in JEvents
This vulnerability within JEvents was detected with oursecond approach to discover reflected and stored XSS.We first discovered the following potentially vulner-able code within the component file form_body.php . Due to the reason that the parameter $this->keyword is echoed directly without any escaping mecha-nism, we further investigated its origin. Our investigation ledus to the components controller file ( search.php ) in whichthe code displayed in Listing 1 is used to process the inputparameter keyword .At the beginning of Listing 1, the request parameter keyword is saved in the variable $keyword . Thereafter, ifthe input is longer than the predefined maximum length of 20characters, it is truncated to a length of 20 characters. How- ever, instead of using the already truncated value, JEvents usesthe original input value combined with a protection againstSQLi vulnerabilities ( db-escape , cf. line 6).The originally truncated value is therefore overwritten.Most importantly, the escaping is applied for a database con-text instead for an HTML attribute context. Finally, the valuethat is escaped in order to avoid SQLi is assigned to the viewwithout any truncation.As an exploitation example, a malicious URI including /index.php/searchjevents?keyword=XSS" onfocus=alert(1) autofocus= could be used to trigger an XSSpayload; we break out of the attribute context with a double-quote sign and automatically execute arbitrary JavaScriptcode by triggering the event handler onfocus . Based onthe privileges of the attacked user, it is possible to attackthe complete Joomla installation as Joomla’s frontend andbackend reside on the same origin (e.g., to get administrationprivileges). $keyword = $jinput -> getString (’keyword ’, ’’); $upper_limit = 20; if (JString :: strlen($keyword) > $upper_limit ) { $keyword = JString :: substr($keyword , 0,$upper_limit - 1); } $keyword = $db ->escape($jinput -> getString (’keyword’, ’’)); [...] $this ->view ->assign("keyword",$keyword); Listing 1: Vulnerable processing of the parameter keyword .The code is protecting the user against SQLi attacks and notagainst attacks in the HTML context.
Case
Persistent XSS in Ark Editor
The first approach of our methodology allowed us to identifya stored XSS vulnerability in Ark Editor by testing all inputsthat we could observe. In general, Ark Editor provides thefunctionality of modifying content directly on a Joomla page5y allowing front-end inline editing. Whenever an article isedited with Ark Editor’s editing tool, an AJAX request is sentto the back-end. This HTTP request includes the parameter data[articletext] , which contains the Base64 encodedcontent of the whole article.The intended behaviour of Ark Editor is to let the user of theeditor modify content, which is always encoded with HTMLentities; therefore, greater and lesser than signs that are, forexample, required to inject an HTML element like string. As a result, an alert-window is always displayed when the article is shown to auser.Usually the default text filter is applied in Joomla, whichdoes not allow any user besides the super user to includeunsafe HTML in an article. However, Ark Editor’s securityonly relied on the client-side escaping of special characterswithin the front-end editor itself. Moreover, Ark Editor didnot implement any CSRF protections in this case, leading toa by Ark Editor self-scored high risk
XSS vulnerability [9].
Case
DOMXSS in Sigplus
With the help of our tool Metadata-Attacker, we ware able todetect DOMXSS vulnerabilities within the photo and multi-media gallery Sigplus.We used Metadata-Attacker to create a sample image con-taining an XSS payload in every metadata field. Afterwards,we uploaded the image to the gallery and, thereafter, openedit in a web browser. With this approach, we are able to trig-ger four XSS vulnerabilities leading to JavaScript-based alertwindows; three of them were DOMXSS and one of themstored XSS issues. One particular case for a DOMXSS is-sue was caused by the combination of Sigplus and, on of theJavaScript libraries it is shipped with, Slideplus.Initially, Sigplus’s backend code extracted some metadatafields from the image (e.g., the image headline) and storedthem in a noscript element; some metadata fields were en-coded with PHP’s htmlentities function. Afterwards, theclient-side initialization script of Sigplus used JavaScript’s innerHTML to set the HTML content of a div element. Fromthere, Slideplus extracted the image headline, which at thispoint was still encoded with htmlentities , and unescapedit. This unescaped value was then used in conjunction with innerHTML , which lead to the XSS vulnerability. Hence animage with the IPTC field number 105 (image headline) set to could be used to cre-ate an alert window; in our example, an image with a not exist-ing resource triggers the error event and executes JavaScriptcode as a proof of concept.
Case
SQLi in JEvents
While following our second approach to discover SQLi, wediscovered the following code in the JEvents library file saveIcalEvent.php (cf., Listing 2).We first detected the SQL query, which uses the apparentlyunsanitized value $ics_id . By backtracing the input array,we discovered that it is only filtered for the HTML contextbut not escaped for the usage in an SQL query; before thisfiltering step the array is directly read from the request. Ouranalysis has, therefore, shown that a request which containsvalid post data to create or edit an event can be used to executean SQLi attack. $ics_id= ArrayHelper :: getValue($array , "ics_id" ,0); [...] $vevent ->catid = ArrayHelper :: getValue($array , "catid" ,0); [...] if (( is_string ($vevent ->catid) && $vevent ->catid<=0) || (is_array($vevent ->catid) && count($vevent ->catid)==0)){ $query = "SELECT catid FROM $db ->setQuery( $query); $vevent ->catid = $db -> loadResult (); Listing 2: By saving an event, an attacker can use POST datamanipulation to trigger an SQLi.As an exploitation example, we can use the query as a value for the parameter ics_id to do an SQLi attack; we add an additional select and extractarbitrary data from the current database. As Joomla uses onlya single database for all operations our injection grants readaccess to the complete installation.
Due to the high number of bugs in Joomla extensions, we alsolooked for extensions that are available for other CMSs, likeDrupal and WordPress. Our analysis has shown that two ex-tensions from our testbed are also available for other systems.First, eXtplorer is comparable to a standalone web-basedfile management component and, thus, also available as aWordPress and Drupal extension. Due to exactly the samesource code, we have the same XSS vulnerabilities on everylarge CMS system which allows developers to include thiscomponent as an extension. Second, Akeeba Backup is alsoavailable for WordPress. Although the source code is modified6o be compatible with WordPress, we could identify that it hasthe same structure and, therefore, the same vulnerabilities.In total, we could derive 17 new XSS vulnerabilities bylooking on eXtplorer and Akeeba Backup.
Although Joomla provides a list of security guidelines withthe official documentation, we detected three different rootcauses for our security issues within the XSS and SQLi area.First, most of the extensions are vulnerable because of miss-ing filtering mechanisms. We could, therefore, assume thatdevelopers might be unaware of our detected security vulner-abilities, or that they have simply forgotten to implement asecurity mechanism. Moreover, Joomla does not provide anyofficial filtering mechanism against DOMXSS attacks.Second, some extensions secure the user’s input and outputby using self-written sanitizers that can be sometimes by-passed. For example, Akeeba Backup explicitly escaped spe-cial characters like the single quote within an inline script element; as a bypass to break out of the JavaScript context,we have injected the closing script element with greater andless than signs that were not escaped.Third, some developers (cf., Listing 1 and 2 for JEvents) areaware of security vulnerabilities but they are protecting theirapplication by misusing security features that are provided byJoomla. For example, JEvents protected the user against SQLialthough the protecting context was actually XSS; therefore,some characters which could be used to break out of theHTML attribute context were not filtered by Joomla.
An approach to secure Joomla’s extension directory couldbe to establish a manual review process to analyze an exten-sion before it is published in the extension store. However,Joomla is an community-based open-source project with lim-ited manpower and thus, it might be more efficient if thisreview process is done automatically on the extension’s code.Since June 2018, Joomla’s code base is continuouslyscanned by the code analysis tool RIPS to detect securityvulnerabilities [16]. In contrast to the core systems, exten-sions are currently not scanned by such code analysis toolsbefore they are published. To achieve the same level of secu-rity, extensions should be scanned by similar tools as well.It is important to note that code analysis tools only detectthe lower bound of the existing vulnerabilities. For example,during our research study we also detected two stored XSSvulnerabilities within the core itself, even though RIPS andNAVEX [2] were previously used as code analysis tools, andhaving a focus on XSS (CVE-2019-6262, CVE-2019-9712).Nonetheless, code analysis tools might help to reduce thenumber of vulnerabilities. Due to our bug reports, we learnedthat in some cases, the reported bugs were only partially fixed. For example, the popular backup extension Akeeba Backuponly fixed two out of three XSS bugs correctly on the firstattempt; one bug was only fixed for HTTP GET requestswhile attacks via HTTP POST were still possible.
Browsers like Google Chrome (GC) and Internet Explorer(IE) introduced XSS prevention tools called XSS filter (IE8) and XSS Auditor (GC 4) [3]. The aim of these tools is todetect XSS attacks within the browser itself. In case of GC,XSS auditor attempts to find reflections during the HTMLparsing phase and therefore it blocks the execution of potentialmalicious code like JavaScript. Researchers have shown thatthese prevention mechanisms could be used as a tool to docross-site information leak attacks and therefore browsersvendors have decided to remove such filters (e.g., in GC 78) [1,14]. Due to the reason that modern browsers like GC are nomore able to detect even simple reflected XSS attacks, thereshould be a special focus on sandboxing mechanisms likeContent Security Policy (CSP) and Trusted Types.Joomla allows the activation of the CSP to primarily miti-gate content injection vulnerabilities such as XSS. Althoughthe core system can be protected with CSP, Joomla extensionsdo not provide a fine granular CSP ruleset. A major challengewould be to automatically verify – when the extension isuploaded to the extension store – CSP rules regarding theirsecurenes. Weichselbaum et al. [32] showed that 99.34% ofthe scanned hosts with a CSP do not offer a benefit againstXSS; inter alia, due to the usage of unsafe -directives. Asa possible verification tool to face this problem, Joomla’sextensions store could make use of Google’s CSP Evaluator. Trusted Types [12, 33] are a new and experimental featurewhich has been proposed to tackle DOMXSS vulnerabilities.This feature can be enabled by using the CSP. The mainidea is to create special JavaScript object types that have tobe assigned to return potential DOMXSS sinks; otherwisethe browser would throw a
TypeError in the event that anuntrusted value is returned. The only way to create thosenew types is by implementing policies which can be definedby using the Trusted Types browser API. While this doesnot automatically prevent DOMXSS, it enforces a check ofsinks (e.g., location.hash ) and makes code audits easier;only the newly defined Trusted Types policies have to bereviewed for security issues. A major drawback is that existinglegacy code needs to be reworked to apply specific policiesfor each use case. However, in order to allow a continuousmigration of legacy code, a default policy can be definedwhich is applied if an untrusted string would be assigned to aninjection sink. Therefore, Trusted Types could be used withina CMS like Joomla while the core, and also the extensions,could be migrated continuously. https://csp-evaluator . withgoogle . com/ Related Work7.1 CMS Security
In 2015, Trunde and Weippl [29] created an analysis basedon publicly available exploits within Wordpress by nearlytaking 200 vulnerabilities into account. As a contribution,they outlined that a combination of manual and static analysismight be the best solution to discover similar vulnerabilities;we used the same approach to discover XSS and SQLi vulner-abilities. Extensions were not within their scope.In 2017, Van Acker et al. [30] evaluated the security oflogin forms by looking on popular web frameworks and CMS(e.g., Joomla, Drupal and WordPress). Their evaluation of theAlexa top-100 thousand showed that the implemented securitymeasures were lacking in numerous cases because HypertextStrict Transport Security (HSTS), HTTP Public Key Pinning(HPKP), Sub-resource Integrity (SRI), and various CSP direc-tives, such as Upgrade-Insecure-Requests (UIR) and Block-All-Mixed-Content (BAMC), were not implemented. Injec-tion attacks such as XSS and SQLi were not considered.
In 2014, Fonseca and Vieira [11] analyzed the security of 35Wordpress extensions using the static code analysis tools php-SAFE and RIPS. They found more than 350 XSS and SQLivulnerabilities and thereby showed that plugins in Wordpresspose a security risk. They argued that prior to its release thesecurity of a plugin should be verified through static codeanalysis by the developers and the core application providers.They neither considered other CMSss, nor detected cross-CMS bugs.In 2016, Con¸tu et al. [6] argued that while CMSs provide alot of flexibility, they also result in more attacks and additionalvulnerabilities through extensions. In addition to common se-curity best practices, they proposed a centralized reportingtool which forwards reports of security vulnerabilities to thecorrect party to reduce the amount of vulnerabilities intro-duced through the usage of a CMS.In 2018, Sosonkin [25] detected a persistent XSS in aJoomla extension using image metadata. He used the exif commandline tool to include the XSS payload within the
Caption-Abstract metadata.In 2019, Cernica et al. [5] evaluated the security of the mostcommon backup plugins for Wordpress. They showed that12 out of 21 investigated extensions leak sensitive data, forexample, by making backups accessible to everyone. Theyconcluded that most backup plugins fail to use proper random-ness and strong cryptographic methods, and therefore end upposing a security risk.In the same year, Ruohonen [24] pointed out that Word-press as the most popular CMS “has had a particularly badtrack record in terms of security”, but in the recent years the security vulnerabilities were more likely to be found in itsplugins. He studied the correlation between the popularity ofa plugin and the amount of reported and disclosed vulnera-bilities, and through an empirical study concluded that thosetwo properties are indeed correlated.
There is a large body of research considering XSS and SQLi.In the following paragraphs, we highlight the prevalence ofthese vulnerabilities by performing systematic scans.In 2013, Lekies et al. [19] evaluated the prevalence ofDOM-based XSS attacks in Alexa top 5,000 websites. Intheir study, they identified over 6,000 unique vulnerabilitiesdistributed over 480 domains. Nearly 10% of the analyzeddomains had at least one DOMXSS issue.In 2015, Parameshwaran et al. [22] introduced the tool
DEXTERJS which uses instrumentation to perform taint anal-ysis on JavaScript code supplied by a target website. Theycrawled the Alexa top 1,000 and, using their tools, found820 distinct zero-day DOMXSS vulnerabilities. The system-atic analysis of DOMXSS has been in the scope of manyadditional researchers (e.g., Steffens et al. [26], Stock et al.[27, 28]).In the same year, Parvez et al. [23] evaluated the abilityof three black-box scanners to find SQLi and XSS. Theyconcluded that the scanners still fail to find all vulnerabilitiesin their testbed.In comparison to all these works, we identified XSS andSQLi vulnerabilities directly in the analyzed Joomla exten-sions. Afterwards, we estimated their impact by scanning forthe frequency of the vulnerable extensions in all Alexa top-1million websites. Our approach allowed us to perform large-scale scans on more websites and responsibly disclose ourvulnerabilities directly to the extension developers, whosefixes had a direct impact on all the analyzed websites.
We presented a security analysis of the top-10 rated Joomlaextensions. We showed the generalizability of detectingcross-platform vulnerabilities on Drupal and WordPress. Ourmethodology allowed us to identify XSS vulnerabilities ineach of the analyzed extensions, and SQLi vulnerabilities in30% of the analyzed extensions. Due to a missing isolationbetween the core system and the installed extensions, thesevulnerabilities had a direct impact on the security of the wholesystem. In total, the detected vulnerabilities affected over 40%of the Alexa top-1 million websites using Joomla.The direct security impact of core extensions shows thathighly-ranked extensions must receive as much attention asthe Joomla core system. Every extension should be critically8eviewed before being published in the official directory. Thisshould be done by dedicated security audits or carefully im-plemented automated security tools.From a scientific point of view, it is also interesting to studythe missing separation between the Joomla core and extensionsystem. New research directions could study the possibilityregarding the separation of both technologies, and developmulti-stage concepts of separating accessible data from theextensions and the core system.Overall, our findings prove that these directions should notonly be followed by Joomla, but additionally, similar tech-niques and research directions should be studied in otherCMSs, such as Drupal and WordPress.
References [1] Issue 968591: Owp launch tracking bug: Deprecate andremove xssauditor. https://bugs . chromium . org/p/chromium/issues/detail?id=968591 , May 2020.[2] Abeer Alhuzali, Rigel Gjomemo, Birhanu Eshete, andV.N. Venkatakrishnan. NAVEX: Precise and scal-able exploit generation for dynamic web applica-tions. In , pages 377–392, Baltimore, MD, 2018.USENIX Association. ISBN 978-1-939133-04-5. URL . usenix . org/conference/usenixsecurity18/presentation/alhuzali .[3] Daniel Bates, Adam Barth, and Collin Jackson. Regularexpressions considered harmful in client-side xss filters.In WWW ’10 , 2010.[4] R. Dewhurst C. Mehlmauer and Erwan. Wpscan a word-press vulnerability scanner. https://wpscan . org/ ,July 2019.[5] I. Cernica, N. Popescu, and B. Tiganoaia. Security eval-uation of wordpress backup plugins. In , pages 312–316, May 2019. doi:10 . . . , pages 277–280, June 2016.doi: 10 . . . , pages 989–1003, San Diego, CA, 2014. USENIXAssociation. ISBN 978-1-931971-15-7. URL . usenix . org/conference/usenixsecurity14/technical-sessions/presentation/dahse . [8] Stefano di Paola. Analysis and identification ofdom based xss issues. . nds . ruhr-uni-bochum . de/media/attachments/files/2012/01/AnalyzingDOMXss_StefanoDiPaola_Bochum . pdf ,January 2012.[9] Ark Editor. Ark 2.6.9 - ark editor security an-nouncement. https://arkextensions . com/blog/582-security-announcement , March 2019.[10] M. R. Espargham. Owasp joomscan project. https://github . com/rezasp/joomscan , April 2019.[11] J. C. C. M. d. Fonseca and M. P. A. Vieira. A practi-cal experience on the impact of plugins in web security.In , pages 21–30, Oct 2014. doi:10 . . . https://wicg . github . io/trusted-types/dist/spec/ , August 2019.[13] The PHP Group. Prepared statements and storedprocedures. . php . net/manual/en/pdo . prepared-statements . php , July 2019.[14] Jessica Haworth. Google deprecates xss auditor forchrom. https://portswigger . net/daily-swig/google-deprecates-xss-auditor-for-chrome ,July 2019.[15] Mario Heiderich. Html5 security cheatsheet. https://html5sec . org/ , August 2019.[16] Joomla! Rips becomes joomla official code analysispartner. https://developer . joomla . org/news/739-rips . html , June 2018.[17] Joomla! Joomla! developer network: Security announce-ments. https://developer . joomla . org/security-centre . html , July 2019.[18] Joomla! Extension types (general def-initions). https://docs . joomla . org/Extension_types_(general_definitions) , July2019.[19] Sebastian Lekies, Ben Stock, and Martin Johns. 25million flows later: Large-scale detection of dom-based xss. In Proceedings of the 2013 ACMSIGSAC Conference on Computer & , CCS ’13, pages 1193–1204, NewYork, NY, USA, 2013. ACM. ISBN 978-1-4503-2477-9. doi: 10 . . http://doi . acm . org/10 . . .920] OWASP. Top 10-2017 a7-cross-site scripting(xss). . owasp . org/index . php/Top_10-2017_A7-Cross-Site_Scripting_(XSS) , July 2019.[21] OWASP. Xss filter evasion cheat sheet. . owasp . org/index . php/XSS_Filter_Evasion_Cheat_Sheet , February2019.[22] Inian Parameshwaran, Enrico Budianto, Shweta Shinde,Hung Dang, Atul Sadhu, and Prateek Saxena. Dex-terjs: Robust testing platform for dom-based xssvulnerabilities. In Proceedings of the 2015 10thJoint Meeting on Foundations of Software Engineer-ing , ESEC/FSE 2015, pages 946–949, New York,NY, USA, 2015. ACM. ISBN 978-1-4503-3675-8. doi: 10 . . http://doi . acm . org/10 . . .[23] M. Parvez, P. Zavarsky, and N. Khoury. Analysisof effectiveness of black-box web application scan-ners in detection of stored sql injection and storedxss vulnerabilities. In , pages 186–191, Dec 2015. doi:10 . . . Pro-ceedings of the Evaluation and Assessment on Soft-ware Engineering , EASE ’19, pages 222–228, NewYork, NY, USA, 2019. ACM. ISBN 978-1-4503-7145-2. doi: 10 . . http://doi . acm . org/10 . . .[25] Mikhail Sosonkin. Persistent xss via imagemetadata. https://debugtrap . com/2018/03/01/joomla_sige_xss/ , March 2018.[26] Marius Steffens, Christian Rossow, Martin Johns, andBen Stock. Don’t trust the locals: Investigating theprevalence of persistent client-side cross-site scriptingin the wild. In . The Internet Society, 2019. ISBN 1-891562-55-X. URL . ndss-symposium . org/ndss2019/ .[27] Ben Stock, Sebastian Lekies, Tobias Mueller, PatrickSpiegel, and Martin Johns. Precise client-side protectionagainst dom-based cross-site scripting. In , pages 655–670, 2014.[28] Ben Stock, Martin Johns, Marius Steffens, and MichaelBackes. How the web tangled itself: Uncovering the his-tory of client-side web (in) security. In { USENIX } Security Symposium ( { USENIX } Security 17) , pages971–987, 2017.[29] Hannes Trunde and Edgar Weippl. Wordpress secu-rity: An analysis based on publicly available exploits.In
Proceedings of the 17th International Conferenceon Information Integration and Web-based Applica-tions & Services , iiWAS ’15, pages 81:1–81:7, NewYork, NY, USA, 2015. ACM. ISBN 978-1-4503-3491-4. doi: 10 . . http://doi . acm . org/10 . . .[30] Steven Van Acker, Daniel Hausknecht, and AndreiSabelfeld. Measuring login webpage security. In Proceedings of the Symposium on Applied Comput-ing , SAC ’17, pages 1753–1760, New York, NY, USA,2017. ACM. ISBN 978-1-4503-4486-9. doi: 10 . . http://doi . acm . org/10 . . .[31] W3Techs. Usage of content management systems. https://w3techs . com/technologies/overview/content_management/all , July 2019.[32] Lukas Weichselbaum, Michele Spagnuolo, SebastianLekies, and Artur Janc. Csp is dead, long live csp! on theinsecurity of whitelists and the future of content securitypolicy. In Proceedings of the 23rd ACM Conferenceon Computer and Communications Security , Vienna,Austria, 2016.[33] WICG. Trusted types. https://github . com/WICG/trusted-typescom/WICG/trusted-types