Hey everybody.
Welcome to next video.
In this very room we're talking about cross-eyed scripting now across the scripting is the ability to
modify the client side of the browser.
Now keep this keep in mind this is different from a server based attack where sequel injection which
we've used before is actually attacking in the back end or the back server now cross site scripting
is attacking the front end or the client only not the server only the client.
And that's all it's going to affect because you're going to be working with H2 AML javascript ex AML
that type of thing is the only thing you have to work with which is not interpreted normally by the
server as in like it's not a server language like P. HP.
So it's gonna be interpreted by the browser.
Now with that said you have a few things you can do with this book before I want to before we get into
that.
I want to explain what cross scripting is.
There's three different types.
There's a dom based reflected and stored or persistent depending on how you look depending on who you
talk to.
Now the DOM based in quick overview on Dom is a document object model and this is essentially in JavaScript
or in the browser.
It gives you a programmer the ability to modify the document on the page or the web page itself without
having to deal with reloading the page.
So being able to add things dynamically having things load in and out all that can be done through the
Dom.
And so nothing when you when you're anything you do in the DOM is not actually present on the page.
So if we right click through source this is the raw html that's being loaded at the current time.
If we wanted to change the html directly without using the Dom we would have to refresh the whole page
with with new HDMI up with Dom we can change stuff out as we go.
So a good example of this is this lets say this lets say this right here this title.
So if we wanted to change that if we do inspect element what we're actually doing is interfacing with
the DOM.
So if we come into here and say you know red team nation right that is interfacing with the DOM because
we've modified it through the Dom and not on the web page itself but if we refresh the page it goes
back to normal.
So that's that's how Dom works now reflected is where we actually put the payload onto the screen.
So if we put test here you can see it actually produces it on the screen.
So if we do not inspect element let's just do the source
area source we can see down here plops it directly to the screen.
Sounds good.
And then stored is something simple as a message boards or being test test and we sign this we can see
we have our option here no matter what page we refresh.
Well we go to a different page.
Come back here as you can see reflected does not keep our data at the bottom but stored.
We'll always see it.
We'll go and clear this so that's the difference between them.
Now to interface with Dom it looks like if we do English and we do select we see your default language
is equal to English.
So if you do a quick look at the source we can see that this is being set from the DOM with document
dot right.
So document is the object in the DOM that's referring to this page and it's writing these values all
right.
So that looks good.
So how do we deal with this.
So there's something important about cross scripting while stored or persistent will load onto the page
because under persistent it's normally stored in a database or in a file of some kind.
And then it will always be presented to the users or whoever it's supposed to be presented to with the
same data.
So if you're able to get it in there and you load the page up again as different user it will then execute
on the browsers.
And that's always going to be there until an admin figures out that if there and then has to remove
it.
But for Dom and reflected you have to pass the user a link they have to actually click on it.
So what do I mean by that.
So in the browser no matter what we do here it's fine.
But if we go into the browser and we add a little bit of JavaScript so we'll do an alert we'll do documents
dot cookie which is important script.
So we go out and close it up.
But in the browser we go and run that boom we can see that we execute it and we get a an alert browsers
we've executed javascript on a client with just a link.
Now he gave this link to somebody else and they ran it well in this particular case is my local machine.
But if you ran this on like Facebook or Microsoft or Google or whatever you find it and you send that
link to somebody they'll be able to access it and they'll get the same result.
However you can see here that HP session I.T. is the session I.T. used for me to interact with this
web interface.
So this is my user logged in.
If I take this and load this as a cookie into another browser on a different machine I will then have
taken over or hijacked the session of this user.
Now that's important.
So that's called Cookie stealing or session hijacking and what you can do with that is you can take.
You can send an admin a link as soon as they click on it it grabs the cookie from their browser but
whatever interface they were working with and it's and in this case it sends it to the screen for them
so they'll know immediately but we'll look at a different option and a little bit that kind of allows
you to take the cookie and steal it for yourself.
So this works on the DOM because it's being passed in this way now under reflected we again we showed
that if we run test here it runs it fine but if we go script alert document cookie and we go ahead and
close the script tag we go ahead and submit this oh I'll stick with that.
So let's uh let's write it here.
So if we do script alert
do document that cookie and script
script copy that it in and run it both get the same result.
We have our PSP session I.D. and everything looks good.
So again what's stored.
Go and test this test this where we can even lead them.
Message
message.
And we go ahead and plop that in there.
We go and sign the guestbook.
You can see that we're getting the same result.
However differences if we come back to reflected you can see we're not getting that result no matter
what we had here.
It's fine but we have to paste that in there to get our result.
But as soon as we come back away from it it's gone.
But what's stored.
We click on it.
Boom we're gonna get it every single time a user clicks on here.
Now that's great.
But that's not very useful from an attacker's point of view.
How can we use this a little bit more.
So what we can actually do is make the user give us the cookie so we can tell them to it or we can have
them redirect to a different Web site and have it have them give us the cookie instead.
So if we look here I've got simple HDP Python server running on port 80 80 and let's build us a payload
that we can use for this right.
So if we go ahead and get our script and then we'll do location or document that location is equal to
and we'll give this A.P. local host on port 80 and we'll do we'll just give it a fake file name called
of file not BHP and cookie is equal to empty.
And then we're gonna add document location document dot cookie and go ahead and close our payload.
So what we can see here is what we're doing is document relocation basically tells the browser to redirect
to this Web site.
But what's happening is it's loading that actually what it's doing is telling it to go to filed IP HB
with a parameter cookie equals and then we're dumping in the actual value of the user's cookies in the
U or else.
So that way when the web browser connects you'll see the cookie and you are out.
So we go and take this payload and we'll throw it in the we'll do it and reflected just to kind of show
you an example.
So if we go here go ahead and click submit.
We can see boom local host 80 80 file file not found but if we go to our our Python server which is
running it we can see there is our session 90 or P2P session.
So this is very useful and the same again the same thing can can work for Dom as well.
So if we come up here and load this we can see boom we got a new session I.T. and it also works for
stored.
However what I want to show you quickly is if we do this we go ahead and dump this in there you can
see it got cut off so if we had we went ahead and ran this it would just fail.
However there is a nice trick you can do.
So if you inspect the element like we modified the the name up here if we come into here and we say
the max length isn't 50 but it's five hundred then we should be able to paste the whole thing as you
can see we can.
So this is just client side so we can modify anything client side we want but if the server checks for
that length of characters then it'll go ahead and cut it off.
But we're going to go and test it.
We've modified it locally.
We're going to sign the guest book and perfect.
That's exactly what we wanted.
So if we come into here we see we get a third.
So if we kind of go back and we reload guest book it redirects us again.
So every user when they go and reload the e-book every time is gonna always get that same value.
Now this is good for when like I said when an admin comes through and clicks on this link or just views
this page then just clicking on this page and viewing it they'll get redirected and we'll get a copy.
Well what's interesting here is you could actually say in this particular case the stored was just redirecting
us here.
But what you can do is you can actually tell the file that you're going to so cookie in this case file
that BHP you can actually have filed a BHP redirect the user back to whatever page they were just or
the previous page that they were just on or a home page as an example.
So it looks a little bit less suspicious than just redirecting them to a page that doesn't exist.
So you can you can make this full fledge and just you know go all out if you really wanted to.
So there's a lot of options you can do here.
I want you guys to play around with this using document location is one way you can load these things
into links or images.
So you're the source of the image is the is the you are also to go ahead and load that.
So it looks less suspicious.
You can make the image with zero with zero height and then it ends up not being visible on the screen.
There's a lot of options you can do.
I frames with zero length and width and or width and height and then you won't see it on the screen
either.
So there's a lot of various ways you can do this.
So go ahead play around with this.
I assume by this point you've set up a DV W.A. play around with this particular one.
And as a quick example so if you go to DV W.A. security you can tell it which level of difficulty you
want.
It'll just make sure it'll just make each challenge slightly harder.
So under stored for example it won't let you do it just as easily but everything is possible even under
the impossible setting.
So go ahead and give this a try.
Play around does get familiar with cross scripting in practice and test it out with for example what
I want you guys to do is set up DV W.A. on one machine then what I want you to do after that point is
go on to your calling machine.
Another killing machine if you install it on one already and have the admin quote unquote on the killing
machine running the Web service DV W.A. logged in as admin you log in as a different user from one of
the past from one of the users we cracked in the previous challenge or the previous video and sequel
injection.
Go ahead and submit something on guestbook and have the admin user browse to the page.
But what I want you to do is have it full circle have it redirect them back to the home page after stealing
the cookie use a cookie editor.
Do Firefox or Chrome.
There's a lot of extensions that you can use or plugins for it that allows you to modify cookies create
recreate the cookie and refresh the page and see if you're logged in as admin.
So that gives you a full test of the full circle.