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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

During an HTTP communication, the client and the server
exchange messages. The client sends 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 3.0 – Caendra Inc. © 2018

Let’s 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

Web Browser Web Server

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018
 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 3.0 – Caendra Inc. © 2018

Now that we know how the request is composed, let us inspect the
web server response.

Web Browser Web Server

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

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.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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

GET / SSL/TLS
HTTP/1.1 HTTP

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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.
http://www.iana.org/go/rfc2978

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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.

http://www.ascii-code.com/

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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.

http://unicode-table.com/en/#0032

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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.

http://www.w3.org/International/articles/definitions-characters/

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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">

https://tools.ietf.org/html/rfc2616

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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)
http://www.w3.org/html/wg/drafts/html/master/syntax.html#named-character-
references
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

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)
• :/?#[]@!$&"() *+,; = %
http://tools.ietf.org/html/rfc3986#section-2.1

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 %26
+ Indicates a space %2B

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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.

http://www.w3schools.com/tags/ref_urlencode.asp

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 Protocol Host Port

http://www.elswapt.site:80

When not specified, the default port is always 80.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Now, let us look at two examples:

Example 1 Example 2

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

There are several exceptions to SOP restrictions:

window.location document.domain

Cross origin resource

Cross window messaging
sharing (CORS)

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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
http://tools.ietf.org/html/rfc6265

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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

GET (http://a.elswapt.site/learning/lab.php) learning/lab.php

HTTP Request Header:
…
Cookie SESSID:=d8a4z21

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 Web Browser elswapt.site

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

requests a page
from the target
domain

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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

GET (http://elswapt.site/lab.php) elswapt.site

HTTP Request Header:
… lab.php
Cookie SESSID:=B

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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 3.0 – Caendra Inc. © 2018

 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:= b.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 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 02ab12.txt

Var1=abc
Var2=123
SessionID=02ab12

Web server Session ae01de.txt

Database
SessionID=ae01de
Var1=xyz
Var2=987

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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

form to POST the

usr=John,passwd=p4ss
user's credentials.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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.

http://portswigger.net/burp/ https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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.

http://www.squid-cache.org/

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

 Intercepting Proxy Example

Here the proxy is an application

which intercepts the penetration
tester's browser traffic.
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
 Proxy Server Example

Here the proxy server filters all

the traffic coming from the
internal network.
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
Burp suite
offers one of
the best
proxies
available.

You can
download the
Free Edition
here. http://portswigger.net/burp/download.html

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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.

http://portswigger.net/Burp/downloadfree.html

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 Burp Suite Proxy tab contains an
HTTP history sub tab.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Then you can set
your target host
and port.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

A Host header.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

And two empty
lines after the
headers.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Burp displays the
response in the
Response panel.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
URIs, URLs, and URNs: Clarifications
HTTP Status Code Reference
and Recommendations 1.0
http://www.w3.org/Protocols/rfc2616/rfc2616-
http://www.w3.org/TR/uri-clarification/
sec10.html

SSL/TLS Strong Encryption: An HTTP Overview, History, Versions

Introduction and Standards
http://www.tcpipguide.com/free/t_HTTPOverviewHist
http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html
oryVersionsandStandards.htm

HTTP State Management

Mechanism (cookies) Burp Suite

http://tools.ietf.org/html/rfc6265 http://portswigger.net/burp/

ZAP
https://www.owasp.org/index.php/OWASP_Zed_Atta
ck_Proxy_Project

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Burp Suite Same Origin

HTTP Cookies and

OWASP ZAP
Sessions

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018