A stored cross-site scripting attack is where we actually leave something on the actual web server
itself to be able to do scripting to a different site, therefore fulfilling the whole definition of
cross-site scripting. Because what we've been doing up to this point is just doing little
pokey things to make sure that we can actually have response from the actual server that we're
messing with. And yes, those responses and scripts that we can send do retrieve good information for
us, but we're going to walk through a persistent cross-site scripting attack and see the difference.
Now let's hop on over to the side screen here real quick, and I want to point out a few things.
First of all, I have a couple of test scripts that we're going to be using for this demonstration
and understanding on the Kali box itself. And we're going to be using the Kali box to be that
second site where we retrieve all the information from our persistent cross-site scripting attack.
Now I'm going to put in the code box below where these are actually stored at on the Kali box,
so that way you can go take a look at them and see how we did everything. Because we have steel.php
and I'll zoom in for you here real quick, which is basically a PHP script to give us information
about the remote connection that's going into our target. And we've got to prep the target as well
too, and I'll put the code for that as well below. Now steel.php is going to record information
to stolen.txt, and we're going to tap over to that because you'll see that as we invoke
our cross-site scripting attack on BWAP, that updates will come into stolen.txt.
So let me go ahead and swap over to stolen.txt here. And inside of our stored BWAP website,
we're on the Ubuntu desktop. Now remember the BWAP is stored on the Windows 10.
And I also want to point out one last thing. This one works even better for us because as you can
see inside of my proxy settings, that I have no proxy enabled on here. There we go. And this allows
us to be able to do this truthfully, so that way we can see true information coming from the client,
in this case being the Ubuntu desktop. Now inside of our Ubuntu desktop, we're taking a look at the
actual blog entry in our cross-site scripting exercise within BWAP. Now if I haven't showed
you yet, if you go down to cross-site scripting under hack, it's under the cross-site scripting
stored blog. I'm going to zoom in for you real quick right there. And you notice that it's
listed as stored. The reason for this is because whenever we put in our code, which again is in
the code box below, we're going to have add selected and submit. Now before I hit submit,
I do want to point out a couple things. One, I have on the Kali box on the right side,
the stolen.txt file open to show that there are no tricks up my sleeve. This will update and you'll
see an option to reload this text file here momentarily. And again, all that coding is
inside the stolen or steal.php file. And you can easily access that and take a look at it for
yourself to see what all's in there. The information that's filled inside of here, based on our code
here, comes down to cookies. And what we're doing is we're using cross-site scripting in a
stored fashion to be able to put a script on the actual website, which in this case is BWAP,
to send to a third party, which is the Kali box, cookie information. And that cookie information
is determined inside of steal.php. But the scripting you see here is, is that we need to
identify where we're going to send all that info to. All the info is going, but the steal.php is
only going to pick and choose based on what's inside that script, what it wants. And you'll
see what it is here momentarily. So we're just telling it the script and keep in mind, no spaces
in here are no line breaks. You see that there's a space between new and image, but there's actually
no line breaks in this. Otherwise you have to use the percent sign symbols to be able to fill that
in like percent to zero for space. But in our script, we're going to go to the source of
0.53 steal.php and query that PHP file for cookie equals document plus document.cookie,
meaning send all of our cookie info over there and let steal.php figure out what it wants.
And when we click on add, uh, pop back in there real quick. We click on add,
watch the right side, the part right above me here real quick, as it takes its time to think
about this for a second. And you can see that the file has been changed and now I can easily go in
and reload the actual file itself. And as I reload, I'm going to zoom in for you because
this is a bunch of information that we captured from the actual client. And without the proxy
settings in the actual boot to itself, we're able to see that the true IP address of this
is 192.168.0.52. Had you left the proxy information in there, it would still populate an IP address,
but it would be the IP address of the proxy that you're using, which is why side note,
why VPNs are really good. So you see that we also collected the header of the request.
We got browser info. We get, uh, information about the operating system. And if I move over
to the right, let me get my mouse back in there real quick. We have also have date and timestamps
along with, and I'm going to highlight this here for you. So you see it very plainly,
make sure I get all of it together. Come on, you can do it.
Now I'm going to zoom in for you and you could see it that we have the actual session ID. And
this is really great information because if that session is still active, we can actually cross
into another form of attack called session hijacking, which is coming later. But you could
see that we have other information as well, too, such as that security tag that aligns with the
security tag that aligns with the BWAP site, noting that security is actually set to low on
the site. And we're keeping it at low right now, just to be able to get the basic understanding
down of what these attacks do. But again, all the information that we need to be able to build out
our reconnaissance platform of things that are actually going to this site. Now you may be
wondering at this particular point, is that good for just that one or is it good for everything
else? Well, I'm glad you asked, because now what we're going to do is go into the actual web
browser of the host Hyper-V that we go into the Windows server platform. We're going to be opening
up Edge and going to the exact same site for blogs. But in this part, we won't be actually
putting a code. We're just going to be viewing the actual blog itself. Now, here I am, and I've
simply just went to the actual site itself. And you can see right above me that that file has
changed. And we're going to go in and take a look at that file on a reload and see that the
information has in fact changed and a new entry has been created. Well, as I zoom in, you can see
that that is 192.168.0.1, Mozilla 5.0, Windows NT 10.0, et cetera, et cetera, meaning that we have
way more information about a different system that has actually gone to the blog site. And that's
it right there. Now, we didn't add anything from Microsoft Edge on the host Hyper-V. We just simply
logged into bwap.test and went to the blog site. This is where we truly understand the definition
of stored and persistence in terms of cross-site scripting. Because now that that script is in
there because of vulnerabilities to that website, the script that was inputted allows the attacker
to retrieve information and send to a different location or multiple locations. And it doesn't
matter if another user comes in and puts in another blog entry or deletes another blog entry.
As long as that original blog entry is there with the script in tow, then anytime a connection is
made to that bwap site, you will see the actual stolen.txt amend itself with cookie information
based on stolen.php or steal.php. And that's because the persistence allows for that script
to stay on that server as opposed to our non-persistent reflective cross-site scripting
earlier where we just did a couple of query manipulations to have information given back
to us or simply redirect to another site through a proxy. And while both of these are cross-site
scripting attacks, it's important to remember the difference between the two that one leaves
cookie crumbs and the other one is really just playing on a vulnerability that doesn't leave
much of anything. You may find something in the event log here and there about an error, but
really it's more of a passive approach. And different situations require different types
of attacks. So keep this in mind as we start going through the rest of this course and
looking at those different attacks and maybe even seeing how something like this can be applied.
Remember all code below and feel free to definitely check out the steal.php inside of
the actual Kali box.