Challenge 1: Solution

[00:00:00]
>> Mike North: So we're going to look at how we can cause some trouble, and see if we can stir up the other cross-site scripting bug that wasn't directly shown to you. So the first one is basically this, when you create a new account this is the way you'd be able to spot it easily and something that already had some data in there.

[00:00:21]
If someone said, Mike's checking like this, and I create a new account. Oops, looks like my server's restarting too. Mike's checking, new account. So the fact that we see this in bold, that should raise a little bit of a red flag. If you're a penetration tester and you see this, you just got curious.

[00:00:44]
You just thought, hey, this is not just raw text. There is some markup, and I wonder what markup is allowed, and I wonder what they are preventing? And in this case we don't happen to be preventing anything. So we could do something like this, totally safe account, not a hack at all, script, alert.

[00:01:16]
>> Mike North: I put semicolons in my JavaScript even when I'm cross-site scripting. Take that Brian Hull. So, and now you see that we've actually, this is the little skull up here. We've gotten the browser to run our code. So I'm seeing it twice here. Here's another cross-site scripting attack.

[00:01:37]
If we inspect this here, I mean it was sort of blurred a little bit with the first one, so it was difficult to pick up. But this is actually a separate vulnerability where a validation message, in this case it's a success message, it is sent back to the user.

[00:01:53]
So this is a stored and a reflected cross-site scripting attack. Because this, what we're looking at now, inside this alert panel, this is a transient piece of data, right. The third one in the profile page. So when you see something like this, you might have gotten curious and deleted a letter here.

[00:02:16]
No user found example.co. What if we did no user found script alert hi? And we can make this work here. Browsers typically, Chrome will prevent this. They have a cross-site scripting filter where if they see a portion of your URL that exactly matches code that it's being asked to execute, it'll pump the brakes.

[00:02:41]
I've done something deliberately, I'm trying not to sand bag Chrome here. I've done something to deliberately circumvent this by, I basically add a console log done to the end of the script tag. So if we were to look at what happens here, I just alter it enough that it's like, well that's not a text for text match for something that was present in the URL.

[00:03:08]
So this is the kind of error you would absolutely see in older browsers, Chrome saves us from that. So if we were just to, instead of doing this replace, if we got rid of that. Which I will just for demonstration purposes here. And wonder if I need to restart.

[00:03:31]
>> Mike North: So there's my first error.
>> Mike North: And this is the second one. See look at the nature of the error, the last line in what Chrome is telling us. This type of error is called blocked by XSS Auditor, detected some unusual code on this page. And if we look in the console, I think it gives us, let's see, any more information?

[00:03:57]
Let's preserve the log.
>> Mike North: So the XSS Auditor blocked access to this script because the source code of the script was found within the request, right. So you can disable this, if you really wanted to, from your app by saying XSS protection in a response header and the value of that header would be zero.

[00:04:23]
That's telling Chrome to back off. I would be interested in hearing if there's a good reason for disabling this. It's pretty nice. But in older browsers like this, there is no XSS filter. It would be really easy to slip this thing by. So those are the three errors, the one is this that we're looking at here which I had done some shenanigans in my back end, right.

[00:04:51]
It's not immediately obvious what this is, what's going on here. Imagine instead of console log done it was some tracking event that's like, yeah, we're just gonna add something like page loaded, something like that. Fire beacon out to Google Analytics. There are ways to make this look not so suspicious.

[00:05:09]
But this line of code here just modified things enough to where Chrome was like, well no, that is not an exact match for something I found inside the request. And so you are free, that must be code that originates from the program that you wrote, and in part it is.

[00:05:27]
And so now it would work.
>> Mike North: This is gonna bug me, I'll fix this between exercises for you all. So this is number one, number two is on the main page here where every time we reload this page, this here is evaluated as a cross-site scripting error. Now if I refresh the page and don't touch it, you're gonna see that it becomes pretty easy for us to figure out where these inline scripts are.

[00:06:02]
Notice that the page stops rendering at that specific point there, that's where the script tag is. It's right after not a hack at all. And you see we don't get the account number, we don't get the balance. Now this is just because this is a blocking call alert freezes execution.

[00:06:22]
But this is, just know that it's evaluated inline. So whatever's happening, if you set a couple break points you can figure out is this part of data or what's going on. The third one of course is when we create a new account. We already showed you, that was in that little alert drop down.

[00:06:41]
So that was, that happens to also be persisted but that's also reflected back at us as soon as we create an account. The consequence there being you could create a form that would post to that address, and then users would potentially see the HTML resulting from that post call.

[00:06:58]
There are two different ways to exploit that. So those are our three cross-site scripting attacks. Now we're gonna move on to talking about how we can make it not so easy to send links to people and trick them into running code as their authenticated user. So we'll talk about how we can defend against them.