Auditing Web Servers and Web Applications

Introduction
• The concept known as the World Wide Web
began in the late 1980s
• As the Internet has evolved, web services have
become more and more complex, supporting
rich, interactive experiences, mobile
applications, and more. 
• While application models can vary, some basic
principles of web service controls can apply to a
wide range of systems.
• Businesses rely on web applications to
connect with customers via websites, to
manage human resources systems, for e-mail
and collaboration, and more. 
• Today, nearly every business has an online
presence in the form of one or more websites,
and many key business processes rely on web
technology.
 WEB AUDITING ESSENTIALS
• Like much of auditing, assessing a web server is not an
exact science. 
• Many different types of web servers are in use (servers
running on Apache, nginx, or Microsoft Internet
Information Services are the most common) and
millions of different applications rely on web services. 
• The wide variety of systems reliant on web services can
complicate an audit; you can simplify the situation by
sticking to the basics, which are applicable to almost
any web-based system.
•  A higher and higher percentage of web traffic
is application related today, with systems
exposing application programming interfaces
(APIs) as web services.
• An organization with a strong security
program will have a number of additional
controls designed to protect web servers.
• Web Auditing Components
 TEST STEPS FOR AUDITING WEB SERVERS
1. Verify that the web server is running on a dedicated logical
system not shared with other critical applications. 
• A compromised web host may allow the attacker to
compromise other applications on your server. 
• Use a dedicated logical machine for your web server, either in
the form of a separate physical host or, more likely, a separate
virtual machine. 
•  Carefully consider the legitimate business need to allow other
applications to remain on the same host as the web server. 
• If these applications must coexist, consider bringing each of
the additional applications into the scope of the audit.
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 an unnecessary risk of compromise from
vulnerabilities that could have been patched with
updated code releases.
• Every organization has its own patch management
systems and policies.
• Review the policies and procedures for ensuring that
systems are kept up to date with the latest code
releases. 
3. Verify that unnecessary services, modules, objects, and APIs are
removed or disabled. Running services and modules should be
operating under the least privileged accounts.
• Unnecessary services, modules, objects, and APIs present an
additional attack surface area, resulting in more opportunities for
malicious attackers and malware.
• Verify that File Transfer Protocol (FTP), Simple Mail Transport Protocol
(SMTP), Telnet, extra server extensions, and Network News Transfer
Protocol (NNTP) services are disabled if they are not required (many
of these are also covered under host operating system audits). 
• Review logs and configuration files to validate that only necessary
modules are enabled. Question the need for anything else that might
be running.
4. 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.
• In addition, we should examine the broader network
protections in place for defending against web server
attacks. Some common defenses include:
a. Web application firewall (WAF): A WAF is an
application-aware firewall that examines web
requests for malicious content. A WAF can be
installed as a stand-alone device, as a feature in other
firewalls, as an add-on module for a web server, or as
a third-party, network-based service. 
b. Reverse proxy: A reverse proxy is a special
kind of intermediary web server that
processes requests from the outside and
directs them appropriaReverse proxies can be
used as firewalls to enable very limited traffic
patterns to the target web system.
c. Denial-of-service (DoS) prevention: In a DoS
attack, a system is overloaded with requests,
causing a crash or other unpredictable
behavior.
d. Bot defenses: Some bots, such as those used
by popular search engines, may be beneficial
in indexing content for the Internet; some
bots are malicious in nature and crawl sites
looking for vulnerabilities to exploit.
5. Verify that accounts allowing access to the web server
are managed appropriately and use strong passwords. 
• Inappropriately managed or used accounts could
provide easy access to the web server, bypassing
other additional security controls that prevent
malicious attacks. 
• This is a large step with a wide scope, covering
controls around account use and management.
• The default administrator account on Windows
servers should be renamed, and all accounts should
be restricted from remote login except for those used
for administration.
6. 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 a web server
compromise.
• Verify that files and directories have
appropriate permissions, especially those
containing the following:
a. Website content 
b. Website scripts
c. System files
d. Tools, utilities, and software development
kits
7. Ensure that unnecessary information such as
version and directory listings are not exposed
through the web interface. 
• Web servers that expose information
unnecessarily can leak sensitive data or
make it easier for attackers to find
vulnerabilities.
• Simple settings in server configuration can
be checked to verify that information is not
exposed.
8. Ensure that the web server has appropriate logging
enabled and that monitoring processes are in place.
• Logging auditable events helps administrators
troubleshoot issues. 
• Logging also allows incident response teams to gather
forensic data.
• Web servers can be expected to have logs related to
login and access events that include user information,
IP addresses, and other data.
• High-value web servers, including those with sensitive
or regulated data, should have their logs transferred to
a central log storage and analysis facility.
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.
• 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.
10. Verify the validity of any server certificates in
use. 
• Server-side certificates enable clients to
trust your web server’s identity. 
• Old or revoked certificates may prevent
end users from visiting your site or may
produce warnings or errors.
 TEST STEPS FOR AUDITING WEB
APPLICATIONS
1. Ensure that the web application is protected against
injection attacks. 
• Injection attacks occur when an attacker adds
unexpected commands or queries to expected
parameters, tricking the application into
performing a different task. 
• A common type of injection attack is called SQL
injection, where Structured Query Language (SQL)
commands are inserted into web forms or other
fields.
• Using SQL injection, an attacker can cause an
application to delete data, add new data, or
execute other commands against the database.
•  Many websites have exposed credit card and
Social Security 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.
• Some of the methods provided next are also
helpful in protecting against other attacks:
a. Validate all inputs and reject any data that
does not match the expected input, such as
values, length, and character sets. 
b. Perform a code review, if possible, for all calls
to external resources to determine whether
the method could be compromised.
• Open-source and commercial scanning tools are
available that may help find injection
vulnerabilities.
• Consider hiring third-party help if the
application is particularly sensitive, if you lack
the resources, or if you need to verify items
such as regulatory compliance.
2. Review the application for authentication and
session management vulnerabilities. 
• 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 and level of
authorized access.
3. Verify that sensitive data is identified and
protected appropriately. Ensure proper use of
encryption technologies to protect sensitive
data.
• Web applications may handle extremely
sensitive information, such as health
records, financial data, company secrets,
and more.
• Sensitive data must be identified and
handled appropriately.
4. Review the web server for exposure to XML
external entities (XXE) attacks. 
• Applications that accept or process Extensible
Markup Language (XML) data could be
vulnerable to XXE. 
• A malicious actor could construct an XML file
with commands seeking to extract sensitive data
from a system or perform other commands. 
•  A recent addition to the OWASP list, XXE attacks
aren’t as widely known as others like injection.
5. Verify that proper access 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) to each object may allow an
attacker to step out of authorized boundaries,
accessing other users’ data or unauthorized
areas.
6. 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
7. Review the website for cross-site-scripting
vulnerabilities. 
• 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 disclosing end-user files,
installing Trojan horse programs, redirecting the
user to some other page or site, and modifying the
presentation of content.
8. Review protections against exploitation of
deserialization sequences. 
• While somewhat challenging to exploit, the
impact of a successful attack can result in the
complete compromise of a system. 
• This type of issue can occur when an
application processes a sequence of data
passed as part of a command or request. 
• If an attacker is able to manipulate the request
and pass unexpected data as part of the query,
the application may not execute as expected.
9. Review processes to ensure vulnerabilities are not
present in libraries, frameworks, or other
components.
• While any application may have hidden, difficult-
todiscover vulnerabilities, you can greatly improve
your defensive posture by ensuring that already-
known vulnerabilities are not present.
• The complexity of modern websites can make this a
difficult task, as shared frameworks, libraries,
databases, and other dependencies significantly
expand the opportunity for vulnerabilities to exist in
the site.
10. Ensure that adequate logging is present and
review processes for examining log data. 
• We should ensure that web systems are
logging correctly and that the organization
is able to identify and respond to adverse
activity.
• High-value web servers, including those
with sensitive or regulated data, should
have their logs transferred to a central log
storage and analysis facility.
11. Review the security training provided to application
development teams and ensure that development teams
understand secure coding practices. 
• Development teams with proper security training can avoid
many of the application vulnerabilities found in websites.

12. 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.
13. 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.

14. Review web application redirects and forwards to

verify that only valid URLs are accessible.
• Using an unvalidated redirect, attackers may be
able to redirect users to the attacker’s website
using a URL that looks as if it comes from your
domain.