6.

1 Introduction

6.2 Common Vulnerabilities

6.3 Bypassing Authorization

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Authentication is the process of determining whether
someone is really who they claim to be. This protection
mechanism ensures that contents are accessed only if the
user or the application has the rights to do so.
For example, web applications often rely on username and
password pair to authenticate users.
This is the easiest way to authenticate.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Before starting inspecting the security implications and
vulnerabilities, it is important to keep in mind the difference
between Authentication and Authorization.
Although the two terms are used interchangeably, they are
very different:
• Authentication is the process of verifying who you are.
• Authorization is what you are able to do: authorization
attacks have to do with accessing information that the
user does not have permission to access.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
An authentication factor represents something the user
owns, knows, or is. We can distinguish the three different
types of authentication factors:

Ownership Knowledge Inherence

factors factors factors

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Something the Something the Something the

Knowledge factors
Ownership factors

Inherence factors
user has. user knows. user is.
E.g. Security E.g. password, E.g. fingerprint,
token, mobile PIN, secret signature, face,
phone, bank question retinal pattern
online token

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The single-factor authentication method requires a user to
provide one of the three authentication factors we just saw.
It is the most common method used by web applications that
offer simple services.
A typical single-factor authentication implementation
requires that a user provides only the password (ownership
factor) for the system to authenticate them.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The two-factor (or multi factor authentication - MFA)
authentication system requires a user to provide two or more
of the three authentication factors.
For example, when you go to an ATM machine, you use two
factors:
• Something you know: the PIN
• Something you have: the credit/ATM card

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Given how popular mobile phones are, it is becoming
increasingly popular to have web applications that use the
mobile phone as the second factor after the password.
This is typically implemented by web applications that send
an SMS message to the user (or use their own mobile
application) with the PIN that the user must type on the
website.
A real-world example of this is Google's 2-step verification.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
In this chapter, we will analyze some typical vulnerabilities of
web applications authentication systems that use single-
factor authentication. Let us restrict our analysis to the most
commonly-used factor: the knowledge factor.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A web application requiring authentication of its users
(usually username and password pair) must be cognizant of
the way in which data is transferred in or out.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If the channel is not encrypted, an attacker, acting as a
man-in-the-middle, can steal all the user’s provided
information, including credentials.

POST Request to http://wapt.els.com/login.php

?user=mike&password=password

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Passwords represent a critical aspect of the authentication
system.
A simple password can be easily guessed likewise, even a
short password with a special character can be easily brute-
forced. A long password can be guessed, if it is a dictionary
word, using a dictionary attack.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Generally, if a password does not adhere to a strong
password policy, it is exposed to attacks such as:

Dictionary attack Brute-force attack

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Dictionary attack

This type of attack involves the attacker querying the

authentication system with a set list of words (wordlists).
The list of words are all derived from a standard dictionary
and can be language-oriented (English, Italian, etc.) or role-
oriented (business, IT, etc.).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Dictionary attack

User-chosen password are often called the weakest link in the

security chain, because, typically, people do not like to use a
long password. They prefer short passwords that they can
remember and are very common.
Furthermore, over the years, there have been many data
breaches against many websites, and some of the password
lists have been leaked and merged with these lists.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Dictionary attack

The goal of this attack is to guess passwords by selecting

words from the dictionary.
The following are some resources of common wordlists:
• Openwall
• Seclist
• SkullSecurity

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Brute-force attack

This attack tries to use every possible combination of

characters to guess the password. Due to its nature, it takes a
long time to complete; generally the attacker chooses to
perform this attack only if the dictionary attack has failed.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Brute-force attack

The number of attempts depends upon the character domain

and password length (charset).
For example, if the character domain is [a-zA-Z0-9] and the
password length is 8, the max number of attempts will be
62^8 ~= (218*10^12).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the following slides we will see a few different techniques
to enforce password policies.
Remember that you are a professional Penetration Tester,
thus, in addition to attacking and discovering the target Web
Application vulnerabilities, you will also provide a
remediation report to you clients.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Strong Password Policy

A strong password policy should let the user choose his

password while adhering to the following rules:
Do not include
Length: at least 10
Composition personal information
characters
• At least one uppercase char
and dictionary words
• At least one lowercase char
• At least one digit char Change password
Never use the same • Special characters (% $ ;) regularly (monthly,
password twice
annually)
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Storing Hashes

From the server-side perspective, passwords must never be

stored in clear text.
If an attacker gains access to a password repository full of
clear text passwords (such as a database), they will be able to
access any victim’s account with the discovered credentials.
Passwords need to be hashed (preferably with a salt) before
they are stored.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Lockout/Blocking Requests

To avoid brute-force and dictionary attacks, a system can be

designed to block authentication requests coming from
attackers.
A typical example of good system design is a system that:
• Adds an increasing delay after each failed login attempt
• After 3 failed attempts show a CAPTCHA puzzle
• After 10 failed attempts locks the user for a certain amount
of time
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Generally, web application authentication mechanisms
accept: a user identifier (this identifies unambiguously the
user against the system) and a secret word (a password),
known by only the user.
A user can correctly authenticate to the system only if the
credentials (both user and password) are correct.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A badly designed system can reveal sensitive information
even if wrong credentials have been inserted.
For example, a web application could reveal information
about the existence of a user.
It is important to note that while determining valid user
names is something not considered a serious threat, user
names are half of what is needed to login.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

An example of badly handled incorrect login messages is:

Login for user foo: invalid password

Login failed, invalid user ID

Login failed; account disabled

Login failed; this user is not active

All these messages reveal that the provided user is correct.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
The following is an example of how handle the above
situation correctly:
Login failed; Invalid user ID or password

This does not inform the attacker on which credential is

wrong and makes enumeration more difficult.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Some applications may not display the previous messages
but, have a distinct behavior depending on user existence. An
attacker that identifies these behaviors may attack the web
app via user enumeration. The following are some examples:

User does not exist User exists

Cookies are deleted Cookies are not deleted or a new Cookie is set
User goes to a known fixed page User goes to a user-specific page
The HTML is fixed The HTML changes or is different from an invalid user

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Most of the time, when a user exists in the database there
will be more processing, for example:
• User does not exist in the DB: show error + abort
• User exists in the DB: retrieve user, calculate password,
check if the password matches
Because of this, it may be possible to perform user
enumeration by timing how long it takes to the application to
send a response.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This type of vulnerability can be exploited and allow an
attacker to discover whether a user is present on the system.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Once this information is available to the attacker, he can
perform any attack requiring the username component, such
as:
• A dictionary (or brute force) attack against the password
to discover the user’s password.
• A password reset for that user if the system suffers from a
weakness in the password reset feature.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

We can automate this username enumeration process with
tools such as Burp Suite. Note that this same approach can be
re-used for password cracking purposes once we have a pool
of existing usernames.
The first order of business is to determine whether the target
website is vulnerable or not.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In order to perform user enumeration, a login page should
return different messages based on the submittal of a pair of:
• correct username - wrong password
• wrong username - wrong password
We are assuming that we do not know the password.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Note that we are looking for differences with the two
different cases, not only in the web page’s visible content, but
also, the URL, cookies or web page source. Any difference can
be fingerprinted and used at our disposal to differentiate a
correct from an incorrect guess.
Burp Comparer is the tool in Burp Suite that finds visual
differences between two responses.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us activate Burp proxy, set up our Browser to use Burp as
the proxy, and define our scope as we have previously done.
From the Target tab, make sure to click on Filter and check
show only in-scope items.
Then, back to the browser to make two subsequent login
requests
• one using a valid username (we should have at least one
valid username to start our enumeration attack)
• and another using a bogus one
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
In this example foo is an incorrect guess, while John is a real
username.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The difference here is easy to find. We receive an explicit
Invalid Username message when the username is not valid. In
contrast, when it is valid we receive an Invalid Password
message (the passwords can be entered randomly).
Back to Burp suite, we will see our requests and related
responses being collected in the Site map subtab of the Target
tab.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

We will locate the two requests (usually they are POST
requests) and right-clicking on them and then "Send them to
Comparer (responses)".
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
When Comparer appears, we will be able to click on Word to
make a word-by-word comparison and we will receive the
visual difference between the two requests.
At this point, we must be able to easily spot any differences
between the two requests that will let us differentiate them.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Here we can see the differences between the two responses.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Our enumeration attack will take place in the Burp Intruder
tab. To do this let us go to the Target tab and by right clicking
on one of the POST requests we will pick Send to intruder.
From the Intruder we will be able to fuzz the application using
wordlists or brute force attacks.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

We will have to instruct Burp on:
• Which parameter we want to brute force/fuzz
• The type of payload we want to use (dictionary, pure brute
force, dates, illegal Unicode…)
• What part of the response it will have to keep track to match a
correct guess

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Preparing Parameters

The parameter we want to fuzz is provided from the Positions

subtab of the Intruder tab.
By selecting the parameter and then clicking on Add (or Clear)
we will add (or remove) a single fuzzing point.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In this example, we want to fuzz the username. So we will
add a position to the username parameter.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Preparing Payloads

The type of payload we want to use is chosen from the

Payloads subtab.
We can use a set of pure brute force parameters by defining
the charset to use, but we can also use wordlists and much
more. You just need to select it from the Payload type
dropdown menu. In our tests we will use a Simple list.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

As you can see, in the Payload
Options there is a list of
common usernames. We used
the Load button in order to
read usernames from a file.
Burp automatically reads each
line of the file and fills the list.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Matching Patterns

The difference between a correct and an incorrect guess is

used by Burp to check whether a username has been
enumerated or not.
We will give this information in the Options subtab.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

We are telling Burp to mark
a guess as correct, when the
text Invalid password is
found in the web page
content.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Start!

Finally we can launch the attack from the Intruder menu,

clicking on Start.
This is the result with the valid usernames found checked.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

As we can see in the results window, two usernames have
been enumerated: admin and guest.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The check in the Invalid password column stands for a valid
match for that pattern in the web page content/headers.
We will save this information for later use, when we try to
brute force passwords instead of usernames.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Another perspective that an attacker should never
underestimate is the use of default credentials: known
usernames and passwords that may be present in some
software packages and require explicit user intervention to be
removed or changed.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Publicly known default credentials can quickly result in
compromise, as illustrated by bAdmin, Phenoelit and CIRT.
Testing for default credentials requires two simple steps:
1• Identify all the components of the target website that may
require credentials
2• Search for default password against the components
identified

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Many open source web applications (for example CMSs) are
provided with predefined user accounts. The administrator
might forget to change these account credentials.
In this case, an attacker can easily use the default credentials
to log in to the system by simply reading the application
documentation.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In other cases, a web developer could create test user
accounts and forget to delete them.
These accounts can be easily guessed if the developer applies
an inadequate policy to generate the credential pair.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Typical default credential values:
Usernames Password
administrator <blank>
admin password
root pass123
guest guest
system adminpassword
test 1234

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Having users login each time is inconvenient, for this reason
many websites implement the "remember me" feature.
When this feature is in place, and after a successful user
authentication, the web application does not ask the user to
log in (usually for a specified period of time).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The password remember feature can be implemented
through the following methods:

By storing credentials By storing the

Through the
permanently within credentials
browser cache
the web storage within a cookie

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The password input element, as with any other sensitive
information, must not be cached. If the attacker can access
the browser cache, he will be able to steal the password.
This is a typical scenario in public internet cafés, where a pc is
accessed by different people.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The cache browser method relies on HTML syntax. The
following HTML code enables the browser to cache the
password.

INPUT TYPE="password" AUTOCOMPLETE="on"

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The cookie method makes use of cookies to store credentials
therefore, the password will be stored in a cookie and sent
through the HTTP Cookie header.
Alternatively, a token might be stored in the Cookie. This is a
better feature, as the token can be given an expiration that is
much shorter than the expiration of the user’s password.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The security concern here is that an attacker could steal the
cookie through the following attacks:
• XSS attack only if the cookie has not been marked with the
flag HTTPOnly.
• Session hijacking via packet sniffing only if the cookie is
sent over an unencrypted channel.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

When the cookie is obtained, access to the user’s account is
obtained as well.
Please note that in this case, the value stored in the cookie
might have a much longer life (even 30 days) compared to a
session cookie (which usually expires in minutes or hours).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A web developer could rely on local storage to store
credentials. The developer would use the API call
localStorage.setItem() to add an item containing
credential data to local web storage.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web storage is a data container accessible and writable by all
pages sharing the same origin therefore, an attacker could
access web storage after a successful XSS attack.
If the password has been stored unencrypted, the attacker
could obtain the victim’s password.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

1) Cache Browser Method Defense

The autocomplete HTML attribute instructs the browser on

whether storing certain form information is allowed or not.
You must use the following HTML code to disable the cache
for the HTML password element.
<INPUT TYPE="password" AUTOCOMPLETE="off">

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

2) Cookie Method Defense

If the cookie contains the user password, the password must

be encrypted before storing it within the cookie.
Keep in mind that a cookie can be easily stolen (for example,
via XSS exploit) and installed on a different browser.
In other words: if the attacker can steal the "Remember me"
cookie, he can impersonate the victim without knowing the
actual password.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
3) Web Storage Method Defense

The same applies for Web storage; if the web storage

contains the user password, it must be encrypted, first.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Users who forget their passwords must have a proper and
safe way to reset it. The issue unfortunately is, that they have
forgotten the only piece of data that could authenticate them
against the web application. What can we do?

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Depending on the criticality of the web application, there are
many approaches to implementing a good reset feature.
Generally, it is implemented by sending an email to the user
with a new password or a link to trigger the password reset
function.
As a first step, a web application could ask one or more secret
questions before sending the email.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Secret questions are a critical component in authentication
mechanisms. When implemented, they are set by the account
owner during the account setup phase and will be used
during a password reset process.
They are just like "another password" and they are usually
the weakest link in the authentication system.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

They should be known only by the owner of the user account
and should not be guessable by others. The secret question is
chosen by the user during the setup of his account; a web
application cannot control the secret question but, can
suggest recommendations to the user to avoid easily
guessable answers.
Let us analyze some typical vulnerabilities.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To avoid dictionary or brute force attacks, the web application
must limit the answer attempts and then block the requests
coming from a malicious user. This feature can be easily
implemented by counting a user’s incorrect attempts and
blocking the IP after several consecutive tries.
Of course, an IP can always be changed by the attacker
through proxies or the TOR network.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

An attacker could easily guess the answer of a question if:
Its response has a public answer (Google, book, etc.)
• Example: How many people live in Rome?

Its response has a private answer but is easily guessable (i.e. social engineering)
• Example: What’s your mother’s name?
• Example: What was your first car?

Its response has a limited domain

• Example: Which country do you prefer?
• Example: Which fruit do you prefer?

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A web application should never allow unlimited attempts to
answer a secret question. An attacker could try a dictionary
or brute-force attack to guess the answer.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In many password reset implementations, the password reset
protocol requires the user to click a link (usually received via
email), which triggers the password reset.

Enter your Email: [email protected]

Reset Password Password Reset Link

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In this case, the link must be accurately created. Here are a
few typical weaknesses:

Typical Weaknesses of Password Reset Links

Guessable Recyclable
password reset password reset
Predictable
link link
password reset
token

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web applications should create the password reset link and
maintain the following rules:
• The link should contain a token
• The token should abide to the following rules:
• Minimum length N characters: N>6
• Wide Character Set: For example [A-Za-z0-9]
• Purely random and unpredictable
• Subject to expiration soon: 30 or 60 minutes

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Guessable Password Reset Link

The link triggering the password reset does not contain a

random token and it is easily guessable; in most cases it
contains only a reference to the user requesting the password
reset action.
A link structured this way can be easily created by an attacker
and used to reset the password of arbitrary users.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Guessable Password Reset Link
The following is an example of guessable password reset link.
In this case, an attacker only needs the user email address.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Recyclable Password Reset Link

In a recyclable link, the link triggering the password reset can

be used more than once.
If an attacker obtains it, he can reset the victim’s password
even if the link has been already used.
This means that a random token in the password reset link is
not enough; it should also be discarded once it has been
used.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Predictable Password Reset Token

With a predictable token, even if a token is used within the

link, if it is not a “good” random number, it is still a security
issue.
For example: a counter would not be a good token and the
same applies to a timestamp. An attacker could guess which
token will be assigned next and build a link to reset the
victim’s password.
The token must be unpredictable and discarded, once used.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
The term logout refers to the end of a valid web session. A
logout event occurs when the user voluntarily logs out.
Another logout could occur when the user does not perform
an action for a certain amount of time and the application
automatically frees up the resources allocated to that session.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

From the web server perspective, a logout event must
correspond with the de-allocation of the session data,
including the sessionID.
If the web server does not destroy the session data, the
session could be re-used. An attacker, after gaining a session
token used by the victim, could impersonate his account even
if the related session had been correctly logged out of by the
victim.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This type of attack takes the name of Incorrect Session
Destruction because the server does not properly destroy the
session after a logout operation. Some prefer to call it Session
Resurrection; however, from the server’s perspective, the
session is still alive.
Note that we will talk about session security in the next
chapters.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The term CAPTCHA stands for "Completely Automated Public
Turing test to tell Computers and Humans Apart". The
purpose of CAPTCHA is to determine and differentiate
humans from bots, by having the human solve a picture
puzzle.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The main issue when taking into account the CAPTCHA
challenge-response schema, is that it is not easy to create it
from scratch therefore, this may sometimes introduce new
security issues. This also applies to third-party CAPTCHA
schemas too.
In the past there were many weak CAPTCHA implementations
that led to bypassing authentication, XSS, SQL Injection and
much more.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

It is worth to note that there are techniques and tools that
work on both third-party and in-house CAPTCHA schemes:
• Cintruder
• Bypass CAPTCHA with OCR engine
• Decoding CAPTCHA
• OWASP: Testing for CAPTCHA

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Besides automated tools, you should also consider that it is
cheap enough to hire people for breaking CAPTCHA puzzles:
• Virtual sweatshops versus capt
• Spammers use the human touch to avoid CAPTCHA
• Virtual sweatshops defeat Bot-or-Not Tests

For this reason, CAPTCHA should be only considered as a

small added security difficulty against attackers.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
In this section, we will deal with vulnerabilities that allow an
attacker to bypass authorization.
Please note the term bypass. Varying from the previous
chapters, we will not try to find a password; we will instead
try to access protected contents without actually logging in.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Generally, a web application provides a set of public (or
anonymous) pages, accessible by all visitors, and a set of
protected pages only accessible by authorized users (usually
after a login).
If the web developer does not set proper controls on each
protected page, these resources could be accessed even by
unauthorized users.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

An attacker can simply visit a link to the resource with any
browser or change a parameter value that directly refers to
another object. OWASP refers to this type of vulnerability as
Insecure Direct Object References – A4.
This type of vulnerability derives mainly from the web
developer or system engineer’s negligence.
Due to its nature, is very common in custom web
applications.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Imagine that you are authenticated into your government
portal to manage your latest tax paperwork. You are
accessing your report from this URL:
http://taxes-are-beautiful.yeah/report.php?id=123

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You are authorized to view this report, but you should not be
authorized to view other reports. If, by changing the id
parameter, you are able to see reports from other users,
there is an Insecure Direct Object reference.
A reference becomes insecure (the name of the vulnerability)
when the web application does not validate the related input
parameters properly and an attacker can manipulate them to
access other objects.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Each protected page must contain a prologue. The prologue is
a block of code written in a server-side scripting language
(PHP, ASP.NET, JAVA).
The goal of the prologue is to determine if the users are
authorized to access the resource and in case they are not,
terminate script execution which prevents the unauthorized
access from happening.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The following is a very simple example of prologue written in
PHP:

<?
session_start();
if (!isset($_SESSION['logged'])) {
header("Location: http://www.elsfoo.com/login");
die();
}
?>
…
// Protected Content
…

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Missing Function Level Access Control (A7), known in the
OWASP Top 10 -2010 as Failure to Restrict URL Access (A8),
must not be confused with the just saw OWASP A4.
In this case, an attacker can change a parameter or the URL in
order to access privileged functions (not an object like in the
previous examples).
Attackers can usually guess links or bruteforce URLs to find
unprotected pages.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

An example for this could be the URL for the management
interface of a website or for the back-end XML of a web
application:
• http://mysite.site/admin/manage.php
If an non-admin user can access the page, the flaw exists.

Another example is a parameter used to specify the functions

to invoke. The flaw exists if there is no mechanism to enforce
who can invoke specific functions.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Sometimes web developers make use of fixed parameters to
provide access to protected pages. If no other control is
provided, an attacker could take advantage of this
vulnerability to access the protected contents.
Note that user-controllable input in PHP would be anything
coming from $_GET, $_POST, $_FILE, $REQUEST, $_COOKIE
and some sections of $_SERVER.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Suppose there is a web application requiring credentials at
the following link: http://www.elsfoo.com/login.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If the user provides correct credentials, they will be
redirected to the page (containing protected contents)
• http://www.elsfoo.com/index.php?auth=TRUE

If the user provides no, or incorrect credentials, they will be

redirected to the page (containing public contents)
• http://www.elsfoo.com/index.php?auth=FALSE

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The fixed parameter is auth and it is used by the web
application to distinguish between authenticated and non-
authenticated sessions.
An attacker can easily change the parameter auth to TRUE.
Since the web application considers only the auth parameter
to determine if a request is authenticated or not, the attacker
will be able to access protected contents.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This is the kind of logic flaw that you do not find documented,
but, it is actually found more often than you would imagine.
When a user attempts to access a resource meant to be
protected, it is common behavior to be redirected to a web
page prompting for valid credentials or simply showing an
error message.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Generally, this feature is implemented by using the Location
HTTP header; a web application that wants to redirect a
user to a new page inserts this header (with the new page
location) into the HTTP response.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

For the sake of clarity, let us use the following the scenario.
The user requests protected contents at the following page:
• http://www.elsfoo.com/getPersonalData.php?user=
bob

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Because the user is not authenticated, he or she will receive
an HTTP response including the following header:
Location: http://www.elsfoo.com/login

The user’s browser will analyze the header of the HTTP

response and will perform a new GET request to the new
page (login) without showing the content body of the first
request.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The web browser, after receiving the HTTP response with a
Location header, will not process the rest of the HTTP
response and will issue a new HTTP GET request to the new
page (/login).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The web browser will not show the body of the HTTP
response if it contains a Location header, but this does not
mean that the body is not there!
It could actually have been received by the client and it can
contain useful information for a malicious user or a
penetration tester. This happens because the developer has
forgotten to terminate the server script execution right after
the redirect.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The following snapshot shows a proxy intercepting an HTTP
response in a web application using redirects to protect
contents. The user is requesting the page
getPersonalData.php (the protected page) to retrieve the
personal data of the user Bob. In this case, the request was
performed by a non-authenticated user.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The web browser
automatically
redirects us to
login.php.
We will not see the
contents of the page.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Location header will be used by the browser to perform
a new HTTP request and ignore the body of the old one. The
web developer has not omitted the body of the HTTP
response in the case of non-authenticated requests. So, by
using a proxy, an attacker can easily see protected contents;
in this case, the personal data of the user Bob was obtained.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A web developer using a redirect to protect content must
remember to terminate the script execution after inserting
the redirect statement.
This can be implemented in many ways depending on the
scripting language (PHP, ASP.NET, Java, etc.).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

An example written in PHP. Note the die() function.

<?
session_start();
if (!isset($_SESSION['logged'])) {
header("Location: http://www.elsfoo.com/login");
die();
}
?>
…
// Protected Content
…

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The instruction header will send the Location header to the
HTTP response and the instruction die() will terminate the
script execution. The web server will send an HTTP response
with an empty body but with the Location header.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Generally, web applications manage authentication by
assigning an unique token to each authenticated session. This
session token, known as the session identifier will be sent by
the server to the user after a successful login; it will then be
re-sent by the user in subsequent HTTP requests (embedded
in the URL or in the cookie).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A session identifier can be easily guessed by an attacker if its
generation is predictable. A strong session identifier must
have the following features:
• purely random and unpredictable
• valid only for a single session
• time-limited
If an attacker finds a valid session identifier, he will be able to
impersonate the victim’s session without knowing the victim’s
credentials.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
SQL injection is a technique used to attack a database. If a
web application’s authentication relies on a database and if
user input is not properly sanitized, an attacker could take
advantage of that to gain unauthorized access to the system,
impersonating some other user.
Keep this in mind if you want to bypass authentication and
authorization mechanisms.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Local File Inclusion and Path Traversal are two other
vulnerabilities that can be used to bypass the security
authorization mechanisms implemented in a web application.
They typically happen when the web application that is trying
to retrieve a file from the file system, does not properly
sanitize the user input.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

We will analyze in detail these two vulnerabilities in the next
modules. For now let us say that:
• Path traversal: allows attackers to retrieve files from the
web server, that are not intended to be accessible
• Local File Inclusion: it is a type of path traversal that allows
attackers to access or execute the code of a local file (local
to the web server)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Path traversal

These two vulnerabilities usually happen when the user input

is used as part of a file path. Let us see a path traversal
example to better understand it. Consider the following PHP
code contained in the page faq.php:
<?php
$my_file = @$_GET['lang'] . '.html'; //Add extension to my file
if (file_exists($my_file )) { //Only if the file exists
readfile($my_file ); //Display the file
}

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

An attacker may be able to retrieve the content of any file on
the web application, by requesting the following page:
http://elswapt.site/faq.php?lang=[path_to_file]%00

Path to file such as

/etc/passwd The %00 is the URL encoded version of null
character. It marks the end of a string so that the
.html extension is not concatenated

The previous code will be interpreted as follow:

$my_file = @$_GET['lang'] . '.html'; //$my_file is /etc/passwd

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Local File Inclusion

The following is instead an example of the Local File Inclusion

vulnerability. Consider the following vulnerable code:

<?php
if (isset($_GET['lang'])) {
$my_file = $_GET['lang'] . '.html'; //Add extension to my_file
include('files/' . $ my_file ); //Display the file
}

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Once again let us assume the page is named faq.php. An
attacker may retrieve the file from the file system with:
http://elswapt.site/faq.php?lang=[path_to_file]%00

Path to file such as

../../../etc/passwd The %00 is the URL encoded version of null
character. It marks the end of a string so that the
.html extension is not concatenated

The "files/" folder is not taking into account since we are

able to go up of one folder by using the "../" sequence.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Google's 2-step
Openwall
verification

Seclist SkullSecurity

bAdmin Phenoelit

CIRT CAPTCHA

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

CAPTCHA - XSS CAPTCHA - SQLi

Bypass CAPTCHA with

Cintruder
OCR engine

OWASP: Testing for

Decoding CAPTCHA
CAPTCHA

Virtual sweatshops Spammers use the human

versus capt touch to avoid CAPTCHA

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Virtual sweatshops Insecure Direct Object
defeat Bot-or-Not Tests References – A8

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Username Enumeration Bypassing authorization

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Authentication and Authorization
In these labs, the student can practice techniques to bypass
authorization and authentication mechanisms by exploiting SQL
Injection, enumerating users and much more.

Powered by TCPDF (www.tcpdf.org)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015