Identify Threats in Frameworks that your Application Relies on with Qualys Web Application Scanning
Last updated on: September 7, 2020
Most organizations that have an application security program use web application scanning, also known as “Dynamic Application Security Testing” (DAST) to automate the identification of security vulnerabilities in their web applications. They use DAST technology to identify vulnerabilities in their own applications and those developed by their partners. However, many of these applications are based on popular frameworks such as WordPress, Joomla and Drupal. While utilizing these frameworks adds many commonly used features, they may also have unidentified vulnerabilities lurking in code that is not developed by the organization. Using a DAST solution like Qualys Web Application Scanning (WAS) can help organizations to identify and mitigate many of the vulnerabilities that may be hidden threats in these open-source frameworks.
Recently, Joomla fixed just such a vulnerability identified by scanning with Qualys WAS.
About Joomla! and the Vulnerability
As you probably know, Joomla is one of the most popular open-source content management systems in use today. According to Wikipedia, “As of February 2014, Joomla has been downloaded over 50 million times” and is widely considered second only to WordPress in popularity. It has a long history of web security vulnerabilities as noted by nearly 700 entries that contain “Joomla” in the CVE database. Most organizations may infer that because the framework is in such widespread use that they can rely on the Joomla development teams and other third-party assessments of applications built upon Joomla to expose vulnerabilities that would impact them. But as I found, it may be wiser to enlist the help of a DAST solution like Qualys WAS to ensure you are identifying any previously unidentified vulnerabilities that may be easy for attackers to find.
I recently scanned an application that uses Joomla 3.3.3 version with Qualys WAS, and I identified a Cross-Site Scripting (XSS) vulnerability which was not previously reported. I was surprised by it because it is a relatively visible location for an XSS vulnerability and the Joomla team has recently really focused much more attention on the security of the platform. After identifying the issue, I contacted the Joomla team, and they have now fixed this vulnerability in a new release, Joomla 3.3.4. CVE-2014-6631 has been issued for the bug.
How and Where Qualys WAS Found the Vulnerability
The discovery of the issue also outlines some of the challenges that many DAST solutions are not robust enough to overcome. While Joomla was performing input validation that would indicate to many DAST solutions that there was not an exploitable XSS vulnerability, WAS identified that the filtering was insufficient to protect against a more determined attacker that was willing to evaluate and overcome the filter.
The vulnerable URL was easy to find when crawling the web application and I believe most DAST solutions would be able to crawl and extract the vulnerable link. Here is the location of the vulnerable link:
Log in as an administrator, then click ‘Submit a Web Link’, and you can find the vulnerable link:
<a class="btn modal-button" title="Image"
href="http://yourhost/Joomla_3.3.3/index.php?option=com_media&view=images&
tmpl=component&e_name=jform_description&asset=com_weblinks&author="
onclick="IeCursorFix(); return false;" rel="{handler: 'iframe', size: {x: 800, y: 500}}">
<i class="icon-picture"></i> Image </a>
After playing with the vulnerable link, I found that the web application was using some filtering of dangerous characters like “<” and “>”. However, it was still vulnerable because it was not filtering some other dangerous characters like the double quote “ and it was also not performing correct output encoding. (Even if it filters double quote, this is still vulnerable since you could inject JavaScript code directly into the onchange event).
Qualys WAS has many payloads to handle this case, so it is not surprising that WAS identified this vulnerability accurately. After a little research it became clear that there was more than one release of the framework that was vulnerable, meaning this probably impacts a large number of applications that use those earlier versions.
Proof of Concept
This URL (with “yourhost” changed to match the FQDN for your web application) should help you determine if your application is vulnerable:
http://yourhost/Joomla_3.3.3/index.php/component/media/?view=images&tmpl=component& e_name=jform_description&asset=0%29;alert%28%27XSS%27%29//&author=
How to Mitigate Web Security Threats
A strong sense of web security when implementing web applications will help you reduce the web security threats from the source. Using proper input validation and output encoding techniques is critical to ensuring robust security of web applications.
Check Whether Your Input Validation is Adequate
If you take a close look at this vulnerability in Joomla, the injected malicious code that an attacker is using will be reflected in 4 areas in the response body. In these 4 reflection points, the developers are using 2 different input validation methods. Three areas are using input validation to remove all the dangerous characters. (This input validation method is actually robust enough to prevent XSS vulnerability). However, the last one where it is reflected on onchange event is using a different input validation method, which is inadequate and exposes this application to an XSS attack. It is strange that they are using two different input validation methods in the same page, but many times this happens when there is not a centralized library of validation methods in use, which is the best practice.
Appropriate input validation will be able to prevent this XSS vulnerability, the patch for this vulnerability is still using input validation and it is able to mitigate this XSS vulnerability. However, it might be inadequate sometime in the future if it is used without considering where the input would be included in the response.
Applying Output Encoding
As widely adopted, output encoding is another method to prevent XSS vulnerability and is usually used in addition to input validation to provide a defense-in-depth approach. This vulnerability in Joomla would have been avoided if they had used appropriate output encoding methods as well.
Great post. Thank you.