THE ETHICAL METHODOLOGY OF WEB HACKING

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 I’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

Follow up:

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? How many 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— will describe several attacks that yield remote superuser control over a Web server, all over TCP port 80.

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 validation 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. We’ll cover some of the classic methods for extracting data—and even using SQL to take control of the operating system. Attack the Management Interfaces Until now, I 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, I’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. If you think this is bad, we’ve only scratched the surface of

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.