Security - CL3 Flashcards
Application Security Audit
Standalone Vulnerability Scanners
A number of different tools exist for performing completely automated vulnerability scans of web applications. These scanners have the benefi t of being able
to test a large amount of functionality in a relatively short time. In a typical
application they often can identify a variety of important vulnerabilities.
Standalone web application vulnerability scanners automate several of the
techniques we have described in this book, including application spidering,
discovery of default and common content, and probing for common vulnerabilities. Having mapped the application’s content, the scanner works through
its functionality, submitting a range of test strings within each parameter
of each request, and analyzes the application’s responses for signatures of
common vulnerabilities. The scanner produces a report describing each of
the vulnerabilities it has discovered. This report usually includes the specifi c
request and response that the application used to diagnose each reported
vulnerability, enabling a knowledgeable user to manually investigate and
confi rm the bug’s existence.
A key requirement when you are deciding whether and when to use a
vulnerability scanner is to understand the inherent strengths and weaknesses of these types of tools and the challenges that need to be addressed
in the course of developing them. These considerations also affect how you
can effectively make use of an automated scanner and how to interpret and
rely on its results.
Vulnerabilities Detected by Scanners
Several categories of common vulnerabilities can be detected by scanners with
a degree of reliability. These are vulnerabilities with a fairly standard signature.
In some cases, the signature exists within the application’s normal requests and
responses. In other cases, the scanner sends a crafted request designed to trigger the signature if the vulnerability is present. If the signature appears in the
application’s response to the request, the scanner infers that the vulnerability
is present.
Here are some examples of vulnerabilities that can be detected in this way:
- Refl ected cross-site scripting vulnerabilities arise when user-supplied input
is echoed in the application’s responses without appropriate sanitization.
Automated scanners typically send test strings containing HTML markup
and search the responses for these strings, enabling them to detect many
of these fl aws.
- Some SQL injection vulnerabilities can be detected via a signature. For
example, submitting a single quotation mark may result in an ODBC error
message, or submitting the string ‘; waitfor delay ‘0:0:30’– may
result in a time delay.
- Some path traversal vulnerabilities can be detected by submitting a traversal sequence targeting a known fi le such as win.ini or /etc/passwd
and searching the response for the appearance of this fi le.
- Some command injection vulnerabilities can be detected by injecting a
command that causes a time delay or echoes a specifi c string into the
application’s response.
- Straightforward directory listings can be identifi ed by requesting the
directory path and looking for a response containing text that looks like
a directory listing.
- Vulnerabilities such as cleartext password submission, liberally scoped
cookies, and forms with autocomplete enabled can be reliably detected
by reviewing the normal requests and responses the application makes.
- Items not linked from the main published content, such as backup fi les
and source fi les, can often be discovered by requesting each enumerated
resource with a different fi le extension.
In many of these cases, some instances of the same category of vulnerability
cannot be reliably detected using a standard attack string and signature. For
example, with many input-based vulnerabilities, the application implements some
rudimentary input validation that can be circumvented using crafted input. The
usual attack strings may be blocked or sanitized; however, a skilled attacker can
probe the input validation in place and discover a bypass to it. In other cases, a vulnerability may be triggered by standard strings but may not result in the
expected signature. For example, many SQL injection attacks do not result in any
data or error messages being returned to the user, and a path traversal vulnerability may not result in the contents of the targeted fi le being directly returned
in the application’s response. In some of these cases, a sophisticated scanner may
still be able to identify the vulnerability, or at least note some anomalous behavior
for manual investigation, but this is not feasible in all cases.
Furthermore, several important categories of vulnerabilities do not have a standard signature and cannot be probed for using a standard set of attack strings.
In general, automated scanners are ineffective at discovering defects of this kind.
Here are some examples of vulnerabilities that scanners cannot reliably detect:
- Broken access controls, which enable a user to access other users’ data,
or a low-privileged user to access administrative functionality. A scanner does not understand the access control requirements relevant to the
application, nor can it assess the signifi cance of the different functions
and data it discovers using a particular user account.
- Attacks that involve modifying a parameter’s value in a way that has
meaning within the application — for example, a hidden fi eld representing
the price of a purchased item or the status of an order. A scanner does not
understand the meaning that any parameter has within the application’s
functionality.
- Other logic fl aws, such as beating a transaction limit using a negative
value, or bypassing a stage of an account recovery process by omitting a
key request parameter.
- Vulnerabilities in the design of application functionality, such as weak
password quality rules, the ability to enumerate usernames from login
failure messages, and easily guessable forgotten-password hints.
- Session hijacking attacks in which a sequence can be detected in the application’s session tokens, enabling an attacker to masquerade as other users.
Even if a scanner can recognize that a particular parameter has a predictable value across successive logins, it will not understand the signifi cance
of the different content that results from modifying that parameter.
- Leakage of sensitive information such as listings of usernames and logs
containing session tokens.
Some vulnerability scanners attempt to check for some of these vulnerabilities.
For example, some scanners attempt to locate access control bugs by logging
into an application in two different user contexts and trying to identify data
and functions that one user can access without proper authorization. In the
authors’ experience, checks such as these typically generate a huge number of
false positive and false negative results.
Within the previous two listings of vulnerabilities, each list contains defects
that may be classifi ed as low-hanging fruit — those that can be easily detected
and exploited by an attacker with modest skills. Hence, although an automated
scanner will often detect a decent proportion of the low-hanging fruit within
an application, it will also typically miss a signifi cant number of these problems — including some low-hanging fruit that any manual attack would detect!
Getting a clean bill of health from an automated scanner never provides any
solid assurance that the application does not contain some serious vulnerabilities
that can be easily found and exploited.
It is also fair to say that in the more security-critical applications that currently exist, which have been subjected to more stringent security requirements
and testing, the vulnerabilities that remain tend to be those appearing on the
second list, rather than the fi rst.
Finding Vulnerabilities in Source Code
Many types of web application vulnerabilities have a fairly consistent signature
within the codebase. This means that you can normally identify a good portion of an application’s vulnerabilities by quickly scanning and searching the
codebase. The examples presented here appear in various languages, but in
most cases the signature is language-neutral. What matters is the programming
technique being employed, more than the actual APIs and syntax.
Cross-Site Scripting
In the most obvious examples of XSS, parts of the HTML returned to the user
are explicitly constructed from user-controllable data.
SQL Injection
SQL injection vulnerabilities most commonly arise when various hard-coded
strings are concatenated with user-controllable data to form a SQL query, which
is then executed within the database.
Path Traversal
The usual signature for path traversal vulnerabilities involves user-controllable
input being passed to a fi lesystem API without any validation of the input or
verifi cation that an appropriate fi le has been selected. In the most common
case, user data is appended to a hard-coded or system-specifi ed directory path,
enabling an attacker to use dot-dot-slash sequences to step up the directory tree
to access fi les in other directories.
Arbitrary Redirection
Various phishing vectors such as arbitrary redirects are often easy to spot
through signatures in the source code.
OS Command Injection
Code that interfaces with external systems often contains signatures indicating code injection fl aws.
Backdoor Passwords
Unless they have been deliberately concealed by a malicious programmer,
backdoor passwords that have been used for testing or administrative purposes
usually stand out when you review credential validation logic.
Native Software Bugs
You should closely review any native code used by the application for classic
vulnerabilities that may be exploitable to execute arbitrary code.
