-: Welcome back.
I want to talk about another vulnerability
that we mentioned
in the theory video, and that is cross site scripting.
If you remember,
this is a vulnerability where we execute code due
to poor user input filtering.
In this attack, it is not
the server that is getting targeted
but the users that visit that website.
There are three main types of XSS attack.
There is reflected XSS, stored XSS
and DOM based XSS.
And in this course we'll be covering first two
which are reflected and stored XSS.
But before we do that, let's quickly remind ourselves
of scenario as to how this attack looks like.
So, the attacker finds an XSS vulnerability.
They inject JavaScript code that they want to
target to execute inside of their browsers
and then anyone who visits that web page
will execute the JavaScript code that you inject it.
This is an example of stored XSS
where the victim doesn't have to click on any links.
All they need to do is to visit the same page on their own
and they will execute that script that you injected.
So, how does this work?
Well, this is possible only in case the script
that you injected is getting stored on the server.
This would most likely be if there is, for example
a page where you need to type in some type
of a comment and then that comment will show on that page.
If that comment input is vulnerable
then you most likely will have a stored XSS
because, anyone loading that page,
after that, will load your comment as well.
And if your comment was a JavaScript code
they will execute that code.
So what does this mean?
Well, this means once you inject it, it'll stay
on the server and server will host that page
with malicious JavaScript code to anyone trying to visit it.
On the other hand, reflected XSS is
a little bit different.
It won't work on anyone that visits the page.
It'll only work if you send a link with malicious code to
to someone.
In this scenario, the server doesn't store our injected code
on their site, so it won't be hosting the page
with our code.
However, the code injection vulnerability could still exist.
If we find it, then we would craft our JavaScript code
that we want victims to execute, and we would send
those links to anyone that we want.
Once they click on the link and open the website page
our JavaScript code will also get executed.
Now, these types of attacks are usually used
for session stealing or by attackers to mine on targets PCs
and create web botnets.
But our goal is to just find the bug itself
and we will demonstrate how coakley stealing works
later.
Let's get get straight into it.
Okay. So, the thing that we need
is our method exploitable running.
I got it already up.
And we also need the D V W A page.
Make sure that you have burbs running
with intercept turned off.
And once you do all of that
you want to navigate to the XSS reflected right here
because this is the first example
of XSS that we are going to cover in this video.
Another thing that you want to do is you want to
set the security level to be low for our first example
and let's give it a try to figure
out whether this even has an XSS vulnerability.
So, what does this application do?
Well here it asks us to input our name.
So, I will just go and type here Alexa inside
of this input just to see what happens.
So, if I click on submit, okay, so it prints out
hello Alexa, what a welcoming application, right?
And this right here is an example of how it should work.
You type in your name
it'll welcome you with hello and then your name.
However, what happens once we try to inject JavaScript code
the most simple JavaScript code
and what we usually do first once hunting
for XSS is type desk code.
So, let me go in terminal just so you can see it better.
So, this arrow to the left
then script arrow to the right alert.
And inside of the brackets we put one between single quotes
or you can actually put anything you want
and you close the script tag.
And this right here is a JavaScript code.
It tells the page to alert us with number one.
And once again
you can specify anything between these quotes.
So, what does this mean?
This means it'll open that small popup window
at the top of the page where it should print out one.
And these script tags right here are just a way
for us to tell the webpage, Hey
anything that's inside of these script tags
you should read as JavaScript code and not HTML code.
And this at the end is just the closed script tag
which is telling the webpage,
here is where JavaScript code ends.
This alert is a JavaScript function that will
alert whatever is inside of these brackets.
So, let's give it a try and let's input this inside
of our user input instead of a name.
I will copy it, go to my page and paste it right here.
So, script alert and closed script.
I click on submit, and here it is.
We have XSS vulnerability.
Since it ran our code and it opened this small window,
we can see it says one, which is what we alerted.
Well, this was pretty easy since this was
on low settings we can assume, no user input was filtered
therefore we managed to execute this.
And as easy as this looks like there are many
many pages that are currently
on internet that are vulnerable to this type of bug
even with this simple script.
And as harmless as this looks, it can be used to
do some serious damage on client site depending
on what exactly you send them as JavaScript code.
Let me show you what I mean.
What you would do
after actually creating the XSS vulnerability
and finding it, you would copy the code
with the JavaScript code that you injected
and anyone that clicks on the link.
So, I will just simulate right here
someone clicking on the link
they click on the link that you sent, they press enter.
They will also execute
that JavaScript code as we can see right here.
They will also get a pop-up window that says one
and this is a reflected cross site scripting attack.
Anyone that opens this link will also execute this.
They don't have to type the JavaScript code themselves.
Now that we did this, let us also take a quick look
at the source code of this page.
So, I will open view source
and here is the PHP code for this specific page
and they just paste our input right here.
They don't perform any filtering whatsoever.
Now that we covered the low security level
let's try to find XSS
in a medium level security to see if it works.
So, I will close this, go to the D V W A security
and I will change from low to medium.
Click on submit and this will change everything to a medium.
So, let's go back to XSS reflected.
And let's first type the name to see
whether it gives the same output and it does
it prints out Hello and then the name.
So now let's try the same script that we did
with the low security.
So open script text, I will alert one
and I will close script text,
click on submit.
Hmm, it seems that they actually remove the script text.
We can only see right here.
Hello alert one.
And it doesn't give us a popup window that says one.
This means there is some type of filtering performed
onto this page because we don't get that window
and our code doesn't get executed.
By the output
of our application, we can assume that the filtering
performs removing of script text.
And usually this is type of filtering that you
will encounter.
Why? Well, because script tags automatically mean to
develop page that JavaScript code is coming.
So some webpages perform filtering just
by removing this script text.
But let's see whether they filtered it well enough.
They seem to filtered
script like this, but have they filtered
script like this?
What if I write it in capital letters?
Will that also be filtered?
Let's give it a try.
If I type script and then alert
and I also close the script with capital letters
click on submit and here it is, we got it to run once again.
So, all we had to do was write scripts in capital letters.
They only filtered out lower letter case script.
Let's make sure that that is the case
by going and visiting the source code.
And let's see, what did they do?
And here it is inside of the print statement
they used the string replace function
onto the script text and replaced it with empty space.
And that is the reason why we did the first example.
We didn't get script printed out.
We only got alert one printed out
since they removed our script text
but we managed to bypass this with capital script letters.
But what would happen if they, for example
also filtered the capital script letters?
Well then we could do something like this.
We could type and let me write it first
in terminal just so you can see it better.
We could write something like this scr
and then open another left arrow script, close right arrow
and then ipt close another right arrow
alert one
and close script tags.
And the reason why we are writing script tags like this is
because our webpage only filters the opening script text.
It only filters this, it doesn't filter closed script text.
So, what did we do right here?
Why would this work?
Well, before I explain it, let me first give it a try
onto the webpage just to see
if it would work and it does indeed work.
So, what I essentially did right here is I split
this script tag into two pieces and what the web page does
it only filters out entire script tag.
So, what the web page would do is it would see
this opening bracket, then script and closing bracket.
It would remove it
but then we would still be left with a script tag.
So, if I go right here and let's pretend that we are
at the webpage, we'll filter out the opening script tag.
So, let's remove this and what do we get?
Well, we get another opening script tag
that won't be removed
and that is why this would work as well.
Great. Now let us see the attack where we steal cookies
from the person that visits our link.
Those cookies could then be used to steal their session
and possibly enter their online account on that website.
If the website session management is also poor.
Right now, we will see only how to get that cookie
with cross site scripting.
So, to do this, we must first see where are we
going to receive the cookie value.
So, they will execute the code
and our code will extract the cookie
but where is it going to send it?
For this, we're going to start a small Python HTP server
that we will send the cookie to.
So, how to do that?
Well, we can go inside of our terminal and just
type the command Python dash m and then simple HTP server
and then the port number where we want to host it
let's say port number 8,000.
If I press enter, this will start the HTP server
on all interfaces on port 8,000.
Then the malicious JavaScript code
that we want to inject is this right here.
I will first write it in another terminal
and then we are going to cope it inside of the page.
So, we must first start with capital script because we are
on medium level, the regular script won't work.
Then we can type document dot, right, open brackets.
Then type one single quote, open another left arrow
and image source equals open double quotes htp slash slash
and then the IP address of our care Linux machine
and then the port on which we are running
that Python server, which in my case is 8,000.
Then we can add another slash and close single quote
after it would add a plus and then document dot cookie
after that space and another plus.
And after that comes single quote space, double quote
close write arrow, another single quote, close bracket dot
and comma, and then the close script text.
Okay, I know what you're thinking.
What even is this?
And this can be a little bit challenging for someone
who never encountered JavaScript before.
However, this is just JavaScript syntax.
It's just the programming language.
And after a few times trying XSS, you will pretty much
get used to it and it won't be that weird looking
once you write it, since I assume that for anyone
that hasn't encountered this before, this looks pretty
terrible.
But what we are essentially doing right here
is we are opening script text in capital letters because
of the filtering on our page.
And then we are writing the document dot cookie
which is the cookie session of the user visiting that page
and running this code and sending that to the IP address
on Port 8,000.
Since that is where we are running our Python server.
And here we should get printed out the cookie session ID
once someone visits our link with this JavaScript code.
And at the end
all we are doing is we are closing the script tag.
So let's give it a try and run this in our user input.
Copy it once again, go to our page and type it here.
If I press enter or submit
while nothing seems to happen right here
but if I go to my web server, here it is.
Here is our targets cookie.
Here is PHP session ID, and that is the cookie value.
It even tells right here that we got the security
on medium and this is something that we might
be able to use to steal their session.
However, more about that later.
For now, we saw how to find an success vulnerability
in both low and medium security level.
As I said,
this can be one of the challenging parts of the course.
However, if there is anything you don't quite fully get
feel free to post the question so we can clarify
it even more and make it understandable.
Great.
In the next video,
we're going to do this same vulnerability
just we're going to see how it would look like
if it was a stored XSS.
Remember, this what we covered is called reflected XSS
and target will only execute the code if they
open the link with our JavaScript code.
In the next video, we'll see the vulnerability
for the JavaScript code gets stored on the server itself.