This module contains the required background information

you will need before you begin your web application security
testing.

Note: covering how web applications work is beyond the

scope of this course.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

2.1 HTTP/S Protocol Basics

2.2 Encoding

2.3 Same Origin

2.4 Cookies

2.5 Session

2.6 Web Application Proxies

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Hypertext Transfer Protocol (HTTP) is the basic protocol used
for web browsing and, these days, for most other
communication on the web.
It is the client-server protocol used to transfer web pages and
web application data. The client is usually a web browser that
starts a connection to a server web such as MS IIS or Apache
HTTP Server.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

During an HTTP communication, the client and the server
exchange messages. The client sends a requests to the server
and gets back responses. The format of an HTTP message is:

HEADERS\r\n
\r\n \r (Carriage Return): moves the cursors to the
beginning of the line
\n (Line Feed): moves the cursor down to the next line
\r\n: is the same of hitting enter on your keyboard
MESSAGE BODY\r\n

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us examine an HTTP request in detail. The following is the
content of the request that we send when we open our web
browser and navigate to www.google.com.

google.com:80

GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive

An HTTP request to www.google.com is initiated. What you

see here are the headers (called HTTP Request Headers) for
this request. Note that a connection to www.google.com on
port 80 is initiated before sending HTTP commands to the
webserver.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 GET / HTTP/1.1 REQUEST METHOD
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive

This is your request type (also known as an HTTP Verb).

GET is the default request type when you type a URL into the
location bar of your web browser and hit Enter.
Other Verbs are POST, PUT, DELETE, OPTIONS, TRACE...

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 GET / HTTP/1.1 PATH
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive

This is the file you are requesting. The home page of a

website is always "/". Other pages can be requested, of
course, such as: /downloads/index.php. Your request
always refers to the root folder to specify the requested file
(hence the leading "/").
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 GET / HTTP/1.1 PROTOCOL
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive

This is the HTTP protocol version that your browser wants to

talk with. This basically informs the web server about which
version of HTTP you would like to use in any further
communication.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 GET / HTTP/1.1 HOST HEADER
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive

This is the beginning of HTTP Request Headers. HTTP Headers

have the following structure: Header-name:Header-Value.
The Host header allows a web server to host multiple
websites at a single IP address. Our browser is specifying in
the Host header which website you are interested in.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 GET / HTTP/1.1 HOST VALUE
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive

After each request header, you will find its corresponding

value. In this case you want to reach the Host
www.google.com.
Note: Host value + Path combine to create the full URL you are
requesting: the home page of www.google.com/
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 GET / HTTP/1.1 USER-AGENT
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive

The User-Agent reveals your browser version, operating

system and language to the remote web server.
All web browsers have their own user-agent identification
string. This is how most web sites recognize the type of
browser in use.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 GET / HTTP/1.1 ACCEPT
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive

The Accept header is used by your browser to specify which

document type is expected to be returned as a result of this
request.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 GET / HTTP/1.1 ACCEPT-ENCODING
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive

The Accept-Encoding is similar to Accept, but it restricts the

content codings that are acceptable in the response. Content
codings are primarily used to allow a document to be
compressed or transformed without losing the identity of its
media type and without loss of information.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 GET / HTTP/1.1 CONNECTION
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate
Connection: keep-alive

With HTTP 1.1 you can keep your connection to the remote web
server open for an unspecified amount of time using the value
"keep-alive". This indicates that all requests to the web server
will continue to be sent through this connection without
initiating a new connection every time (as in HTTP 1.0).
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Now that we know how the request is composed, let us inspect the
web server response.

In response to the HTTP Request, the web server will respond with
the requested resource, preceded by a bunch of new Headers.
These new headers from the server will be used by your web
browser to interpret the content contained in the Response
content.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

The above is an example of a web server response. Note that

we cut out the page content since it is not relevant for our
study at this time. Let us inspect some of these headers in
greater detail.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 STATUS-LINE
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

The first line of a Response message is the Status-Line, consisting

of the protocol version (HTTP 1.1) followed by a numeric status
code (200) and its relative textual meaning (OK).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 STATUS-LINE
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

The more common status codes are:

• 200 OK, the resource is found.
• 301 Moved Permanently, the requested resource has been assigned a new
permanent URI.
• 302 Found, the resource is temporarily under another URI.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 STATUS-LINE
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

• 403 Forbidden, the client does not have enough privileges and the server
refuses to fulfill the request.
• 404 Not Found, the server cannot find a resource matching the request.
• 500 Internal Server Error, the server does not support the functionality
required to fulfill the request.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 DATE
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

Date represents the date and time at which the message was
originated.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 CACHE HEADER
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

The Cache headers allow the Browser and the Server to agree
about caching rules. Cached contents save bandwidth because,
in short, they prevent your browser from re-requesting contents
that have not changed when the same resource is to be used.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 CONTENT TYPE
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

Content-Type lets the client know how to interpret the body of the
message.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 CONTENT-ENCODING
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

Content-Encoding extends Content-Type.

In this case the message body is compressed with gzip.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 SERVER HEADER
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

The Server header displays the Web Server banner. Apache and IIS
are common web servers. Google uses a custom webserver
banner: gws (that stands for Google Web Server).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 CONTENT LENGTH
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

Content-Length indicates the length, in bytes, of the message

body.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 CONTENT
HTTP/1.1 200 OK
Date: Fri, 13 Mar 2015 11:26:05 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Server: gws
Content-Length: 258

<PAGE CONTENT>

This is the actual content of the requested resource. The content

can be an HTML page, a document, or even a binary file. The type
of the content is, of course, contained in the Content-type header.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

For now this information about requests and responses are
enough. We will inspect them more in depth later on.
If you want to dig deeper in syntax and semantics of all
standard HTTP/1.1 header fields, please check the following
RFC 2616.
It lists and explains all the header fields in detail.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The best way to understand something is to play around with
it a bit.
Firefox (as well as other web browsers) already have some
features that allow us to inspect HTTP Headers on the fly.
Once Firefox starts, open the options menu and select
Developer -> Network.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You should see something like the below snapshot. Now we
just need to browse any web page we want and all the
requests and responses will be listed in this pane.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

By selecting any request or response from the list, a new
panel appears on the right and we will be able to inspect
information such as headers, cookies, parameters and so on.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Now that you know how HTTP works, let us see how to
protect it!
HTTP content, as in every clear-text protocol, can be easily
intercepted or mangled by an attacker on the way to its
destination. Moreover, HTTP does not provide strong
authentication between the two communicating parties.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the following slides you will see how to protect HTTP by
means of an encryption layer.

HTTP Secure (HTTPS) or HTTP over SSL/TLS is a method to run

HTTP, which is a clear-text protocol, over SSL/TLS, a
cryptographic protocol.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This layering technique provides confidentiality, integrity
protection and authentication to the HTTP protocol.

???

GET / SSL/TLS
HTTP/1.1 HTTP

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In other words, when using HTTPS:
• An attacker on the path cannot sniff the application layer
communication.
• An attacker on the path cannot alter the application layer
data.
• The client can tell the real identity of the server and,
sometimes, vice-versa.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

HTTPS does not protect against web application flaws! All
the attacks against an application happen regardless of
SSL/TLS.
The extra encryption layer just protects data exchanged
between the client and the server. It does not protect from an
attack against the application itself.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Attacks such as XSS and SQL injections will still work.
Understanding how HTTP and web applications work is
fundamental to mount both stealthy and effective attacks!

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Information encoding is a critical component of information
technology. Its main function is to represent the low-level
mapping of the information being handled.
The encoding process, often invisible to end users, occurs
each time an application needs to elaborate on any data.
Web applications are not excluded from this. Like many other
applications, they continuously process thousands of pieces
of information even for simple requests.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Understanding the encoding schemes used by a web
application can give you a big advantage during the detection
and exploitation of a vulnerability.
In this part of the course, we will introduce you to the
basics of web application encoding. You will find
that they are pretty much the same as any other application
encoding.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Internet users, via their web browsers, request billions of
pages every day. All of the content of these pages are
displayed according to a charset. But what is a character set?
As the word suggests, it contains a set of characters: they
represent the set of all symbols that the end user can display
in their browser window. In technical terminology, a charset
consists of pairs of symbols and code points.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The symbol is what the user reads, as he sees it on the
screen. The code point is a numeric index, used to
distinguish, unambiguously, the symbol within the charset. A
symbol can be shown only if it exists in the charset.
Examples of charsets are: ASCII, Unicode, Latin-1 and so on.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The ASCII (American Standard Code for Information
Interchange) charset contains a small set of symbols.
Originally it was 128 only, but now it is usually defined with
its extended version for a total of 255. It is old and it was
designed to support only US symbols.
For example, ASCII cannot be used to display Chinese
symbols, among many others. The ASCII charset doesn’t
contain symbols like © † ∑ α β «.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Here are some examples:
CODE HEX SYMBOL
65 41 A
66 42 B
67 43 C
68 44 D
… … …

You can find the complete list here.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Unicode (Universal Character Set) is the character encoding
standard created to enable people around the world to use
computers in any language. It supports all the world's writing
systems. Here you can find the whole Unicode charset.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Character encoding (or simply encoding) is the
representation, in bytes, of the symbols of a charset: a
mapping of the symbols to a series of ordered bytes so that
your data can get to you.
A symbol can be represented by using one or more bytes.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Unicode has three main types of implementation of character
encoding: UTF-8, UTF-16 and UTF-32, where UTF stands for
Unicode Transformation Format.
The numbers 8,16 and 32 are the amount of bits used to
represent code points.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

For example, the same symbol will be represented as follow:

SYMBOL UNICODE UTF-8 UTF-16 UTF-32

! U+0021 21 00 21 00 00 00 21
W U+0057 57 00 57 00 00 00 57
⦾ U+2B80 E2 AE 80 2B 80 00 00 2B 80
⌗ U+2317 E2 8C 97 23 17 00 00 23 17

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Even in HTML, it is important to consider the information
integrity of the URL’s, and ensure that user agents (browsers
& co.) display data correctly.
There are two main issues to address: inform the user agent
on which character encoding is going to be used in the
document, and preserve the real meaning of some characters
that have special significance

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

According to the HTTP 1.1 RFC, documents transmitted via
HTTP can send a charset parameter in the header to specify
the character encoding of the document sent: this is the
HTTP header Content-Type.
HTML4
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">

HTML5
<meta charset="UTF-8">

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If not defined, the RFC defines as default charset the ISO-
8859-1: "8-bit single-byte coded graphic character sets" aka
Latin 1. Setting an incorrect charset or simply omitting it can
bring on some really unexpected behavior. If you intentionally
set an incorrect charset, your browser may not display some
symbols correctly.
These encoding schemas that we have talked about so far can
be applied to all applications.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the HTML language, there are many characters (symbols)
with special meanings.
For example, the symbol < describes the start of an HTML tag,
and obviously that tag will not be shown to the end user; the
symbol > indicates the end, and so on.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If you want to show these symbols in your web document and
you want to avoid the symbols being interpreted by your
browser as HTML language elements, then you need to use
the related entities.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

An HTML entity is simply a string (starting with & or &# and
ending with ; ) that corresponds with a symbol.
When the browser encounters an entity in an HTML page it
will show the symbol to the user and will not ever interpret
the symbol as an HTML language element.
Let us see some examples.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

As the standard states, character references must start with a
U+0026 AMPERSAND character (&) and following this there
are multiple ways to represent character references.
Character Reference Rule Encoded Character
Named entity & + named character references + ; &lt;
Numeric Decimal &+#+D+; &#60;
D = a decimal number
Numeric Hexadecimal & + #x + H + ; &#x3c;
H = an hexadecimal number (case- &#X3C;
insensitive)
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Although the primary purpose of HTML entities is not really
to be a security feature however, its use can limit most client
side attacks (IE: XSS).
We will discuss this more in the following chapters.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

As stated in the RFC 3986, URLs sent over the Internet must
contain characters in the range of the US-ASCII code
character set. If unsafe characters are present in a URL,
encoding them is required.
This encoding is important because it limits the characters to
be used in a URL to a subset of specific characters:
1• Unreserved Chars: [a-zA-z] [0-9] [- . _ ~]
2• Reserved Chars (they have a specific purpose)
• :/?#[]@!$&"() *+,; = %

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Other characters are encoded by the use of a percent char (%)
plus two hexadecimal digits. Reserved chars must be encoded
when they have no special role inside the URL. What follows
is a list of common encoded characters:
Character Purpose in URI Encoding
# Separate anchors %23
? Separate query string %3F
& Separate query elements %24
+ Indicates a space %2B

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

When you visit a site, URL-encoding is performed
automatically by your browser. This happens automatically
behind the scenes in your browser while you surf.
Here is a complete URL-encoding reference.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Although it appears to be a security feature, URL-encoding is
not. It is only a method used to send data across the Internet
but, it can lower (or enlarge) the attack surface (in some
cases).
Generally, web browsers (and other client-side components)
automatically perform URL-encoding and, if a server-side
script engine is present, it will automatically perform URL-
decoding.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us show you some important examples about how web
browsers URL-encode simple user requests.
Browser index.html?arg=test index.html?arg= test with spaces index.html?arg=<h1>hello world</h1>

arg=test arg=%20test%20with%20spaces arg=%3Ch1%3Ehello%20world%3C/h1%3E

arg=test arg= test with spaces arg=<h1>hello world</h1>

arg=test arg=%20test%20with%20spaces arg=%3Ch1%3Ehello%20world%3C/h1%3E

arg=test arg=%20test%20with%20spaces arg=%3Ch1%3Ehello%20world%3C/h1%3E

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Base64 is a binary-to-text encoding schema used to convert
binary files and send them over Internet. For example, the e-
mail protocol makes massive use of this encoding to attach
files to messages.
The HTML language permits the inclusion of some resources
by using this encoding. For example, an image can be
included in a page by inserting its binary content that has
been converted to base64.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The alphabet of the Base64 encoding scheme is composed of
digits [0-9] and Latin letters, both upper and lower case [a-
zA-Z], for a total of 62 values. To complete the character set
to 64 there are the plus (+) and slash (/) characters.
Different implementations however, may use other values for
the latest two characters and the one used for padding (=).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The following code will show an image in a web document.
The server will send this image without the need to read it
from another source like the file system.
<img_src="data:image/gif;base64,R0lGODlhDwAPAKECAAAAzMzM/////wAAACwAAAAA
DwAPAAACIISPeQHsrZ5ModrLlN48CXF8m2iQ3YmmKqVlRtW4MLwWACH+H09wdGltaXplZCBi
eSBVbGVhZCBTbWFydFNhdmVyIQAAOw=="alt="Base64 encoded image"
width="150"height="150"/>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In this chapter, we have discussed the major encoding
schemas, but that is not all of them.
In fact, remember that any web designer or developer could
easily create their own encoding schema.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
One of the most important and critical points of web
application security is same origin policy.
This policy prevents a script or a document from getting or
setting properties of another document that comes from a
different origin.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

CSS stylesheets, images and scripts are loaded by the browser
without consulting the policy.
Same Origin Policy (SOP) is consulted when cross-site HTTP
requests are initiated from within client side scripts (IE:
JavaScript), or when an Ajax request is run.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The origin is defined by the following triplet:
Protocol Host Port

Take a look at this example:

http://www.elswapt.site

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Protocol Host Port

http://www.elswapt.site

The origin of http://www.elswapt.site is different from

https://www.elswapt.site origin because the protocol is
different.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 Protocol Host Port

http://www.elswapt.site

The origin of http://www.elswapt.site is different from

http://admin.elswapt.site origin because the host is
different.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 http://www.elswapt.site

The hierarchy of domains descends from the right to the left.

In the above example:
• site is the top-level domain (TLD)
• elswapt is the second-level domain (SLD)
– subdomain of site
• www is the third level domain
– subdomain of elswapt
• and so on
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 Protocol Host Port

http://www.elswapt.site:80

When not specified, the default port is always 80.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us see some SOP examples applied to the following
address: http://els.wapt.site/index.php:
URL SOP Reason
http://els.wapt.site/admin/index.php Same protocol, host and port
https://els.wapt.site/index.php Different protocol
http://els.wapt.site/index.php:8080 Different port
http://www.els.wapt.site/index.php Different host

Content from about:blank, javascript: and data:

inherits the origin.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 IMPORTANT

It is important to know that Internet Explorer works a bit

differently from other browsers. It has two exceptions:
• Port: it does not consider the port as a Same Origin
component.
• Trust Zone: the Same Origin is not applied to domains that
are in highly trusted zone (i.e. corporate domains)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Why should the browser control where a script
can or cannot have access ?

Let us explain it using a simple example.

Suppose you are logged in to your bank site and suppose your
friend invites you to visit his new website. Also, suppose your
friend is a malicious friend.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

As a general rule, the Same Origin Policy (referred to as SOP)
prevents JavaScript, running on a given origin, from
interacting with a document from a different origin. The
primary purpose of SOP is to isolate requests coming from
different origins.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 What would it happen if SOP did not exist?

Your evil friend could build a crafted page, instigate you to

visit it, and once visited by you, access (some) personal
information from your bank account.
As you can see without SOP you could not surf the Internet.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The main rule of SOP is:
“A document can access (through JavaScript) the properties
of another document only if they have the same origin”
More precisely, the browser always performs the request
successfully but it returns the response to the user only if the
SOP is respected.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

With the term document, we are referring to an HTML page,
an iframe included in the main page, or a response to an Ajax
request. As stated above: images, style information (*.css)
and JavaScript files (*.js) are excluded from the previous
statement; they are always accessible regardless their origin,
and the browser loads them without consulting SOP.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Now, let us look at two examples:

Example 1 Example 2

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Example 1

Let us suppose that index.html on domain a.elswapt.site

(referred to as origin1: http://a.elswapt.site) wants to
access, via an Ajax request (xhr), the home.html page on
domain b.elswapt.site (referred to as origin2:
http://b.elswapt.site).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The document index.html on domain a.elswapt.site
cannot access, via an Ajax request (xhr) the home.html page
on domain b.elswpat.site
XHR GET (http://b.elswapt.site/home.html)

a.elswapt.site b.elswapt.site

index.html home.html

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Example 2

Let us see another example. We have two documents: the

main document http//www.elswapt.site/index.html and
the iframe document http//www.elswapt.site/iframe.html.
index.html
<html>
…
<body>
<iframe src="http//www.elswapt.site/iframe.html">
</iframe>
</body>
</html>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The two document objects have the same origin, each
document can access the other via JavaScript. So, within the
main document the following JavaScript instruction would be
successful:
window.frames[0].body= "Hello world";

Similarly, within the iframe document, the following

JavaScript instruction would be successful:
window.parent.body= "Hello world";

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If we point the iframe to http://www.mybank.bank the
previous JavaScript code would fail because the two windows
do not have the same origin.
Keep the previous example in mind. SOP often defines the
boundaries of many client-side attacks.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

There are several exceptions to SOP restrictions:

window.location document.domain

Cross origin resource

Cross window messaging
sharing (CORS)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A document can always write the location property of
another document.

"The window.location object can be used to

get the current page address (URL) and to
redirect the browser to a new page."

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Consider two documents on your browser with some existing
relationship (i.e.: the first document includes the second via
an iframe, or the second document has been opened by the
first one with a window.open call).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Each document can write the location property of the other,
but cannot read it, except the case where the two documents
have the same origin.

Read

Write

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This means that the location property can be always changed,
notwithstanding the same origin policy that determines
whether a new document can be loaded.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Suppose you have the following document
http://www.elswapt.site/index.html:

<html>
…
<body>
<iframe src="http//www.elearnsecurity.com/index.html">
</iframe>
</body>
</html>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Within the index.html document, the following JavaScript
instruction is run successfully:

window.frames[0].location=http://www.google.com;

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A document can always update the location property of
another document, if they have some relationship.
Typical relationships are: a document is embedded within
another via an iframe element, one document is opened by
the other via the window.open DOM API.
Let us look at some typical examples.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A document X included by another document Y via an iframe,
can always change the location of Y.
Code on Y
<html>
<body>
<iframe src='X'></iframe>
</body>
</html>
Code on X
<html>
<head>
<script type="text/javascript">
window.parent.location="http://www.google.com";
</script>
</head>
</html>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A document X opened by document Y through the
window.open DOM API can always change the location of Y.
Code on Y
<html>
<body>
<button name='Click' onclick="window.open(X);">
Click
</button>
</body>
</html> Code on X
<html>
<head>
<script type="text/javascript">
window.opener.location="http://www.google.com";
</script>
</head>
</html>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Another important exception is related to the DOM property
called document.domain.
This property describes the domain
portion of the origin of the current
document.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A document with the URL
• http://subdomain.domain.com/index.html
has the document.domain property set to
• subdomain.domain.com

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This property can be changed. A document can update its
own document.domain to a higher level in the domain
hierarchy, except for the top level (e.g. .com).
The second-level domain (e.g. domain.com) can be specified
but it cannot be changed (e.g. from domain.com to
whitehouse.gov).
By changing the document.domain property, a document
partially changes its own origin.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us say that a document with the URL
• http://a.elswapt.site/index.html
includes, via an iframe, another document belonging to a
different origin
• http://b.elswapt.site/home.html

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Due to the SOP, the JavaScript code running from the context
of the main document cannot access, via JavaScript, the
iframe content because the two documents come from
different origins.

Origin A Origin B

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The SOP is circumvented, though, if the following JavaScript
code (document.domain="elswapt.site") is run by each of
the two documents. In this manner, the two documents can
be considered to have the same origin.
<iframe scr="http://b.elswapt.site/home.html" />

a.elswapt.site b.elswapt.site
<script> <script>
document.domanin="elswapt.site" document.domanin="elswapt.site"
</script> </script>

index.html home.html
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
The new HTML5 feature known as Cross Window Messaging
permits different documents (iframes, popups, current
window) to communicate with each other regardless of the
same origin policy by using a simple synchronous mechanism.
Do not worry; this mechanism will be dealt with in-depth in
the HTML5 module.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Cross origin resource sharing is a set of specs built to allow a
browser to access a few resources by bypassing the same
origin policy. The CORS architecture uses custom HTTP
response headers and relies upon server-side components or
server-side scripting languages.
This also will be dealt with in-depth in the HTML5 module

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
HTTP is a stateless protocol. This means that a website
cannot retain the state of your visit between different HTTP
requests without mechanisms such as sessions or cookies.
Each visit without a session or a cookie looks like a new user
to a server and a browser.
To overcome this limitation, in 1994 sessions and cookies
were invented. Netscape, a leading company at that time,
invented cookies to make HTTP stateful.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Cookies are just textual information installed by a website
into the "cookie jar" of the web browser. The cookie jar is the
storage space where a web browser stores the cookies.
They are fragments of text containing variables in the form of
name=value.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A server can set a cookie via the
Set-Cookie HTTP header field in a
response message. A cookie has a
predefined format. It contains the
following fields.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A website only sets a cookie for its domain.
• e.g. google.com sets a cookie for the domain:
google.com or .google.com
This means that the browser will install the cookie in
the cookie jar and will send this cookie for any
subsequent request to:
• google.com
• www.google.com
• maps.google.com

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The scope of this cookie will be *.google.com
Domain A cannot set a cookie for domain B.
The browser will sends A's cookie in accordance with
the above domain scope (to A and all of its
subdomains), including the path and the expiration
date.
There are two important considerations about the
domain field:
• a leading ".", if present, is ignored
• If the server does not specify the domain attribute, the
browser will automatically set the domain as the server
domain and set the cookie host-only flag. This means that
the cookie will be sent only to that precise hostname

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Expires gives the cookie a time constraint.
The cookie will only be sent to the server if it is
not expired.
Session cookies expire when the session exits.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The cookie Path field specifies for which requests, within
that domain, the browser needs to send the cookie.
For cookies with path =/downloads, all subsequent
requests to:
• /downloads
• /downloads/foo
• /downloads/foo/bar
will include this cookie.
The browser will not send this cookie for requests to
/blog or /members

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A cookie can carry a number of values at once. A server can set
multiple values with a single Set-Cookie header by
specifying multiple KEY=Value pairs.
For example:
Set-Cookie: Username="john"; Authenticated="1"

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The HttpOnly flag is used to force the browser to send the cookie only through
HTTP.
This flag prevents the cookie from being read via JavaScript, Flash, Java and any
other non-HTML technology. This is a protection mechanism against cookie
stealing via XSS.
You will see how to exploit XSS vulnerabilities later on.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Secure flag forces the browser to send the cookie only through HTTPS (SSL).
This prevents the cookie from being sent in the clear.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The domain attribute represents the domain value for which
the cookie is valid. Together with the path, secure and expires
attributes, it is useful during the process in determining if a
cookie must be submitted along with a new HTTP request.
RFC6265 distinguishes cookies set with a specified domain
value from cookies without.
RFC
6265
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
An important difference in the previous RFC is the leading dot
at the start of the domain value string. As opposed to the
previous RFC, the leading dot (.) has no particular
significance; the browser does not care about it.
For example, this means that a browser will handle cookies
with these domain values the:
• .elswapt.site
• elswapt.site

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us have a look at the following different cookie domain
settings. We will see when and how the cookie will be sent.

Unspecified cookie
Specified cookie domain
domain

Internet Explorer
exception

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 A cookie with a domain value specified will be sent by the browser
when one of the following conditions occurs:

1 2 Cookie domain value is

Cookie domain value different from the target domain
= AND
target domain Cookie domain value is a suffix of the
target domain.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Cookie domain value 1
=
target domain

Suppose that the cookie domain value is els.wapt.site and

that the target domain requested by the browser is
els.wapt.site (it is the same).
If we request the following page:
• http://els.wapt.site/index.php
the cookie will be sent.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Cookie domain value is different from the target domain 2
AND
Cookie domain value is a suffix of the target domain.

Suppose that the cookie domain value is wapt.site and that

the target domain requested by the browser is
els.wapt.site. For example we are requesting the page
• http://els.wapt.site/index.php
The cookie will be sent because the string wapt.site
represents a suffix of the string els.wapt.site.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us see some examples. A page on the target domain
elswapt.site sets a cookie with domain value
elswapt.site.
The browser will send this cookie in HTTP requests matching
the following URLs:
• http[s]://elswapt.site/*
• http[s]://www.elswapt.site/*
• http[s]://www.lab.elswapt.site/*
• http[s]://*.elswapt.site/*
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
A page on the target domain *.elswapt.site can set a
cookie with domain value elswapt.site.

Example: A page on the target domain a.b.elswapt.site

sets a cookie with domain value elswapt.site.
The browser will send this cookie in requests matching the
following URLs: http[s]://*.elswapt.site/*

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A page on the target domain elswapt.site cannot set a
cookie with domain value *.elswapt.site.

Example: A page on the target domain elswapt.site cannot

set a cookie with domain value a.elswapt.site.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This means that lower-level subdomains can set cookies for
higher domains. Indeed b.a.elswapt.site can set a cookie
for a.elswapt.site or elswapt.site.

On the reverse side, higher domains cannot set cookies for

lower-level subdomains. Indeed elswapt.site cannot set
cookies for anysubdomain.elswapt.site.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

When a cookie does not contain a domain value, it is
assumed that the host-only-flag is set to true. A cookie with
the host-only-flag value will be sent only to the target domain
that set it.
Note that the RFC uses the term host instead of domain.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If a page on the target domain elswapt.site sets a cookie
without the domain value, the browser will send this cookie
only in HTTP requests that exactly match the following URLs:
http[s]://elswapt.site/*.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Internet Explorer does not distinguish between cookies with a
specified domain value from ones with unspecified values.
Cookies with unspecified domain values will be interpreted by
the browser as if they had a domain value corresponding to
the target domain set in it.
Let us look at an example of this.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A page on the target domain elswapt.site sets a cookie
without a domain value. IE differs from other browsers, and
will consider sending this cookie as if its domain value was set
to elswatp.site therefore, it will send this cookie in HTTP
requests that match the following URLs:
• http[s]://elswapt.site/*
• http[s]://www. elswapt.site/*
• http[s]://www.lab. elswapt.site/*
• http[s]://*. elswapt.site/*
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
This following slides will depict the process of cookie
installation within a web browser.
This example, although pretty simplistic, should finally shed
some light on how cookies are handled.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A login page is a great place for a session to begin and also a good
point at which a cookie is installed in your browser.

Web Browser www.google.com

POST /login.php
Host: www.google.com

usr=John&Pass=mypass

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The web site will respond with a Set-Cookie response header. This
header contains the cookie to be installed in the browser and to be
included in all subsequent requests to www.google.com
Web Browser www.google.com

HTPP /1.1 200OK

...
Set-Cookie: domain=google.com; path=/; expires=espires=Mon;
16-Apr-2013 19:03:22 GMT; authenticated='1'; httpOnly;
secure;
<PAGE CONTENT>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

For every subsequent request, the browser will consider:
Domain scope, Path, Expiration, Flags. If all the above checks
pass, a cookie header that contains the cookie will be
inserted into the Request header.
Web Browser www.google.com

GET /mail.php
Host: www.google.com
Cookie=authenticated="1";

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us see some examples wherein the browser accepts
cookies sent by the web server and some others where the
cookies are rejected.

Examples of Correct Cookie Examples of Incorrect Cookie

Installation Installation

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The browser requests a page from the target domain
a.elswapt.site and the web server sends a response,
including a cookie without a domain value.
Let us see how this works in the next slide.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target
domain

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target HTTP RESPONSE HEADER: The web server
domain … sends a response
Set-Cookie: SESSID=d8a4z21 including a
Path =/
cookie without a
domain value

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

POST (http://a.elswapt.site/login.php)
The cookie is
accepted and will HTTP RESPONSE HEADER:
be available only …
Set-Cookie: SESSID=d8a4z21
to the target Path =/
domain
a.elswapt.site,
since the domain GET (http://a.elswapt.site/logout.php)
value was not HTTP Request Header:
specified. …
Cookie SESSID:=d8a4z21

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This cookie will be sent in each HTTP request matching the
following URLs:
• http://a.elswapt.site/*
• https://a.elswapt.site/*

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The browser requests a page on the target domain
a.elswapt.site and the web server sends a response
including both a cookie with the domain value
.elswapt.site and the path value /.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target
domain

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target The web server
HTTP RESPONSE HEADER:
domain …
sends a response
Set-Cookie: SESSID=d8a4z21; with the domain
domain:= .elswapt.site; value
Path =/ .elswapt.site
and the path value
/

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The cookie is accepted because the domain value
.elswapt.site is a suffix of the domain emitting the cookie,
a.elswapt.site, therefore it will be accepted and sent in
each request matching the following URLs:

• http://elswapt.site/* • http://*.elswapt.site/*
• https://elswapt.site/* • https://*.elswapt.site/*
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 This is what will happen. The cookie previously set is sent to
both a and b subdomains. a.elswapt.site

GET (http://a.elswapt.site/page1.php)
Web Browser HTTP Request Header:
…
Cookie SESSID:=d8a4z21

b.elswapt.site

GET (http://b.elswapt.site/index.php)
HTTP Request Header:
…
Cookie SESSID:=d8a4z21

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The browser requests a page from the target domain
a.elswapt.site and the web server sends a response
including both a cookie without a domain value and the path
value of /learning.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target
domain

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target
domain HTTP RESPONSE HEADER: The web server
… sends a response
Set-Cookie: SESSID=d8a4z21; without a domain
Path =/learning; value and the path
value /learning

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The cookie is accepted and will be available only to the target
domain a.elswapt.site and path /learning/*.
So, this cookie will be sent in each request matching the
following URLs:
• http://a.elswapt.site/learning/*
• https://a.elswapt.site/learning/*

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 This is what will happen. The cookie will be sent for resources
in the /learning/ path.
GET (http://a.elswapt.site/page1.php) page1.php
Web Browser HTTP Request Header:
…
<NO COOKIE> a.elswapt.site

learning/lab.php
GET (http://a.elswapt.site/learning/lab.php)
HTTP Request Header:
…
Cookie SESSID:=d8a4z21

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The browser requests a page from the target domain
a.elswapt.site and the web server sends a response,
including a cookie named SESSID, value A, and a domain
value .elswapt.site.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target
domain

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target The web server
domain HTTP RESPONSE HEADER: sends a response
… with a cookie
Set-Cookie: SESSID=A; named SESSID,
Domain:= .elswapt.site ; value A, and a
Path =/ domain value
.elswapt.site

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

After that, the browser requests a second page from the
target domain elswapt.site and the web server sends a
response including a cookie with the name SESSID, value B,
and without domain value.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser elswapt.site

The browser POST (http://elswapt.site/page2.php)

requests a page
from the target
domain

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser elswapt.site

The browser POST (http://elswapt.site/page2.php)

requests a page
from the target
HTTP RESPONSE HEADER: The web server
domain
… sends a response
Set-Cookie: SESSID=B; with the name
Path =/ SESSID, value B, and
without domain
value

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Both cookies will be accepted and stored by the browser.
They will not interfere with one another as they are two
different cookies.
GET (http://a.elswapt.site/page1.php) a.elswapt.site
Web Browser HTTP Request Header:
… page1.php
Cookie SESSID:=A

elswapt.site
GET (http://elswapt.site/lab.php)
HTTP Request Header: lab.php
…
Cookie SESSID:=B

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us see some examples where the cookie sent by the web
server is not accepted by the browser.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The browser requests a page from the target domain
a.elswapt.site and the web server sends a response
including a cookie with domain value b.elswapt.test.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target
domain

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target HTTP RESPONSE HEADER: The web server
domain … sends a response
Set-Cookie: SESSID=d8a4z21; including a
domain:= b.elswapt.test ; cookie with the
Path =/
domain
b.elswapt.test

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

POST (http://a.elswapt.site/login.php)
The cookie is not
HTTP RESPONSE HEADER:
accepted
…
because the Set-Cookie: SESSID=d8a4z21;
domain domain:= b.elswapt.test ;
b.elswapt.test is Path =/
not a suffix of
the domain GET (http://a.elswapt.site/logout.php)
a.elswapt.site HTTP Request Header:
that sent the …
cookie. < No Cookie >

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The browser requests a page from the target domain
a.elswapt.site and the web server sends a response
including a cookie with domain value b.elswapt.site .

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target
domain

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

The browser POST (http://a.elswapt.site/login.php)

requests a page
from the target HTTP RESPONSE HEADER: The web server
domain … sends a response
Set-Cookie: SESSID=d8a4z21; including a
domain:= b.elswapt.site ; cookie with the
Path =/
domain
b.elswapt.site

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Browser a.elswapt.site

POST (http://a.elswapt.site/login.php)
The cookie is not
HTTP RESPONSE HEADER:
accepted because
…
the cookie Set-Cookie: SESSID=d8a4z21;
domain value domain:= a.elswapt.test ;
b.elswapt.site is Path =/
not a suffix of the
domain GET (http://a.elswapt.site/page1.php)
a.elswapt.site HTTP Request Header:
emitting it. …
< No Cookies>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Sometimes the web developer prefers to store information on
the server side instead of the client side.
This happens in order to hide the application logic or just to
avoid the back and forth data transmission, which is typical
behavior of cookies.
HTTP sessions are a simple mechanism that allows websites
to store variables specific for a given visit on the server side.
Each user session is identified by a either a session id or
token, which the server assigns to the client.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
The main difference between cookies and session variables is
that cookies are stored on the client whereas session
variables are on the server.
Also, session variables expire with the session and sessions
usually expire sooner than cookies do.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The session mechanism works through the use of a session
token (or session ID).
The session ID is assigned to the client by the webserver and
the client will present this ID for each subsequent request in
order to be recognized.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The session ID provided by the client will let the server
retrieve both the state of the client and all of its associated
variables.
You can picture the session ID like primary key in a relational
database where clients’ variables are stored.
Session IDs can be stored within text files, databases or
memory on the server.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 02ab12.txt

Var1=abc
Var2=123
SessionID=02ab12

Web server Session ae01de.txt

Database
SessionID=ae01de
Var1=xyz
Var2=987

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Session cookies just contain a single parameter formatted in a
key value pair. See the example below:

• SESSION=0wvCtOBWDH8w
• PHPSESSID=l3Kn5Z6Uo4pH
• JSESSIONID=W7DPUBgh7kTM

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Websites running PHP, typically install session cookies by
using the "PHPSESSID" parameter name, while JSP websites
typically use "JSESSIONID". Each development language has
its own default session parameter name and typically allow
for developers to customize its functionality (IE: Changing
PHPSESSID to PSESSID).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If needed, servers install session cookies after a browser
performs some type of activity, such as:
• Opening a specific page.
• Changing settings in the web application.
• Logging in.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Then the browser uses the cookie in subsequent requests.
A session could contain many variables, so sending a small
cookie keeps the bandwidth usage low.
In the following example you can see a session cookie in
action.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 POST /login.php HTTP/1.1
The client uses a login Host: my.website.com

form to POST the user's

usr=John,passwd=p4ss
credentials.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The server sends back a
POST ...
response with a Set-cookie
header field. HTTP/1.1 200 OK
...
The cookie contains the Set-Cookie: SESS=MySess1234;
expires=Thu, 21-May-2015
session ID. 15:25:20 GMT; path=/;
domain=my.website.com
...

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The browser will send back POST ...

the cookie according to the HTTP/1.1 200 OK

cookie protocol, thus ...

sending the session ID.

GET /resource HTTP/1.1
...
Cookie: SESS=MySess1234
...

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Since the web browser has a cookie in its jar, any subsequent
request will carry the (session) cookie with it.
As an alternative to session cookies, session ID’s can also be
sent via the GET method appended to the requesting URL.

http://example.site/resource.php?sessid=k27rds7h8w

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the following video you will see how the cookie protocol
works:
• Installation of cookies
• Manipulation of cookies
• Dissecting a cookie
Moreover you will see how HTTP sessions work and how they
use cookies.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Most web applications contains a great deal of objects like
scripts, images, style sheets, client and server side
intelligence.
Having tools that help in the study and analysis of web
application behavior is critical.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

An intercepting proxy is a tool that lets you analyze and
modify any request and any response exchanged between an
HTTP client and a server.
By intercepting HTTP messages a pentester can study a web
application behavior and manually test for vulnerabilities.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The most used web application proxies are:
• Burp Suite (the intercepting proxy feature).
• ZAP.
Proxies are fundamental while analyzing web applications and
will become your best friends for web-app testing.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Do not confuse intercepting proxies with common web proxy
servers like Squid.
Proxy servers have different purposes: bandwidth
optimization, content filtering and more.
The next two images will help make that clearer.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Intercepting Proxy Example

Here the proxy is an application

which intercepts the penetration
tester's browser traffic.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 Proxy Server Example

Here the proxy server filters all

the traffic coming from the
internal network.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Burp suite offers one of the best proxies available. You can
download the Free Edition here.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Burp suite will let you:
• Intercept requests and responses between your browser
and the web server.
• Build requests manually.
• Crawl a website, by automatically visiting every page in a
website.
• Fuzz web applications, by sending patterns of valid and
invalid inputs to test their behavior.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

By using Burp, you can intercept and modify requests coming
from your browsers before they are sent to the remote
server.
You can modify the header and the body of a message either
by hand or, automatically.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the following slides you will see how to launch, configure
and use Burp Suite with your browser.
Attempt to understand all the settings by trying them on your
computer!

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Launch Burp Suite: in Kali you will find it under Kali Linux >
Web Applications > Web Application Proxies > burpsuite.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If you want to run it on another operating system, you can
download it from the Portswigger website.
To run Burp you can double click on the jar file you
downloaded or run

java -jar burpsuite_free_v1.6.jar

from the console.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Now go to the Proxy tab and then to the Options sub-tab.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Here you can start and stop the proxy and configure the
host:port pair on which burp will listen.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Scrolling down you can find other configuration items to fine
tune which messages to intercept, how to automatically
change message content and more.
For now, just leave the default options as they are, you will
see how to use those features later on.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Once Burp Proxy is configured, you have to configure your
browser to use it as the proxy for every protocol.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In Firefox you have to open the
Preferences window, go to the
advanced tab, click on the
Network sub-tab and finally open
the Connection settings window.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To intercept traffic switch to Burp and go to Proxy > Intercept
and click on the Intercept is off button to enable interception.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Now open a website with your browser, Burp will pop up
intercepting the request. You can, optionally, modify and then
forward it by clicking on Forward.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

When Intercept is on, every browser request stops at Burp
Proxy. You can modify the entire request or just its headers.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You can modify the headers both in the Raw tab or in the
Headers tab. Remember to forward the request after editing
it!

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Raw and Headers tab present the very same information with
a different format. The Headers tab simply presents the
headers in a tabular manner.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You do not need to manually intercept and forward every
request though.
Even if you leave the master interception off, Burp will still
collect information on the HTTP traffic coming to and from
your browser.
You can check what Burp is collecting in two ways:
• on the Proxy > History tab
• in the Target > Site Map tab.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Burp Suite Proxy tab contains an
HTTP history sub tab.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 You can also check what Burp is
collecting on Target > Site Map

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Another feature is Burp Repeater which lets you manually
build raw HTTP requests.
You can do the same thing by using other tools such as netcat
or telnet, but Burp provides you:
• Syntax highlighting
• Raw and rendered responses
• Integration with other Burp tools

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To create a request, first you have to set your target by
clicking on the pencil icon in the upper right corner of the tab.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Then you can set your target host and port.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You can define your request by using this text area. Every
request must have at least an HTTP VERB (GET, POST, ...)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A Host header.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

And two empty lines after the headers.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

When your request is complete, you can click the Go button
to send it to the server.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Burp displays the response in the Response panel.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

An easier method to build requests is to intercept a browser
request with the proxy and send it to the Repeater function.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You can do that with the Ctrl+R shortcut or by right clicking in
the request body and selecting Send to Repeater.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the following two videos you will learn how to define the
target scope in Burp and OWASP ZAP, how to configure the
Proxy to intercept only the traffic in scope.
Moreover you will see how to configure and use other
features of both Burp and ZAP, according to the penetration
test engagement goals.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
URIs, URLs, and URNs: HTTP Status Code
Clarifications and
Recommendations 1.0 Reference

SSL/TLS Strong Encryption: HTTP Overview, History,

An Introduction Versions and Standards

HTTP State Management

Burp Suite
Mechanism (cookies)

ZAP

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Burp Suite Same Origin

HTTP Cookies and

OWASP ZAP
Sessions

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Same Origin Policy Cookies
Test different Same Origin Test different cookies
Policy configurations configuration on different
domains

Powered by TCPDF (www.tcpdf.org)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015