[MUSIC PLAYING]
In this lab, we're going to do cross-site scripting
but authenticate it this time, which
means we need the cookie for the session after we log in.
Let's jump into the environment.
And I can show you exactly what that means.
You can open up a terminal and check our IP address.
And we see we are on this subnet right here.
So I'm just going to run Nmap scan against that network,
replacing the two with a 0.
While it's running, I know that this is a web app lab,
so I'm going to open up the browser.
And I know that it is this network with a .3 machine.
And it brings up bWAPP.
And we see over here the .3 has port 80 and 3306 open.
That makes sense for bWAPP, which is an OWASP tool.
bee and bug.
Authenticate, and let us in.
I don't need to save.
We can go to HTML Injection down here
or from this dropdown, HTML Injection Reflected
and hit Hack.
And it takes us to this great page.
This is the page that we know is vulnerable
to cross-site scripting.
But we're going to play with it and learn it.
So say we have Joe Schmoe.
Joe Schmoe is a friendly guy.
We hit Enter, and it goes, and it now
shows our input in the browser.
And it does that because it sent this get request
with these variables to take in from the form.
Let's look at the form real fast.
Careful.
This might be illegal in Missouri.
But we have a form on that page, and it's
going to utilize a get method to htmli_get, passing
these variables.
And if they are passed, then it's going to display welcome
and then whatever is passed.
Well, it just throws it in here into the HTML document.
So we know that we passed a string,
and now it shows up in the document.
Well, what if we pass something else?
What if we passed something like script alert 1 backslash script
like that?
What happens there?
Well, it puts it right on the page.
Maybe-- wow, it puts it right on the page.
Maybe it will interpret it.
Let's play with it a little bit.
Let's pop Burp Suite.
Turn on our intercept.
And let's look at the actual get request that goes with this.
So we've got our cookie here for our session
from being logged in.
And we've got our variables.
Let's send this over to repeater and see
what our responses look like.
So here's the normal response.
This is very similar to the page we just had up.
Went too far.
There it is.
82 it says welcome Joe Schmoe for Joe Schmoe.
And if I did script alert 1 close script and send that.
[INAUDIBLE] Keep going.
There, too far.
Right there.
I messed it up, so it's not showing it properly.
Well, let's do it the right way, then.
Forward slash.
Scroll down, and Burp is interpreting it
as a script block.
I wonder what the browser is actually doing.
This is bad.
You would want-- if you had a form,
you would want some standardization between your
get request and your response.
That way, whatever they're passing in here
doesn't actually get interpreted.
This is cross-site scripting.
So let's run it with a tool cross-site scripter.
Automatic framework to detect, exploit, and report
cross-site scripting vulnerabilities
and web-based applications.
Now, we want to use this with our machine.
So we've got cross-site scripter to attack URL
and our 212.191.3.
That is accurate.
The htmli_get, and then we need to replace
our first variable or the variable
we want to test with this capital XSS.
Then we're going to use this cookie which
is right out of Burp.
mpi6 is what this one is saying.
So let's grab that and make sure that this is accurate.
Security level 0 mpi6.
Checking this is a very important.
Different than what I had in my notes,
that's why you got to double-check.
And it looks like it is vulnerable
to cross-site scripting.
Well, is it vulnerable to the type of attack
we are interested in?
Let's throw a proof of concept in there.
Let's do dot script.
This is just HTML code, and then alert 1
is a built-in function for HTML.
And it looks like it's vulnerable.
We have this final attack.
It is the URL.
And then, right here, we've got %3Cscript%3E.
So that's hex.
It's URL encoding in hex what we passed in.
That's a triangular bracket left, triangular bracket right,
some more encoding, and the rest of the form.
But you can see in there there's alert 1 and the scripts.
And then, this is hex URL encoding.
Let's go over to the browser.
If we take that, and we throw it in the browser--
turn off FoxyProxy-- we know what gets passed
is going to get interpreted.
So let's see what it passes.
It obviously popped up the box of the 1, so that's something.
But you can see here in the URL that it interpreted
it to be script alert 1.
And then, it looks like this is the-- that %2F, your backslash,
your forward slash, and script.
And that worked.
Welcome-- and it says nobody down there.
We've got this box, alert box that popped up with 1.
You can hit OK, and it still says Schmoe.
So it has all that, and it still says Schmoe.
Well, let's take a look.
I want to inspect this page source in here
and see what it got passed.
Oh, OK.
So welcome, and then that script, and then Schmoe.
So this got interpreted.
That's why it popped up the box, and it still showed Schmoe.
And that is authenticated cross-site scripting.
It's very basic what we did here because this is not
a full course on what then you could
do with cross-site scripting.
That's going to be in the web app pen testing
course that stand-alone, not part of the pen testing student
pathway.
But for here, now you can see at least the difference
of what happens if the vulnerability is
behind a login.
If you need to be authenticated as a user,
this is how you do it with a session cookie.
And with that, we will move on to the rest of the course
and the other labs.