It’s been said that Web vulnerabilities are "the new buffer overflow" plaguing the information security community. Almost every day, Bugtraq and other sites record new flaws in commercial or open source Web applications. Even if the vulnerability affects a custom Web application, it’s still being exploited in a manner that could lead to manipulation of the site’s content or exposure of sensitive information.

The staggering growth of Web app vulnerabilities isn’t going unnoticed by the security community. Cutting-edge Web app research is being presented at security conferences and on blogs such as Jeremiah Grossman’s, RSnake’s, and GNUCITIZEN. Stephen Northcutt, president of the SANS Institute, said industry demand has driven his organization to create several Web app security-focused courses addressing penetration testing and secure application development -- like the one I attended last month (“SEC542: Web Application Penetration Testing In-Depth”).

While there are many Web application vulnerabilities, they aren't all the same. Each one may represent different levels of danger to different organizations, depending on the sensitivity of the data available through the site, user access privileges, and the accessibility of other internal systems from the Web and database servers.

So how do you know which Web app vulnerabilities are most serious -- and which to tackle first? In this article, I'll take a look at some of the key vulnerabilities and offer some tips for prioritizing their remediation.

Information disclosure is a common vulnerability, and one of the most often dismissed. Unfortunately, such dismissive attitudes may allow attackers to probe the Web server for information such as the location of the Web application files and usernames for brute force attacks, or even to obtain the Web app’s source code through directory traversal and forced browsing. The clues collected through this sort of probe can often be leveraged to perform more serious attacks.

If a vulnerability assessment of your Web app shows that it is leaking information, evaluate what additional damage could occur if that information was used in conjunction with other vulnerabilities found during the assessment. Source code disclosure usually warrants immediate remediation, as it can include user credentials and may enable an attacker to find other vulnerabilities that wouldn't normally be exposed via a browser-based attack.

Bypass flaws can be exhibited through flaws in the Web app, the server configuration, or a poorly configured firewall. Bypass flaws lead to authentication without having valid user credentials, elevation of privileges, unintended access to files, and access to backend systems. A common bypass flaw is directory traversal, where a Web app allows an attacker to walk the file system, accessing any files that the Web server process will allow.

Just this week, I found a flaw in a Web app that allowed directory traversal and file access to any location on the server -- but was limited to accessing only files with the extension of ".php." Had I been able to upload files to the server via anonymous FTP, I could have easily gained access to a Web-based command shell written in PHP.

In this example, a poorly written Web app and improper file permissions escalated the urgency for remediation. If the attacker could only view the files in the Web root, then the priority to fix this issue would be lower -- with the understanding that the information gained could still be used to make other attacks more effective.

Input validation attacks typically have the widest range of impact, because they can be as simple as causing an error message to appear in a page, which can open the door for a variety of exploits. These attacks are due to improper sanitization of user input, and they include command injection, SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).

A common misconception is that SQL injection will always be a high risk, and requires immediate mitigation. But if the injection causes an SQL error message in the Web page but doesn’t allow arbitrary commands to be executed by the SQL server (such as dropping tables or executing a command shell), then the priority is much lower.

XSS, sometimes dismissed as a party trick, and CSRF can be the most damaging vulnerabilities. These exploits take advantage of the client instead of the server, thereby stealing information and executing commands on behalf of the user.

XSS proof-of-concepts usually involve a pop-up in a browser saying "XSS" or something similar. These demonstrations downplay the seriousness of the threat, when in fact the user’s browser could be taken over by a malicious attacker and used to hack internal resources behind the corporate firewall. CSRF, similarly, abuses the trust that a Web app offers after a user logs in -- and then navigates to another site, leaving an authenticated session open and ripe for abuse.

Attacks against Web apps that abuse the lack of user input validation should be analyzed carefully to determine what impact they have on the Web app itself -- the server, backend databases, and the client browser. If actions can be taken on behalf of the user without their knowledge -- or if arbitrary commands can be executed by the server or SQL server -- then these attacks can present a high risk to your organization and require immediate attention.

When prioritizing the remediation of Web app vulnerabilities, you can't always judge a threat by its classification. Consider what the exploitation of each vulnerability might do to your enterprise systems and your users. Ask your penetration testing team how it has prioritized them in its report. This will help you work with the team to determine which vulnerabilities are truly the most serious -- and which ones to fix first.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.