Tag Archives: XSS

Exploit XSS in <link rel=’canonical’> when characters < and > are filterred

In one of our customer’s website, the injection point is in <link rel=’canonical’ href=”> tag and it looks like something like

 <link rel=’cannoical’ href=’http://example.com/test.php?pid=<?php echo $_SERVER[‘QUERY_STRING’];>’>

The server will encode <, > and “, if you try http://example.com/test.php?pid=”<qss>, the response will be

<link rel="canonical" href='http://example.com/test.php?pid=&quot;&lt;qss&gt;' />

Under this case, using the following payload, you could exploit this XSS under IE7  and IE 8.

http://example.com/test.php?pid=’style=’x:expression(alert(document.cookie))’ t

 

From XSS to CSRF, how to gain administrator control of websites hosting myBB

I describe how XSS vulnerabilities can be used to attack popular open source web applications and application frameworks, and how some web applications are compromised by CSRF attacks because of implementation flaws on the server side.

In most of the case, an attacker will combine these two kinds of vulnerability to launch destructive attacks. In a recent audit against MyBB 1.8.3, I discovered a XSS vulnerability and I demonstrated how to gain administrator access to the website hosting MyBB though session hijacking was prohibited there.  To get a quick look at this article, please read my blog under Qualys Community…

Path Based XSS Vulnerability in PHPBB3.1.0

After reporting a Cross-Site Scripting vulnerability in Joomla 3.3.3, I spend some time to play with widely used open source software, pphBB3.1.0.   Without paying too much effort on it, I found a Cross-Site Scripting vulnerability in it and now it has been patched in phpBB 3.1.1.

Different to a normal XSS vulnerability, Path Based XSS vulnerability, as the name it indicates, is relatively special XSS vulnerability since the injection point is the PATH of HTTP Request,  which makes me to feel worthy to start a write up on it.

Where is the Path Based XSS in PHPBB 3.1.0?

POC

GET /phpBB3/index.php/><script>alert(‘XSS’)</script> HTTP/1.1
Host: yourdomain
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: phpbb3_gk69y_k=; phpbb3_gk69y_u=2Connection: keep-alive

The injected JavaScript Code will be reflected at

<body id=”phpbb” class=”nojs notouch section-index/“><script>alert(‘XSS’)</script> ltr “>

Note:  I was unable to exploit this vulnerability through a modern browser since it will encode the injected JavaScript code automatically as filename. In order to reproduce this vulnerability, you will need assistance from a proxy.

When digging into the source code, I observed this XSS vulnerability was actually caused by the following code

$symfony_request_path = $phpbb_filesystem->clean_path($symfony_request->getPathInfo());
if ($symfony_request_path !== ‘/’)
{
$page_name .= $symfony_request_path;
}                                                                                                                                            // phpbb/session.php
‘SCRIPT_NAME’      => str_replace(‘.’ . $phpEx, ”, $user->page[‘page_name’]),    // includes/functions.php:
<body id=\”phpbb\” class=\”nojs notouch section-“;
// line 55
echo (isset($context[“SCRIPT_NAME”]) ? $context[“SCRIPT_NAME”] : null);
echo ” “;
echo (isset($context[“S_CONTENT_DIRECTION”]) ? $context[“S_CONTENT_DIRECTION”] : null);
echo ” “;
echo (isset($context[“BODY_CLASS”]) ? $context[“BODY_CLASS”] : null);
echo “\”>”;

The source code indicates  injected JavaScript code was taken as the Page Name  and the application is then trying to render the PageName as index/”><script>alert(‘XSS’)</script> in the response page before encode it. As a consequence, it exposed XSS vulnerability.

Path Based XSS Vulnerability are on the stage

 

What is PATH Based XSS vulnerability

In general, PATH Based XSS vulnerability was composed when the request URLs are rendered directly in the response body without proper encoding or input validation.

The most common format of the PATH Based XSS vulnerability looks like.

<a href=” <?php echo $_SERVER[‘REQUEST_URI’];?>”>Click Here </a>

Special, but Not Rare

Path Based XSS vulnerability is special, but it is not rare vulnerability in web applications. With several years working experience in Qualys,   I have seen several cases in some open source web application, such as ATutor , E107 and TomatoCar ,etc.

A lot of developers may never think about the injection point could be the PATH of the URl. Normally, they think XSS vulnerability could only appear in request headers or request parameters. That could explain WHY PHPBB3 is suffering this vulnerability.

With no doubt, attention should be paid to check whether your website is suffering from path based XSS vulnerability because the developers might ignore this potential injection point.