Harsh Realities of the Web

Web applications generally aren't in an advantageous security position, and securing these systems can be an uphill battle. This statement might seem unduly harsh, but as Web security audits consistently show, things just aren't pretty on the Web.

The bottom line is that the security of the whole system determines whether a Web application can be compromised. In other words, the security of the Web application depends not only on the Web application code, but also on the security and configuration of the Web server, the servlet engine, application servers, Web application frameworks, other third-party components and middleware, the database security, the server's OS, and the firewall configuration. A source code review of a Web application in isolation, although certainly of value, examines only a portion of the attack surface.

This section attempts to draw on historical patterns and personal experience to come up with realistic expectations of the security environment the current average enterprise Web infrastructure provides. These maxims might seem unduly harsh or pessimistic, but they represent the rules of the game as it exists today.

You can't trust the Web server: The Web platforms are complex, rapidly changing products that generally have had poor security track records. To be fair, Apache and OpenSSL have held up reasonably well, with only a few remotely exploitable bugs in the past couple of years, and IIS 6.0 looks promising in its default deny configuration. However, this track record isn't that encouraging, and nearly every other Web server has a fairly poor security history. Unfortunately, it doesn't matter how secure your Web application code is if an attacker can easily compromise your Web server.

Reality: Chances are good that the Web server platform hosting the application you're reviewing has its own vulnerabilities. This isn't unexpected, as most complex software probably has dormant security bugs. It's important, however, to be aware of this potential for vulnerabilities and account for it in your planning and risk analysis. In addition, keeping up to date on vendor patches is critical.

Note

As a reviewer, you should research the security of your Web software and make sure you aren't exposed to any known issues. One helpful resource is the Security Focus vulnerability database (www.securityfocus.com), which often has enough information for you to test the issue yourself. Going to the Credit page of the vulnerability entry and looking up the original post that described the problem is useful, as researchers' posts are always more technical than vendor advisories.

If you have the time and motivation, you can try to find vulnerabilities in the software on your own. This endeavor isn't as fruitless as it might seem, as there are probably plenty of surprising vulnerabilities in Web framework code.

Also, if you need to find the versions of software running on a Web server, try using netcat or TELNET to connect to port 80 and issue a simple HEAD request, like this:

HEAD / HTTP/1.0

Usually, you get a banner from the Web server that tells you the version of Web server software you're running, and often you get the versions of other components.

Attackers can get your server-side source code: Source-code disclosure vulnerabilities in Web servers and Web server connectors have been common through the years. One of the authors, for example, found several source-code disclosure vulnerabilities more than five years ago in Java Web Server, based on tricks such as running files through different servlets and appending characters to the end of filenames, such as %00 and %2e. What's scary is that these types of tricks still work today against commercial enterprise products.

If the Web server doesn't have a source-code disclosure vulnerability, there's a good chance of one resulting from the interaction of different layers of technology in its setup. There's also a possibility that JSP forwarding, XML injection, or some other mechanism in the Web application can be exploited to retrieve fragments of server-side source code.

Reality: The application should be designed around the premise that attackers will eventually be able to view server-side source code. Source code shouldn't contain sensitive information, and the site should be secure enough that exposure of technical functionality shouldn't matter. If you want to explore the possibility of retrieving server-side source code, check the Security Focus vulnerability database (www.securityfocus.com) mentioned in the auditing tip.

Attackers can find a way to discover configurations or download configuration files: Application configuration files usually consist of flat text files or XML documents in directories just outside the Web tree or in directories within the Web tree that have some form of protection. There have consistently been vulnerabilities that allow attackers to retrieve these files or use various techniques to explore the Web server's configuration. These vulnerabilities mean debug functionality, prototype code, development testing interfaces, support interfaces, and administrative interfaces that are present but hidden by a layer of obscurity are likely to be discovered. Furthermore, sensitive information in configuration files is probably at risk of exposure.

Reality: There shouldn't be any script files, servlet mappings, or handlers in the production environment that you don't want anonymous Internet attackers exploring. As a reviewer, you definitely want to focus on anything that looks like unnecessary content, as it usually isn't as well vetted as the mainstream code.

Attackers can find all the files in the Web tree: Many vulnerabilities have allowed attackers to retrieve directory indexes or enumerate files and directories in the Web tree. They can range from vulnerabilities in Web servers to configuration issues to application-specific exposures. Attackers could also perform a brute-force or dictionary attack looking for content, or look for specific files, such as tar files, Oracle logs, versioning logs, and other types of common files left behind by developers.

Reality: There should be nothing in the Web tree except documents you intend the Web server to serve. You can expect attackers to eventually find any files in the Web tree. That means include files, programming notes, debugging code, and any other development artifacts should be removed or stored outside the web tree.

Reverse-engineering Java classes is easy: Java class files are usually stored in archives or directories just outside the Web tree. If attackers leverage a vulnerability that allows them to download these class files, they effectively have the Java source code to the application. Java class files can be reverse-engineered to a state that's effectively equivalent to the source form. The reversed source files don't contain comments, and some local variable names are lost, but otherwise, they are quite readable.

Reality: Keep this issue in mind when you're evaluating the significance of a finding that seems as though it would be difficult to discover externally. As far as a solution, you can attempt to obfuscate class files so that they're difficult to reverse-engineer. Ideally, however, attackers who have full application source code shouldn't be able to exploit the system.

Note

If you'd like to pull apart some Java class files, you should use a Java decompiler GUI based on Jad, the fast Java decompiler. You can find the Jad software and a list of GUIs available for Jad at www.kpdus.com/jad.html.

Web applications can be quite difficult to review: Many Web applications are composed largely of third-party code. Applications that are built around frameworks or make heavy use of prepackaged technology can be difficult to analyze. A security reviewer needs to be able to trace the flow of data from end to end in an application, and this process is quite difficult when large portions of the functionality aren't available without reverse-engineering.

Furthermore, many Web applications are abstracted to the point that they become difficult to conceptualize. The abstraction provided by Web frameworks can lead to increased division of labor and more productive programmers, but they also spread the system's functionality over several different layers. A highly compartmentalized object-oriented system has appealing characteristics, but unless it's done extremely well, it tends to make security review more cumbersome. As a reviewer, you're primarily interested in end-to-end data flow and the enforcement of security controls. Understanding the complete data flow is very difficult when the functionality needed to handle one Web request is distributed over more than ten classes and XML configuration files, which is not uncommon.

Reality: Web applications might have weaknesses that even focused source-code auditing has a hard time uncovering.