So we mentioned other things. Well, one of those other things is, is that we can use reflective
cross-site scripting to be able to send a user unsuspectingly to another site. And there are
many different pros that you would want to do this, but I'm going to show you how to do it
first before we get into a bit of an explanation. So as you can see up above, I'm still inside a
burp suite and I have the original packet that we kept from the previous portion of the skill
in repeater. And I'm going to zoom in and show you what I modified here real quick.
And that is inside of the first name. There we go. Yep. Right there. You can see that inside
of my script, I just said window dot location, HTTP, CBT nuggets.com and into the script.
So when I send this over to my browser by right-clicking on it and get back in there first
show responsive browser, go back here and send the actual request that's been modified.
You can see that it goes straight to CBT nuggets.com and it is loading because it's
having to pull it from an actual web server. That's not local to this training environment.
Now, what does that really mean for us? Well, if you go back to, let me get burp suite ready to go
and turn interceptor back on for us. We go back to our credential to pay our first name, last name
page over here for the get process, ASDF, ASDF go. And we take that request and modify the ASDF
for that particular section. Oops, sorry. I need to copy it from the repeater and take that script
that we just did and paste it inside of their web request right there. And again, I'll have the
code for this below as to what it looks like. And then once it's modified, let me show you what it
looks like. You can see right there that we changed the first name to script windows location, etc,
etc. And we're just going to go up and click on that forward all. You can change it to individual
packets if you want as well. We're just doing a quick forward all on this. And as we send it,
you can see there's a little bit of thinking going on over here on the BWAP site.
And I'm going to show you down on the bottom here real quick as I begin to zoom in that it is
trying to connect to CPTNuggets.com on HTTP regular, not actual HTTPS. I'm going to let,
oh, it's not doing it because I have all the interceptor on. I'm just going to forward all.
Actually, I'll turn the interceptor off for a second. You can see that it loaded that
CPTNuggets webpage up. So, why would this be a pro for reflective cross-site scripting if
we're trying to act maliciously or test security settings? Well, straight to the point,
you're confusing the user and basically hoping and working on the fact that they may not know
what the website is supposed to look like. Because if it goes seamless and we intercept
the request, modify it, and then push it on its way, you can see here that they were sent to
another website. Okay, so the user's coming up saying, that must happen after I put in my first
and last name. That's normal activity. Well, you go one step further, you could actually set up
a fake website that's mirrored from, let's say, our bwap.test site and redirect them to that.
And so, inside of that Windows location, they go to our, they put in their first and last name,
and then they get sent to a site that looks like bwap.test and start working from there,
putting in all of their PII and other great information. We take that along with username,
passwords, and all this other stuff and start building the collective to go through and do
even more intrusive attacks. Now, that's just one method, because you have to have that site
set up. In this particular example that we just had, I sent them to cbtnuggets.com as a
demonstration to show how we can intercept and make sure that web request is going where we
want them to go to. In reality, it takes a lot of work behind the scenes to be able to prep
everything to make it look as good as possible. I also want to take this time to kind of explain
in a slight addendum, how do we actually get the user to be able to do this in the first place?
Well, in order for us to be able to intercept this traffic, we know that we have to have a proxy
in this current lab setup between the actual user and the actual web server itself.
How does that proxy get there, or that proxy setting per se? Well, we know that inside of
our Ubuntu desktop that we manually went in and put that proxy setting there.
There's many different methods that we can go through and do this. One of them could be that
we have them click on a malicious file that changes the settings through like a registry
edit or some sort of configuration file behind the scenes, like we did with directory traversal
and file inclusion attacks. Or we can go one step further and start doing things like DNS poisoning
to confuse the DNS server that they're on for name resolution to say, instead of going to Google
at 8888, we want you to go to Google.com at 10.10.10.10 as an example. But DNS poisoning
is a different kind of attack, but sets us up to be able to send users to a different particular
website. Now there are a couple of give and takes that kind of give this away. In our examples,
we're using HTTP, which automatically shows a non-secure warning inside of the web browser
itself. Security training at the organizational level is usually a wonderful way to be able to
get users to identify, hey, something don't look quite right. Because if we go back over to our
side screen real quick and look in the lab, you can see as I zoom in for us here inside of Ubuntu,
next to CBT Nuggets is a exclamation point on the lock, meaning that this website is not secure,
which is also why we're able to capture all of this traffic in our practice environment.
But we could further expand on this later on in our course as we start to understand SSL and TLS.