OWASP6thAppSec TestingGuidev2 MatteoMeuci
OWASP6thAppSec TestingGuidev2 MatteoMeuci
1 Introduction
Penetration testing will never be an exact science where a complete list of all
possible issues that should be tested can be defined. Indeed, penetration testing is
only an appropriate technique for testing the security of web applications under
certain circumstances. The goal is to collect all the possible testing techniques,
explain them and keep the guide updated. The OWASP Web Application
Penetration Testing method is based on the black box approach. The tester knows
nothing or very little information about the application to be tested.
We have split the set of tests in 8 sub-categories:
• Information Gathering
• Business Logic Testing
• Authentication Testing
• Session Management Testing
• Data Validation Testing
• Denial of Service Testing
• Web Services Testing
• AJAX Testing
Each of these categories is further divided in a series of chapters, each of which
describes a specific type of test, providing examples, screenshots, tools and links
to additional information. In the following sections, a general overview of each
category is provided.
Business logic can have security flaws that allow a user to do something that isn't
allowed by the business. For example, if there is a limit on reimbursement of
$1000, could an attacker misuse the system to request more money than is
allowed? Or perhaps you are supposed to do operations in a particular order, but an
attacker could invoke them out of sequence. Or can a user make a purchase for a
negative amount of money? Frequently these business logic security checks simply
are not present in the application. Automated tools find it hard to understand
context, hence it's up to a person to perform these kinds of tests.
3.3 Authentication
At the core of any web-based application is the way in which it maintains state and
thereby controls user-interaction with the site. Session Management broadly
covers all controls on a user from authentication to leaving the application. HTTP
The most common web application security weakness is the failure to properly
validate input from the client or environment. This weakness leads to almost all of
the major vulnerabilities in applications, such as interpreter injection,
locale/Unicode attacks, file system attacks and buffer overflows. Data from any
external entity/client should never be trusted for an external entity/client has every
possibility to tamper with the data: "All Input is Evil" says Michael Howard in his
famous book "Writing Secure Code". That's rule number one. The problem is that
in a complex application the points of access for an attacker increase and it is easy
that you forget to implement this rule. In this chapter we describe how to test all
the possible forms of input validation to understand if the application is strong
enough against any type of data input. We split Data Validation into these macro
categories:
• Cross Site Scripting
• HTTP Methods and XST
• SQL Injection
• LDAP Injection
• ORM Injection
• XML Injection
• SSI Injection
• XPath Injection
• IMAP/SMTP Injection
• Code Injection
• OS Commanding
The most common type of denial of service (DoS) attack is the kind used on a
network to make a server unreachable by other valid users. The fundamental
concept of a network DoS attack is a malicious user flooding enough traffic to a
target machine, that it renders the target incapable of keeping up with the volume
of requests it is receiving. When the malicious user uses a large number of
machines to flood traffic to a single target machine, this is generally known as a
distributed denial of service (DDoS) attack. These types of attacks are generally
beyond the scope of what an application developer can prevent within their own
code. This type of “battle of the network pipes” is best mitigated via network
architecture solutions.
There are, however, types of vulnerabilities within applications that can allow a
malicious user to make certain functionality or sometimes the entire website
unavailable. These problems are caused by bugs in the application, often resulting
from malicious or unexpected user input. This section will focus on application
layer attacks against availability that can be launched by just one malicious user on
a single machine.
Here are the DoS testings we talk about:
• Locking Customer Accounts
• Buffer Overflows
• User Specified Object Allocation
• User Input as a Loop Counter
• Writing User Provided Data to Disk
• Failure to Release Resources
• Storing too Much Data in Session