The central goal of this article is to set forth a Web application security review methodology that is comprehensive, approachable, and repeatable by readers who wish to apply the wisdom we’ve gained over years of performing them professionally. The basic steps in the methodology are

- Profile the infrastructure
- Attack Web servers
- Survey the application
- Attack the authentication mechanism
- Attack the authorization schemes
- Perform a functional analysis
- Exploit the data connectivity
- Attack the management interfaces
- Attack the client
- Launch a denial-of-service attack

Profile the Infrastructure

The first step in the methodology is to glean a high-level understanding of the target Web infrastructure. Is there a special client necessary to connect to the application? What transports does it use? Over which ports? Howmany servers are there? Is there a load balancer? What is the make and model of the Web server(s)? Are external sites relied on for some functionality?

Attack Web Servers

The sheer number of Web server software vulnerabilities that have been published makes this one of the first and usually most fruitful areas of research for a Web hacker. If site administration is sloppy, you may hit the jackpot here.

Survey the Application

If no serious vulnerabilities have been found yet, good for the application designers (or maybe they’re just lucky). Now attention turns to a more granular examination of the components of the application itself—what sort of content runs on the server? Surveying a Web application attempts to discern what application technologies are deployed (ASP, ISAPI, Java, CGI, others?), the directory structure and file composition of the site, any authenticated content and the types of authentication used, external linkage (if any), and the nature of back-end datastores (if any). This is probably one of the most important steps in the methodology, as oversights here can have significant effects on the overall accuracy and reliability of the entire application review.

Attack the Authentication Mechanism

If any authenticated content is discovered in the previous step, it should be thoroughly analyzed, as it most likely protects sensitive areas of a site. Techniques for assessing the strength of authentication features include automated password guessing attacks, spoofing tokens within a cookie, and so on.

Attack the Authorization Schemes

Once a user is authenticated, the next step is to attack access to files and other objects. This can be accomplished in various ways—through directory traversal techniques, changing the user principle (for example, by altering form or cookie values), requesting hidden objects with guessable names, attempting canonicalization attacks, escalating privileges, and tunneling privileged commands to the SQL server.

Perform a Functional Analysis

Another critical step in the methodology is the actual analysis of each individual function of the application. The essence of functional analysis is identifying each component function of the application (for example, order input, confirmation, and order tracking) and attempting to inject faults into each input receptacle. This process of attempted fault injection is central to software security testing, and is sometimes referred to as input valida
tion attacks.

Exploit the Data Connectivity

Some of the most devastating attacks on Web applications actually relate to the back-end database. After all, that’s usually where all of the juicy customer data is stored anyway, right? Because of the myriad of ways available to connect Web applications with databases, Web developers tend to focus on the most efficient way to make this connection, rather than the most secure.

Attack the Management Interfaces

Until now, we haven’t discussed one of the other essential services that typically runs on or around Web applications: remote management. Web sites run 24/7, which means that it’s not always feasible for the Webmaster to be sitting in the data center when something needs updating or fixing. Combined with the natural propensity of Web folk for remote telework (no dress code required), it’s a good bet that any given Web application architecture has a port open somewhere to permit remote maintenance of servers, content, back-end databases, and so on.

In addition, just about every networking product (hardware or software) that has been produced since the mid-’90s likely shipped with a Web-based management interface running on an embedded Web server.

Attack the Client

In many years of professional Web application testing, we’ve seen darn few reviews take appropriate time to consider attacks against the client side of the Web application architecture. This is a gross oversight in our estimation, since there have been some devastating attacks against the Web user community over the years, including cross-site scripting ploys, like those published for eBay, E*Trade, and Citigroup’s Web sites, as well as Internet-born worms like Nimda that could easily be implemented within a rogue Web site and mailed out via URL to millions of people, or posted to a popular newsgroup, or forwarded via online chat.

Launch a Denial-of-Service Attack

Assuming that an attacker hasn’t gotten in at this point in the methodology, the last refuge of a defeated mind is denial of service (DoS), a sad but true component of today’s Internet. As its name suggests, DoS describes the act of denying Web application functionality to legitimate users. It is typically carried out by issuing a flood of traffic to a site, drowning out legitimate requests.