The assessment of various web services and individual subsystems can fill its own book. Web services run over two protocols: HTTP (found on TCP port 80, and sometimes 81, 8080, and others) and HTTPS (an SSL-enhanced web service usually found on TCP port 443).
Many security consultants run simple CGI scanning tools (such as whisker) against web services, which doesn't fully identify and categorize all the risks at hand. In broad terms, professional assessment of web services involves the following five steps:
Identifying the web service running (such as IIS 4.0 or Apache 1.3.27)
Identifying subsystems and enabled components (such as FrontPage Extensions)
Investigating known vulnerabilities in the web service and its enabled components
Identifying and accessing poorly protected sensitive information
Assessing CGI scripts and custom ASP pages running server-side
Automated web service scanning tools, such as nikto (http://www.cirt.net/code/nikto.shtml) and N-Stealth (http://www.nstalker.com/nstealth/), are good at performing Steps 1, 2, and 4. The Open Web Application Security Project (OWASP) site at http://www.owasp.org is a great source of tools and white papers discussing the assessment of custom CGI scripts and ASP pages for SQL injection and other vulnerabilities.
 URLs for tools in this book are mirrored at the O'Reilly site, http://examples.oreilly.com/networksa/tools.
All in all, basic web assessment can be automated. It is imperative, however, that you perform hands-on testing and qualification after automatically identifying all the obvious security flaws, especially when assessing complex environments such as custom-built e-commerce sites.
Buffer overflow and memory corruption vulnerabilities are difficult to identify in most environments, so you have to download exploit scripts and launch them against the target web server (following accurate service identification) to qualify vulnerabilities that manipulate areas of remote server memory.
To show how various components at presentation, application, and data tiers are often arranged in complex enterprise web environments, the OWASP team put together the diagram shown in Figure 6-1.
Vulnerabilities can exist in any of these tiers, so it is important to ensure that even small exposures can't be combined to result in a compromise. From a secure design and development perspective, you must filter and control data flow between the three tiers.
With these pearls of wisdom in mind, you can proceed to check over the target HTTP or HTTPS web server and properly assess various vulnerabilities that may become apparent.