Engaging in a web application penetration test (pen test) is an increasingly common task for today's infosec professionals. Sadly, there's not a whole lot of guidance about how to begin this process with respect to basic logistics. A lot of testers simply set up a web server, install the software to test, and begin pounding away. This approach presents a number of issues, however. Careful consideration and measured approach are better investments of time and effort.
Build a Sandbox
The first issue with the haphazard approach to testing described above is that the software is now installed and running on some sort of trusted machine, either the tester's laptop or a remote server. This is dangerous because the software has yet to be tested, and may very well be vulnerable to exploitation. Deliberately installing vulnerable software for testing purposes is a recipe for disaster, especially due to the fact that the software may never be utilized for its intended purpose so a compromise may be extremely difficult to detect. Many testers argue that they only install the software for a brief period of time and then turn it off or uninstall it once testing is complete, or even that they firewall off access. However, the possibility exists that the tester will forget to disable the software, or change access restrictions after forgetting about the software, and expose themselves to compromise.
The first step in testing web application software should be to establish a secure sandbox. Virtualization technology is key to this effort. Create a new virtual machine and restrict networking for that machine to the hardware host. Don't allow any connections to the machine other than from the hardware host. This walls off the host so that even if software is vulnerable, left running, and forgotten, the virtual host is still protected. It is helpful to configure the virtual machine at a dedicated IP address so testers don't have to hunt for it amongst the pool of DHCP addresses that their virtualization software can assign. Once this is done be sure to enforce reasonable constraints on the virtual machine (such as firewall access restrictions, installing security packages, setting up automatic updates, etc.).
Test Like the Real World
Once your virtual machine is set up the tester should test software from the hardware host (or through a tunnel to the host). This allows the tester to interact with the web application the same way an attacker would - remotely. Don't just rely on remote access, however. Use tools like the Eclipse Remote System Explorer to do code level analysis. Log into the virtual machine and run any static code analysis tools you might have. Note any issues that might crop up based on file system permissions, database security, or issues with other supporting components of the web application. Remember that web applications are a stack and that security exists at every level of the stack.
In addition to using an IDE to review code, use proxy testing software such as OWASP Web Scarab or FIrefox Tamper Data plugin to test the web application. Test the application as an administrative user, a regular user, and an unauthenticated user. Note any discrepancies or deviations from either the stated or implicit security model of the application. Implicit security assumptions are things like the security goal of preventing unauthorized users from accessing the administrative back end, or tampering with content. Be sure to note any security holes present in the web application using any of the three perspectives.
Make it Work
Most testers make the mistake of installing software, running automated tests, and calling testing complete. Remember that to truly test a system you have to understand how it is supposed to work. There is no way to adequately test a system that you can't operate as intended. Install the software and figure out how to use it. Put the web application through its paces, exercise its functionality and understand how it is designed to work. Many security issues involve manipulating legitimate functionality for malicious purposes. Without understanding the functional design of an application there is no way to thoroughly test boundaries to determine if malicious misuse is possible.
Start, Don't Stop with a Checklist
Checklists are extremely useful for making sure that testers cover potential flaws. By making a checklist of vulnerabilities to test for the tester can ensure that they don't overlook an aspect of application security that they meant to review. Don't stop testing when all the items are complete on a checklist, however. Checklists should cover common vulnerabilities that all applications could manifest, but each application is unique and will have potential vulnerabilities associated with their function and design. As testing moves through the checklist of common vulnerabilities, notes should be taken of extended areas of interest that should also be tested. This ensures that the checklist becomes a baseline for testing, rather than the boundary.
Document Your Work
Whether or not flaws are discovered, testers should always document their work. Documentation should discuss methods of testing used, coverage of testing, and any findings. This is extremely useful for reporting vulnerabilities as well as a preventative measure against duplication of effort. Thorough documentation can not only help you to remember what you tested, how, and why, later on but it can also help you to learn what worked and what didn't work. Documentation is the key to making sure that your efforts are effective, repeatable, and can be shared with others. Lastly, be sure to document your work somewhere it can be located easily. There is nothing worse than archiving testing documentation and not being able to find it later on if someone asks about the software system that was tested.
Conclusion
Testing web applications is serious business and testers should afford the effort the attention it deserves. Set up software in a safe environment that is designed to handle potentially dangerous code in a safe way. Testing should be thourough and duplicate real world scenarios but also leverage local access to the application. Testing should be driven by a checklist so that it is both thorough and repeatable, but tests should ultimately be guided by the software function and funcationality. Testers need to take the time and make the effort to understand the proper use for the software being examined and leverage that understanding into tests that proceed beyond the limits of the testing checklist. Finally, testers need to document their process, approach, and analysis. This helps to cut down on duplication of effort and supports the refinement of future reviews through lessons learned as well as retrospection and review of the test in the future.