Auditing Web Servers

Background
The background of Internet web applications is fascinating because it has come so far in such a short time period. Perl,
widely used for web applications, was created by Larry Wall in 1987, four years before the first web server was installed in
the United States. The rapid development of the Internet is broadly attributed to the need to share information that would
accelerate development across research and later business. Entrepreneurs found new business models in the Internet
and were able to take advantage of people's need to send and receive information instantly.
The pieces that enabled this rapid growth include the web server, the web browser, and the connected web of computer
hosts. Some of the key dates in the development of the web as we know it include

1989: European physicists Tim Berners-Lee and Robert Cailliau in Switzerland come up with the concept of the

World Wide Web.

1991: Paul Kunz, a physicist at Stanford, installs the first web server in the United States to communicate with the

"Next" computer in Switzerland.

1993: Mosaic is born as Marc Andreessen, a student at the University of Illinois' National Center for

Supercomputer Applications (NCSA), creates the first web browser with mass appeal. He later leaves with friends
from NCSA to eventually create Netscape Communications Corp.
1995: Java is born with Sun Microsystems Java 1.0.
1995: Apache is officially released to the public.
1996: Microsoft releases Internet Explorer 3.0, and Netscape releases Navigator 3.0.
2000: Hackers take down major websites and deface thousands of others, finally bringing attention to web

security.
2001:
The Open

Web

Application

Security

Project (OWASP)

is

born

(http://www.owasp.org).

Web Auditing Essentials

The trick to auditing your web servers understands how to compartmentalize the task and then correctly specify the scope
of the work you want to accomplish. Auditing in our case is trying to use 20% of the tools and technologies available to
discover 80% of the possible risks implemented into the system or processes around the system. Remember that
auditing, as much as we would like to believe, isn't an exact science, and auditing web servers is one area in which this is
apparent. We are going to equip you with the tools to outline and begin execution for your audit. Release yourself from the
guilt of not being perfect, or you will either never get started or you'll end up ineffective as you try to cover too much with
too few resources and knowledge.

Web Auditing Components

A complete web audit is really an audit of three large components. First, there's the underlying platform or operating
system on which the web application is installed and runs. This is covered in earlier chapters. Second, there is the web
server itself, such as IIS, Apache, or Tomcat, which is covered below. An encyclopedia could be written about every web
application in existence and the individual settings in each one. We cover the concepts, show some examples, and leave
it to you to understand how to apply the concepts to any esoteric web servers. Finally, there is the audit of the web
application that runs on top of the web server. These are show in Table 8-1.
Web Audit Component

Key Concerns

Web platform

Security of the operating system, physical and network protection to the host

Web server

Default settings, sample code, general misconfigurations

Web Audit Component

Key Concerns

Web platform

Security of the operating system, physical and network protection to the host

Web application

Default application settings, input validation, incorrectly serving up data, access to

company confidential data, general misconfigurations
Table 8-1: Web Auditing Components

There is a wealth of languages and structures for web application development, complicating the audit process. However,
there are also several tools available to help us wade through the mix and determine what needs attention. We will go
through these in the steps below.

Auditing Web Platforms and Web Applications

The audit of a web platform, or host, should be conducted in conjunction with the audit of the web server and web
application(s). Please see Chapters 6 and 7 on Unix or Windows if one of those applies for the audit of the platform. The
following steps are intentionally general and cover the common issues found in web servers and applications. These steps
will suffice for most audits.
Keep in mind that if the following steps don't fit with your intentions, then you need to review Chapter 10 on Auditing
Applications. That chapter is intentionally geared toward conceptually breaking down complex or infrequent audits.

Note

The platform portion of the audit is as important as the audit of the web server and the web
applications. Please refer to the Chapters 6 and 7 on auditing Unix or Windows servers for this
portion of the audit.

Auditing Web Servers

There are certainly differences among the many web servers available, but there are many commonalities that you need
to check. These are listed in the steps that follow. Each step may or may not apply to your situation, but you need to take
the time to find out. If these steps apply, then we suggest that you test for the following components of a web server. Keep
in mind that we examine the applications that are running on the web server in a separate list that follows this one.
1. Verify that the web server is running on a dedicated system and not in conjunction with other critical applications.
If the web server were hacked with other applications running on the same host, then they also might be subject to
compromise. You should use a dedicated machine as a web server. For example, you would never want to install your
web server on a domain controller.
How
Determine the infrastructure location with the administrator, and carefully consider other applications that also may be
running on the same host as the web server. If other applications exist, question the need for running other applications
on the web server.

2. Verify that the web server is fully patched and updated with the latest approved code.
Failure to run adequately patched systems subjects the web server to unnecessary risk of compromise from vulnerabilities
that may have been patched with updated code releases.
How
Every organization has its own patch-management systems and policies. Verify that the web server is running the latest
approved code with the help of the administrator according to the policies and procedures in the environment. Also review
the policies and procedures for appropriate and timely demands for keeping and verifying that systems are up-to-date with
the latest code releases.
3. Determine if the web server should be running additional tools to aid in the protection of the web server.
Web servers often come with additional measures designed to protect them, such as IISLockdown and URLScan. These
tools are recommended often by the vendors or developers. The additional controls put in place by these tools can lower
the overall risk of the server to compromise greatly.
How
Determine through research at the web developer's website and discussions with the web administrator what tools are
available and the additional controls the tools offer for the given increase in administration. These tools might include
validation checking or tools that monitor web server connections. Some tools offer quite a bit of additional protection for
very little additional overhead. In the Microsoft environment, IISLockdown and URLScan should be run on every Window
IIS web server with very few exceptions. Check to see if your organization has procedures governing how to configure
these tools, and verify that they are configured correctly.

Note

IISLockdown is only for IIS 5.x. IIS 6 is already semisecure; you still can install URLScan on IIS 6 to
further harden and reduce functionality. With Windows Server 2003 SP1, the Security Configuration
Wizard provides a way to strip all unnecessary functionality from the IIS so that only components
that are necessary for the web server to fulfill its role in life are installed and/or running.

4 .Verify that unnecessary services or modules are disabled. Running services and modules should be operating under the least privileged
accounts.
Unnecessary services and modules present additional opportunities for malicious attackers and malware.
How
Discuss and verify with the help of the administrator that unnecessary services are disabled and that the running services
are operating under the least privileged account possible. Verify that FTP, SMTP, Telnet, FrontPage Server Extensions,
and NNTP services are disabled if they are not required.
If you are running Apache, only enable modules that are absolutely necessary. Table 8-2 presents a list of modules
considered to be the bare minimum. Question the need for anything else that might be running.

Apache Module

Purpose

httpd core

Core module, foundation of the web server

mod access

Necessary for allow, deny, and order directives

mod auth

Supports HTTP basic authentication

mod dir

Supports index files (e.g., index.html)

mod log config

Supports logging

mod mime

Provides support for character set, content encoding, content language, and MIME
types of documents

Table 8-2: Minimum Apache Modules

5 .Verify that only appropriate protocols and ports are allowed to access the web server.
Minimizing the number of protocols and ports allowed to access the web server reduces the number of attack vectors
available to compromise the server.
How
Discuss with the administrator and verify with the administrator's help that only necessary protocols are allowed to access
the server. For example, the TCP/IP stack on the server should be hardened to allow only appropriate protocols, and
NetBIOS and SMB should be disabled on IIS servers. Note any additional controls that may be in place, such as firewall
rules or network access control lists (ACLs) to limit the protocols and ports allowed to access the web server. In general,
only TCP on ports 80 (HTTP) and 443 (SSL) should be allowed to access the web server.

6 .Verify that accounts allowing access to the web server are managed appropriately and hardened with strong passwords.
Inappropriately managed or used accounts could provide easy access to the web server, bypassing other additional
security controls to prevent malicious attacks. This is a large step with a wide scope, covering controls around account
use and management.
How
Discuss with the administrator and verify with the administrator's help that unused accounts are removed from the server
or completely disabled. The administrator's account on Windows servers should be renamed, and all accounts should be
restricted from remote login except for those used for administration.
The root account on Unix flavored hosts (Linux, Solaris, etc) should be strictly controlled and never used for direct remote
administration. Never run Unix web servers such as Apache under the root account. They should be run under a distinct
user and group such as http://www.-apache. Please see Chapter 7 for more information about the root account.
In general, accounts never should be shared among administrators, and administrators never should share their accounts
with users. Strong account and password policies always should be enforced by the server and by the web server
application.
Additional considerations for IIS web servers include ensuring that the IUSR_MACHINE account is disabled if it is not
used by the application. You also should create a custom least-privileged anonymous account if your applications require
anonymous access. Configure a separate anonymous user account for each application if you host multiple web
applications.
7. Ensure that appropriate controls exist for files, directories, and virtual directories.
Inappropriate controls for files and directories used by the web server and the system in general allow attackers access to
more information and tools than should be available. For example, remote administration utilities increase the likelihood of
compromising a web server.
How
Discuss with the administrator and verify with the administrator's assistance that logs and website content are stored on a
nonsystem volume where possible. Verify that files and directories have appropriate permissions, especially those
containing

Website content

Website scripts

System files (e.g. %windir%\system32 or web server directories)

Tools, utilities, and software development kits

Sample applications and virtual directories should be removed. These would include IISSamples, IISAdmin, IISHelp, and
Scripts virtual directories in IIS web servers.

Also verify that anonymous and everyone groups (world permissions) are restricted except where absolutely necessary.
Additionally, no files or directories should be shared out on the system unless necessary.

8. Ensure that the web server has appropriate logging enabled and secured.
Logging auditable events helps administrators to troubleshoot issues. Logging also allows incident response teams to
gather forensic data.
How
Verify with the administrator that key audit trails are kept, such as failed logon attempts. Ideally, these logs should be
relocated and secured away from the same volume as the web server. Log files also should be archived regularly. They
should be analyzed regularly, preferably by an automated tool in largeinformation technology (IT) environments.

9 .Ensure that script extensions are mapped appropriately.

Scripts might allow an attacker to execute the code of his or her choice, potentially compromising the web server.
How
Verify with the web administrator that script extensions not used by the web server are mapped to a 404 web page
handler or simply denied altogether. Examples of extensions that you may or may not use include .idq, .htw, .ida, .shtml,
.shtm, .stm, .idc, .htr, and .printer.

10. Verify that unnecessary or unused ISAPI filters are removed from the server.
ISAPI filters are tightly wrapped with the web server and were intended to allow rapid script execution, faster than CGI
scripts. Support for ISAPI is designed into several web servers, but there have been problems with ISAPI in the past.
Unsecured or unused ISAPI filters may present another avenue of attack.
How
Verify with the web administrator that any ISAPI filters installed on the web server are necessary. Unnecessary or
unsecured web filters should be removed from the server.

11 .Verify the validity and use of any server certificates in use.

Server side certificates enable clients to trust your web server's identity or that your web server is who you say your server
is supposed to be. Old or revoked certificates suggest that your website may or may not be valid to end users.

How
Verify with the help of the administrator that any certificates are used for their intended purpose and have not been
revoked. Certificate data ranges, public key, and metadata all should be valid. If any of these have changed, then consider
the need for a new certificate that reflects your current needs.

Auditing Web Applications

The best compilation of common web application issues is maintained by the Open Web Application Security
Project (OWASP). According to its website, it is "dedicated to enabling organizations to develop, purchase, and maintain
applications that can be trusted." In short, it has a tremendous amount of information that will help you to develop a solid
audit program for your web applications. OWASP is supported by companies such as VISA, Deloitte, and Foundstone.
The OWASP "top ten" have made their way into standards, such as the Payment Card Industry (PCI) standard, and these
"top ten" are regarded as a set of minimum standards you should examine during an audit. Below you will find an example
of how to go about an audit of the OWASP "top ten."
There are important caveats as you move through this audit program. Some of the following steps may be more important
to you than other steps because of how your application is designed. We assume for the most part that there are
interactions between the web server and the user, such as logging into the application or serving up user-requested data.

Note

Keep in mind that the audience of this book varies greatly in technical abilities, and an
attempt has been made to simplify as much as possible for the majority of the readers. You
may want to visit http://www.owasp.org/index.php/OWASP_Top_Ten_Project to determine
what scope and toolset make sense in your environment.

1 .Verify that all input is validated prior to use by the web server.
Information must be validated before being used by a web application. Failure to validate web requests subjects the web
server to increased risk from attackers attempting to manipulate input data to produce malicious results.
How
Discuss with the web application developer or web administrator the methodology used for input validation for the
application you are testing.
There are several tools that effectively act as a proxy and allow you to see much of the content posted from your client to
the remote web server. One such tool is Paros Proxy, located at http://www.parosproxy.org.
Another method used by professional web testers is to understand the movement of data during a code review. This isn't
something that should be taken lightly because it may be beyond the scope of what you are trying to accomplish. There is
a tradeoff that you as an auditor are going to have to make regarding the amount of effort you put into this versus the cost
of the data you are protecting.
In general, two ways to look at validation methods are negative methods and positive methods. Negative methods focus
on knowing what bad input to filter out based on the known bad. The problem with negative filtering is that we don't know

now what tomorrow's vulnerabilities and input methods will bring. Positive filtering is much more effective and involves
focusing on validating the data based on what they should be. This is similar in approach to a firewall that denies
everything except what should be accepted.
Common items for positive filtering include criteria you might find in a database or other places that accept data. These
include criteria such as

Data type (e.g. string, integer, and real)

Allowed character set

Minimum and maximum length

Whether null is allowed

Whether the parameter is required or not

Whether duplicates are allowed

Numeric range

Specific legal values (e.g., enumeration)

Specific patterns (e.g., regular expressions)

2. Verify that proper authorization controls are enforced.

After a user is authenticated to the web server, the web server determines what kind of access the user should have and
to what parts of the website the user should have access. Failure to enforce access controls (authorization) may allow an
attacker to step out of authorized boundaries, accessing other users' data or administering unauthorized areas.
How
Discuss the policy requirements with the administrator. Failure to have a policy or other written documentation for a homegrown application is a red flag that suggests that access controls are not being enforced correctly. This is so because
access controls are complicated and difficult to get right without carefully documenting and thinking through your desired
results. Typical methods for bypassing given authorization include those shown in Table 8-3.

Cached or Insecure
IDs

Many websites use some sort of key or ID stored on the client as a means of determining
what rights the user has on the web server. If the user can guess and create a token, then
he or she may have free reign on the web server.

Forced Browsing

Some websites require certain checks before allowing a user to access content deeper in

the site. If the checks are not enforced, then a user can access the content directly.

Path Traversal

These attacks attempt to backtrack and go around normal permission sets to gain access
to information or files not normally accessible.

File Permissions

Log and configuration files, among others, may have incorrect permissions and be
accessible through the web interface. Correctly setting file permissions also can help in
preventing other attacks.

Client Side Caching

Clients should not cache sensitive information such as credit card and personal data.
Attackers can take advantage of users' cached data and maliciously reuse this
information.

Table 8-3: Common Methods for Bypassing Web Application Authorization

3. Broken Authentication and Session Management

Account credentials and session tokens must be protected. Attackers who can compromise passwords, keys, session
cookies, or other tokens can defeat authentication restrictions and assume other users' identities.
How
Discuss with the administrator the authentication mechanism used to authenticate users to the web application. The web
application should have built-in facilities to handle the life cycle of user accounts. Verify that help-desk functionality, such
as lost passwords, is handled securely. Walk through the implementation with the administrator, and then ask the
administrator to demonstrate to you the functionality.
Table 8-4 contains a shortened list of guiding principles when it comes to checking the authentication mechanism used on
a website. These are taken from OWASP's website, which contains several more principles, including coding examples.

When a user enters an invalid credential into a login page, don't return which item was incorrect. Show a generic
message instead such as, "Your login information was invalid!"

Never submit login information via a GET request. Always use POST.

Use SSL to protect login page delivery and credential transmission.

Remove dead code and client-side viewable comments from all pages.

Do not depend on client-side validation. Validate input parameters for type and length on the server, using regular
expressions or string functions.

Database queries should use parameterized queries or properly constructed stored procedures.

Database connections should be made created using a lower privileged account. Your application should not log into
the database using sa or dbadmim.

One way to store passwords is to hash passwords in a database or flat file using SHA-256 or greater with a random
salt value for each password.

Prompt the user to close his or her browser to ensure that header authentication information has been flushed.

Table 8-4: Guiding Principles of Web Authentication

Note

Please visit http://www.owasp.org/index.php/Authentication for

authentication methods and the strengths and weaknesses of each.

4 .Review the website for cross-site-scripting vulnerabilities.

an

excellent

overview

of

Cross-site scripting (XSS) allows the web application to transport an attack from one user to another end user's browser.
A successful attack can disclose the second end user's session token, attack the local machine, or spoof content to fool
the user. Damaging attacks include the disclosure of end-user files, installation of Trojan horse programs, redirecting the
user to some other page or site, and modifying the presentation of content.
How
Cross-site scripting attacks are very difficult to find, and although tools can help, they are notoriously inept at locating all
the possible combinations of XSS possible on a web application. By far the best method for determining if your website is
vulnerable is by doing a thorough code review with the administrator.
If you were to review the code, you would search for every possible path by which HTTP input could make its way into the
output going to a user's browser. The key method used to protect a web application from XSS attacks is to validate every
header, cookie, query string, form field, and hidden field. Drawing on the previous discussion of positive and negative
validation measures, you should make sure to employ a positive validation method.
CIRT.net contains two tools, Nikto and a Nessus plugin, that you might be able to use to help you automate the task of
looking for XSS vulnerabilities on your web server. Keep in mind that these tools are not as thorough as conducting a
complete code review, but at least they can provide more information to those who don't have the skill set, resources,
time, and dollars to conduct a complete review. Nikto, a tool from http://www.cirt.net/code/nikto.shtml, searches literally
thousands of known issues across hundreds of platforms. It's a powerful tool and should be part of your toolset. Scan
items and plugins are updated frequently and can be updated automatically if desired. Commercial tools also are available
that may help, such as acunetix (http://www.acunetix.com). These tools may find well-known attacks, but they will not be
nearly as good as performing a solid code review.
If you don't have the internal resources available to perform a code review, particularly on a home-grown application, and
you believe that the data on the website warrant a deep review, then consider hiring third-party help. There are outfits
such as FishNet Security (http://www.fishnetsecurity.com) that perform this kind of work.

5 .Verify that the server is updated with all known patches for buffer overflows.
Buffer overflows are quick to find their way into an exploit for web servers in general. You should make sure that all
applicable patches covering buffer overflows are installed on the web server to protect your web applications.
How
Buffer overflows aren't something you typically find by looking through the code unless you are a professional hacker paid
to do this. By far the easiest method to stay on top of buffer overflows is to stay on top of the patching cycle for your
systems. You have patches for the operating system, web platform, and in many cases the web application that you need
to research and verify.
Discuss the patching cycle of the web servers with the web administrator to ensure that any applicable web application
patches have been installed. This sounds like a repeat of step 2 above for the web platform. However, in certain cases,
commercial web applications require their own patches separate from the web platform. Ensure that all known patches
are installed to protect the security of the web platform and web application.

6. Ensure that the web application is protected against injection attacks.

Injection attacks allow a web client to pass data through the web server and out to another system. For example, in an
SQL injection attack, SQL code is passed through the web interface, and the database is asked to perform functions out of
bounds of your authorization. Several websites have coughed up credit-card and Social Security card information to
hackers who have taken advantage of injection attacks.
Failure to realize the power of injection attacks and to review your systems for the likelihood of being exploited may result
in the loss of critical and sensitive information.
How
Discuss injection attacks with the administrator to ensure that he or she understands how they work, and then ask how he
or she is guarding against injection attacks. There aren't any tools that will review and discover every possible injection
attack on your web application, but you still can defend against them. The defense methods are a repeat of what was
covered in cross-site scripting:

Validate all input using positive validation methods.

Perform a code review if possible for all calls to external resources to determine if the method could be
compromised.

Commercial tools are available that may help, such as acunetix (http://www.acunetix.com). These tools are
definitely powerful and may find well-known attacks, but they will not be as good as performing a solid code
review.

Consider hiring third-party help if the application is particularly sensitive, you lack the resources, or you need to
verify items such as regulatory compliance.

7 .Evaluate the use of proper error handling.

Improperly controlled error conditions allow attackers to gain detailed system information, deny service, cause security
mechanisms to fail, or crash the server.
How
Improper error handling generally is a function of having detailed plans in place during development of the application to
centralize and control all input methods. Ask the administrator how error handling was designed into the web application
and how errors are handled internally as the application interfaces with other compartmentalized functions. For example,
how would the web application handle an error generated by the database? Does it make a difference whether the
database is hosted internally by the application as opposed to hosting the database externally on another server? How
does the application handle input validation errors? What about username and password errors?

Error handling is often better controlled if it is centralized as opposed to compartmentalizing it across several interworking
objects or components. If you are reviewing the code, the error handling should flow nicely and show structure. If the error
handling looks haphazard and like an afterthought, then you may want to look much more closely at the application's
ability to handle errors properly.

8. Ensure that secure storage mechanisms are used correctly and appropriately.
Web applications often want to obfuscate or encrypt data to protect the data and credentials. The challenge is that there
are two parts to this scheme: the black box that does the magic and the implementation of the black box into your web
application. These have proven difficult to code properly, frequently resulting in weak protection.
How
Begin the discussion with the web administrator by talking about the sensitivity of the data you want to protect. If the data
are sensitive and not encrypted, then consider whether there are industry or regulatory drivers stating that the data must
be encrypted, and note the issue. If data are encrypted, then discuss in detail with the developer or review documentation
with the administrator to understand how the encryption mechanism was implemented into your web application. Ensure
that the level of encryption is equivalent to the level of data you want to protect. If you have extremely sensitive data such
as credit-card data, then you may want to have actual encryption instead of a simple algorithm that obfuscates the data.

Note

Obfuscation simply means to find creative ways of hiding data without using a key. Encryption is
considered to be much, much more secure than obfuscation. Encryption uses tested algorithms and
unique keys to transform data into a new form in which there is a little or no chance of recreating the
original data without a key. Sound complicated? It's that much harder to defeat properly
implemented encryption than it is to defeat obfuscation.

9. Determine the use of adequate controls to prevent denial of service.

It is possible for attackers to repeatedly connect to your web application and fill up all available resources until there is
nothing left for legitimate users.
How
This is incredibly difficult to defend against, but there are a few things you can do. Discuss with the administrator how he
or she is handling user resources. Ideally, authenticated users would have more resources, and visiting users would be
limited in scope as to what they can access. Resource-intensive operations in some cases may be offloaded, such as
database queries. In some cases, data may be cached so that the same operation isn't performed repeatedly, eating up
your resources for an operation that just occurred.
There are also several application testers such as JMeter from Apache located at http://www.jakarta.apache.org/jmeter.
Check out http://www.opensourcetesting.org/performance.php for a list of open-source stress-testing tools. Finally, make
sure that your hardware and memory are sufficient for the web application.

10 .Review controls surrounding maintaining a secure configuration.

This is a catch-all that addresses configuration management, the overarching concept of maintaining the secure
configuration of the web server. Failure to maintain a secure configuration subjects the web server to lapses in technology
or processes that affect the security of the web platform and web application.
How
Perform the web platform audit, and discuss any issues noted with the administrator. Determine if any of the issues noted
are due to inadequate configuration management. Discuss the following with the administrator to ensure that proper
configuration management controls are in place:

Security mailing lists for the web server, platform, and application are monitored.

The latest security patches are applied in a routine patch cycle under the guidance of written and agreed-to
policies and procedures.

A security configuration guideline exists for the web servers in the environment and is strictly followed.
Exceptions are carefully documented and maintained.

Regular vulnerability scanning from both internal and external perspectives is conducted to discover new risks
quickly and to test planned changes to the environment.

Regular internal reviews of the server's security configuration are conducted to compare the existing
infrastructure with the configuration guide.

Regular status reports are issued to upper management documenting the overall security posture of the web
servers.

Having a strong server configuration standard is critical to a secure web application. These servers have
many configuration options that affect security and are not secure out of the box. Taking the time to
understand these options and how to configure them to your environment is fundamental to maintaining
sound and secure web servers.

Tools and Technologies

There are several reasons why an automated product will fail to thoroughly audit every possible component of your web
server. Code reviews actually may be very fast for experienced coders, but this depends on many variables. For example,
how experienced is the coder? How well does the reviewer understand the web application? How well does the reviewer
understand the constructs of the programming language used for the application? How complex is the application? What
external interfaces exist, and how well does the reviewer understand these external interfaces? If you live and play in this
world, then code reviews may be easy for you. If you live and play in many worlds, then you may want to consider
augmenting your searches with automated tools.
Note

Automated tools can be quite harmful to production environments. Exercise care, and design

the test in a manner that will not affect production systems.

Automated tools can be quite helpful and guide you toward parts of your web platform or web application that might need
further review. A strong case could be made that new applications should be tested with good code reviews and tools
such as those listed below. This list only scratches the surface of what's out there. Many general vulnerability scanners
also test commonly exploited vulnerabilities for web platforms. There are many web testing tools available. Here is a small
list of web tools:

Acunetix: http://www.acunetix.com
Web Sleuth: http://www.sandsprite.com/Sleuth
Paros Proxy: http://www.parosproxy.org
Web Inspect: http://www.spidynamics.com/products/webinspect
nikto: /http://www.cirt.net/code/nikto.shtml
XSS NASL plugin for Nessus: http://www.cirt.net/code/nessus.shtml
JMeter: http://www.jakarta.apache.org/jmeter

Knowledge Base

Apache website: http://www.apache.org/

Microsoft IIS website: http://www.microsoft.com/windowsserver2003/iis
IIS answers: http://www.iisanswers.com/
OWASP "top ten" vulnerabilities to check for when looking at your web server:

http://www.owasp.org/index.php/OWASP_Top_Ten_Project
CGI security: http://www.cgisecurity.net/
Securing IIS: http://www.microsoft.com/technet/security/prodtech/IIS.mspx
Windows Server 2003 Security Guide: The web server role:

http://www.microsoft..com/technet/security/prodtech/windowsserver2003/w2003hg/s3sgch09.mspx
Story about the history of the World Wide Web from Microsoft's perspective:

http://www.microsoft.com/misc/features/features_flshbk.htm
General story about the history of the World Wide Web:
http://www.computerworld.com/developmenttopics/websitemgmt/story/0,10801,73525,00.html

Master Checklists
Auditing Web Servers
Checklist for Auditing Web Servers
1. Verify that the web server is running on a dedicated system and not in conjunction with other critical
applications.
2. Verify that the web server is fully patched and updated with the latest approved code.
3. Determine if the web server should be running additional tools to aid in the protection of the web server.
4. Verify that unnecessary services or modules are disabled. Running services and modules should be running
with least privileged accounts.
5. Verify that only appropriate protocols and ports are allowed to access the web server.
6. Verify that accounts allowing access to the web server are managed appropriately and hardened with strong
passwords.
7. Ensure that appropriate controls exist for files, directories, and virtual directories.
8. Ensure that the web server has appropriate logging enabled and secured.
9. Ensure that script extensions are mapped appropriately.
10. Verify that unnecessary or unused ISAPI filters are removed from the server.

11. Verify the validity and use of any server certificates in use.
Auditing Web Applications
Checklist for Auditing Web Applications
1. Verify that all input is validated prior to use by the web server.
2. Verify that proper authorization controls are enforced.
3. Broken authentication and session management
4. Review the website for cross-site scripting vulnerabilities.
5. Verify that the server is updated with all known patches for buffer overflows.
6. Ensure that the web application is protected against injection attacks.
7. Evaluate the use of proper error handling.
8. Ensure that secure storage mechanisms are used correctly and appropriately.
9. Determine the use of adequate controls to prevent denial of service.
10. Review controls surrounding maintaining a secure configuration.