Welcome back, I want to talk about another vulnerability that we mentioned in the terror video, and
that is cross site scripting.
If you remember, this is a vulnerability for if 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 access attack there is reflected exercice stored access and dorm based
access and in this course will be covering first two, which are reflected and stored access.
But before we do that, let's quickly remind ourselves of a scenario as to how this attack looks like.
So the attacker finds an access 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 injected.
This is an example of stored access 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 will most likely be 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 access 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 will 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 access is a little bit different, it won't work on anyone that visits
the page.
It will only work if you send a link with malicious code 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 sessions dealing or by attackers to mine on target
species and create a botnet.
But our goal is to just find the bug itself and we will demonstrate how kookiest works later.
Let's get straight into it.
OK, so the thing that we need is our anticipatable running.
I got it already up and we also need to w a pitch, make sure that you have purposes running with intercept
turned off.
And once you do all of that, you want to navigate to the access reflected right here, because this
is the first example of access 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 excess vulnerability.
So what is this application do?
Well, here, it asks us to input our name.
So I will just go and type here, Aleksa inside of this input just to see what happens.
So if I click on submit.
OK, 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 will 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 ones hunting for access is type this 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 text.
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 will 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 Web page, hey, anything that's
inside of these script you should read as JavaScript code and not HTML code.
And this at the end is just the closed script, which is telling the Web page.
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, our Kopit.
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 access 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 in 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 side, 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 excess 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 similarly try to hear someone clicking on the link.
They click on the link that you send.
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 crosseyed scripting attack.
Anyone that opens this link will also execute this.
They do not 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 the source.
And here is the code for this specific page.
And they just paste our input right here.
They don't perform any filtering whatsoever.
Now that we cover the low security level, let's try to find access in a medium level security to see
if it works.
So we'll close this, go to the DV 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 access reflected and let's first type the name to see whether it gives the same
output and it does it printouts.
Hello.
And then the name.
So now let's try the same script that we did with the low security.
So open script text alert one and I will close script text click on submit.
Hmmm, it seems that they actually remove the script tax we can only see right here.
Hello, alert one and it doesn't give us a pop up window that says what 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 packs
and usually this type of filtering that you will encounter.
Why?
Well, because script tags automatically mean to the Web page that JavaScript code is coming through.
Some Web pages perform filtering just by removing this script tax.
But let's see whether they filter 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 the 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 they
did.
And here it is inside the print statement.
They use the string replace function onto the script tax and replaced it with empty space.
And that is the reason why we did the first example.
We didn't get the script printed out.
We only got one printed out since they removed our script tax.
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 ACR and then open another left arrow script close right there, and
then IPT close another right, terror alert one and close script attacks.
And the reason why we are writing scripts like this is because our Web page 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 Web page just to see if it would work.
And it does indeed work.
So what they essentially did right here is they split this script tag into two pieces and what the Web
page does, it only filters out entire script.
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.
So if I go right here and let's pretend that we're at the Web page will filter out the opening script.
So let's remove this.
And what do we get?
Well, we get another opening script tag that wont be removed, and that is why this would work as well.
Great.
Now let the see the attack where we still 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
Crosseyed 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 a cookie.
But where is it going to send it for this?
We're going to start a small python http server that we will send the cookie to show how to do that.
Well, we can go inside of our terminal and just type the command python dash and.
And then simple FTP server and then the port number where we want to host it, let's say port number
eight thousand, if I press enter, this will start the server on all interfaces on Port eight thousand,
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're going to keep 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 Eglash and then the IP address of our Linux machine
and then the port on which we are running that Python server, which in my case is eight thousand.
Then we can add another inclose single quote after it with add a plus and then document that cookie.
After that space and another plus and after that comes single quote, space, double quote, clothes,
Retiro, another single quote, close bracket dot and comma, and then the close script tax.
OK, 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 access, 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 has 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, that kookie, which is the cookie session of the user visiting
that page and running this code and sending that to the IP address on PT..
Eight thousand, 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're closing the script tax.
So let's give it a try and found this in our user input cockpit once again, go to our page and type
it here if I press, enter or submit.
Well, nothing seems to happen right here, but if I go to my Web server, here it is, here is our
target cookie.
Here is an 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 so how to find the access vulnerability in both low and medium security level.
As I said, this can be one of the most challenging parts of the course.
However, if there is anything you don't quite forget, 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 us toward access.
Remember this what we covered is called reflected access 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.