Recently Qualys extended the cross-site scripting (XSS) detection capabilities of Qualys Web Application Scanning (WAS) by adding a new mechanism for detecting DOM based XSS (DOM XSS) vulnerabilities. The new mechanism works in an automated manner with no special setup or knowledge requirements, enabling security teams to greatly reduce the risk from these typically hard-to-detect vulnerabilities. Because of the technique Qualys WAS uses, it also indicates the location in your code of any XSS bugs found, which is pretty convenient for your development teams.
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.
Would you buy a cellphone with a hardcoded password? Definitely not. I wouldn’t either.
But as is sometimes the case with non-mass-market devices, security can be overlooked in favor of convenience, even if in retrospect it’s clearly a mistake to do so. Fortunately, this story has a happy ending, thanks to responsible disclosure and quick vendor response.
On April 21, WordPress issued a critical security release and “strongly encouraged” their customers to update their webites “immediately.” In general, the use of these alarming terms is symptomatic of a significant threat. And it is indeed.
WordPress is so overwhelming the CMS market that nearly 50% of all websites are based on it. This recent security release fixes multiple vulnerabilities so important that an attacker may be able to obtain administrator access on any of those millions of websites. The most sensitive vulnerability is targeting WordPress version 4.1.1 and earlier.
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.
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.
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.
Text and strings form the building blocks of web apps. Developers and content creators mix text with other media, code, and HTML to produce all kinds of apps for our browsers. However, when developers mix text with code or they carelessly place strings inside of HTML they expose the app to one of the most common web-related vulns: HTML Injection, a.k.a. Cross-Site Scripting (XSS). One way this happens is when developers use string concatenation to piece together a web page with static HTML and user-supplied data. For example, think of a site’s search function. When you submit a search request, the site responds with something like, "Here are the results for XYZ," and lists whatever might have matched. HTML injection occurs when the search term contains markup instead of simple text, and the app treats it like this:
<span>Here are the results for "<script>alert(9)</script>"</span>
Recently, I found that one of Adobe ColdFusion’s patches (APSB11-29) doesn’t resolve a cross-site scripting (XSS) vulnerability completely. In a specific case, the vulnerability can be replayed. This can be exploited to execute arbitrary HTML and script code in a user’s browser session in the context of a vulnerable site. Adobe has updated its advisory to warn users about this potential risk.
From the advisory APSB11-29, we can see that Adobe fixed a cross-site scripting vulnerability in the CFForm tag (CVE-2011-2463). And, as you know, Adobe ColdFusion Server is based on Java. So, in this article, I’ll analyze the patch with a Java decompiler tool to reveal the issue and the potential risk in the patch itself. Now let’s go further into it.
In between writing lines of code, I try to twist my fingers into typing more human-friendly output. In this case, it’s a new book on web security called, simply enough, Hacking Web Apps. It explains several web security weaknesses and vulnerabilities, from HTML injection to protecting passwords, to design issues that lead to CSRF, clickjacking and more.
Most well-known web compromises tend to stem from HTML injection (cross-site scripting, or XSS) or SQL injection. After all, those vulns tend to be easy-to-find and deliver high-impact results like site defacement or stealing millions of passwords. By now, we have tools like sqlmap and BeEF that strip most of the mystery from how these vulns are exploited. Ask someone experienced in web security how easy it is to find XSS and they’ll probably call it child’s play. Check out the OWASP Top 10 and you’ll see XSS detectability rated as easy.
But HTML injection continues to infest sites regardless of their size or sophistication, which seems to imply that its detectability might not be so easy after all. Maybe XSS remains unknown to the huge population of developers building web sites, or maybe the increasing complexity of sites makes security exponentially harder to maintain. Maybe it’s hard to evaluate the tens of millions of sites on the web when there might not even be tens of thousands of people capable of doing it well. At the very least, more education should help.
The book explains how XSS shows up in unexpected places, giving you hints on what to look for in your own site as well as things to consider when coding countermeasures (hint: regular expressions are tough to get right). Even sites with well-informed developers and experienced security teams have this problem.
And those unexpected places? The HTML injection chapter hacked Amazon right from the printed page. A Gutenberg Press Injection attack, if you will.
Then there are hacks like cross-site request forgery (CSRF) and clickjacking that blur the line between tools and manual testing. The search pages for Bing, Google and Yahoo are all, strictly speaking, vulnerable to CSRF. Manual analysis is required to assess the relative risks in such cases and consider whether certain threats are worth addressing. This is the engineering side of security: weighing trade-offs between performance, complexity, threats and risks. Learning about the kinds of design problems that lead to insecure sites helps you avoid them in the future.
Different design problems are covered in the book, as well as the mistakes that happen when good design is betrayed by poor implementation. What if a site lets you apply a discount code multiple times? What if it lets you modify the email recipient for password reset instructions? What if it encourages you to create a long passphrase, but only uses the first eight characters? These sorts of problems are harder, if not impossible, to find with any automated tool. This is why it’s good to stay informed about web security beyond the simple XSS and SQL injection vulns we hear about so often.
And if you’re still unconvinced about the importance of web security, consider this paragraph from the introduction:
On the web information equals money. Credit cards clearly have value to hackers; underground "carder" sites have popped up that deal in stolen cards; complete with forums, user feedback, and seller ratings. Yet our personal information, passwords, email accounts, on-line game accounts, and so forth all have value to the right buyer, let alone the value we personally place in keeping such things private. Consider the murky realms of economic espionage and state-sponsored network attacks that have popular attention and grand claims, but a scarcity of reliable public information. (Not that it matters to web security that "cyberwar" exists or not; on that topic we care more about WarGames and Wintermute for this book.) It’s possible to map just about any scam, cheat, trick, ruse, and other synonyms from real-world conflict between people, companies, and countries to an analogous attack executed on the web. There’s no lack of motivation for trying to gain illicit access to the wealth of information on the web, whether for glory, country, money, or sheer curiosity.
Hacking Web Apps aims to give you a feeling for how hackers exploit web sites along with examples and details about each vuln’s inner workings. Whether you’re developing a web application, or are just curious how hackers take apart web sites, there should be something in there for you.
