The Joomla community recently patched a SQL injection vulnerability introduced in Joomla 3.7.0. The article reporting this vulnerability explains how to identify the vulnerability (which was discovered via static code analysis) and how to craft an attack, e.g.

http://example.com/joomla/index.php?option=com_fields&view=fields&layout=modal&
list[fullordering]=exploitation_code

After reviewing the description of the vulnerability, I wondered whether an automated web application scanner, known as a DAST (Dynamic Application Security Testing) tool, could identify an instance of this vulnerability without digging into the source code.

Continue reading …

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.

Continue reading …

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.

Continue reading …

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.

Continue reading …

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.

Continue reading …

Cross-site scripting (XSS) and cross-site request forgery (CSRF) have been well-known attack vectors for a long time. In my previous articles, 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.

Attackers can also combine these two vulnerabilities to launch attacks that bypass prevention measures. This article illustrates how an attacker could execute a XSS attack to get the anti-CSRF token, which could then be used in a CSRF attack to gain administrator privileges in the application.

Continue reading …

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim’s browser into executing malicious requests designed by the attacker.  A successful CSRF attack can force the victim’s browser to perform state-changing requests like transferring funds or changing his email address. Clearly these are attacks that need to be prevented.

Continue reading …

Most organizations that have an application security program use web application scanning, also known as “Dynamic Application Security Testing” (DAST) to automate the identification of security vulnerabilities in their web applications. They use DAST technology to identify vulnerabilities in their own applications and those developed by their partners. However, many of these applications are based on popular frameworks such as WordPress, Joomla and Drupal. While utilizing these frameworks adds many commonly used features, they may also have unidentified vulnerabilities lurking in code that is not developed by the organization. Using a DAST solution like Qualys Web Application Scanning (WAS) can help organizations to identify and mitigate many of the vulnerabilities that may be hidden threats in these open-source frameworks.

Recently, Joomla fixed just such a vulnerability identified by scanning with Qualys WAS.

Continue reading …

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.

Continue reading …

Clickjacking is an attack that tricks a web user into clicking a button, a link or a picture, etc. that the web user didn’t intend to click, typically by overlaying the web page with an iframe. This malicious technique can potentially expose confidential information or, less commonly, take control of the user’s computer. For example, on Facebook, a clickjack can lead to an unauthorized user spamming your entire network of friends from your account.

We’ve known about clickjacking, also called “UI redress attacks,” for years now, as they were originally described in 2008 by Robert Hansen and Jeremiah Grossman. There are countermeasures that web sites can implement to protect against clickjacking attacks, such as framebusters, the X-Frame Option and some client-side plug-ins that can be installed in the browser. However, recent studies have shown that web sites may not be taking this vulnerability seriously – or at least they aren’t attempting to protect their web sites from clickjacking.

Continue reading …