Category Archives: Research Work

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

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
Connection: keep-alive

By make the request and clicking the “cancel” button in the response page, the user will be redirected to 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.

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