Auditing a Web application can prove a formidable challenge. Naturally, it's helpful if you can explore the framework and technology that form the foundation of an application. If you're charged with auditing a specific set of Web applications, and you have enough time, this endeavor is certainly useful. However, if you have to review applications on a consulting basis or review applications from many development teams or across several business units in your organization, you might find it challenging to stay on top of all the different technologies being used and stay on top of your security expertise at the same time. The following sections offer a few Web application auditing strategies that extend the process presented in Chapter 4, "Application Review Process." These strategies should help you when auditing an unfamiliar and complex Web application. Focus on the ElementsNo matter how many business objects, XML parsers, or levels of indirection are involved in a system, Web applications perform some common, straightforward actions. Focusing on them can help you figure out how things work and where security controls are located (or should be located). Try to isolate the following activities:
Black BoxingBlack box testing can be a critical tool if you're trying to make the most of a limited time frame. It can also be useful for testing code that's unapproachable or testing application components you don't have code for. Be sure to read the sidebar in this chapter on testing for SQL injection vulnerabilities. If you can cause a SQL injection vulnerability and then trace it back to its cause in the source code, you can often find a mistake developers repeat in other places in their Web applications. Attack from Multiple AnglesIt can help to change up your approach occasionally, especially if you feel as though you aren't making progress in wrapping your head around an obtuse Web system. One good approach is end-to-end analysis of the data. Trace a user's request from the Web server, back to the data tier, and back to the Web server. This approach can help you focus on the data flow that's critical for the application's security. You can also try to put yourself in an object-oriented frame of mind. Look at the system from a higher-level perspective, and study each component in isolation. Document what each component does, and brainstorm potential problems that could happen when it's coupled with other components. Sometimes you can benefit from stepping back and reading about the infrastructure code the Web site uses. Learn more about the technology or even, time permitting, attempt to program simple Web functionality using the same technology and see what kind of issues you spot. If you simply need a break from the code, you can spend time constructing an automated attack against the login mechanism or session tokens. If you find a security vulnerability, you can write an automated script to exploit it, and then see how far you can leverage it. Spend some time performing a straight black box test of the application. Make No AssumptionsUse your ignorance as an advantagecreativity is key. Modern enterprise Web applications are often entrenched in a particular design model or technology that can abstract away a lot of the details of how processing occurs. As an outside auditor, you bring a breath of fresh air to the table. Your goal is to understand how the system actually works, not how it's supposed to work. Sit down and give it your best shot, but try not to make any assumptions. Ideally, you'd like to be able to test various theories about the Web technology as you go. It's not uncommon for a senior developer to make a mistake such as a subtle misunderstanding of threading models in a Web technology. It might take someone with a fresh perspective to identify potential issues of this nature. Testing and Experimentation Are CriticalMuch of the system is probably written by a third party, considering the role application frameworks play in modern Web applications. Because you don't have source code to these components, you have to rely on your intuition and a healthy dose of testing against a live system. Be sure to test the middleware, the Web server, and the configuration. Try to bypass built-in authentication mechanisms by appending strange characters to the URL, such as %00, %2f, and %5c. Research vulnerabilities that have plagued other similar Web technologies, and see whether they can be applied in some fashion. Vet the configuration carefully, and make sure you can't get to any functionality that should be protected. Research vulnerability databases, such as the Security Focus Web site mentioned previously, for issues that affect the software or have affected the software in the past. Get Your Hands DirtyAre you following something along when it suddenly disappears into a complex chunk of framework code you don't have source code to? If you have the time and the location seems interesting, reverse-engineer it! Java code reverses quite nicely from bytecode, and x86 or SPARC assembly code isn't that difficult if you have good tools such as IDA Pro, covered in Chapter 4. Enumerate All the FunctionalityOne way to make sure you give an application proper coverage is to try to enumerate all the functionality users can access, and then make sure you have examined that functionality closely. For example, list every URL that can be called, every servlet and servlet action, all directories in the Web tree, all include files, all configuration files, all open ports, and all third-party software components. Have a Goal and Go for ItSometimes brainstorming a particular goal and then attempting to find a way to accomplish that goal is a useful exercise. For example, you might say "I want to place a fraudulent order" or "I want to view someone else's account information." From there, you can examine all code that could be relevant to your attack, and try to brainstorm ways you could achieve this goal. |