previously we mentioned there are three different types of ex ss vulnerabilities.
We have the reflected X. Ss where we actually put the Xs s payload or the evil code
in the U. R. L. And then we'll have to send this U. R. L.
To the target person to load in their browser.
And once they do our evil code in here gets executed.
Now this is good and not very suspicious because remember Target dot com would be
a popular website that the target uses and therefore they will trust that website.
It's not gonna seem malicious.
We also spoke about stored excesses which
is basically exactly the same as reflected.
It gets you to compromise users as well. It injects javascript code in the target.
The only difference is in this case instead of having to send the U. R. L.
The evil code is stored somewhere possibly in the database and therefore the
code will be executed to any user that loads the vulnerable page.
You won't have to send them the payload within the U. R. L.
Which makes it much more convincing.
You won't even need to communicate directly with users.
You can simply inject your evil code and just wait for people to
load that page and then get the evil code loaded on their website.
In this class we're going to talk about dumb
based xs s vulnerabilities so we have reflected,
stored
and dom is the third variant of excess S vulnerabilities
similar to reflected and stored. It's an excess vulnerability.
So allows us to run javascript code in the vulnerable web pages.
We can discover it exactly the same as the start and reflected.
The only difference is there is no
communication between the client and the web server
when we exploit such vulnerabilities so they
happen or occur completely within the dome.
Adam is basically all the objects that you see on a web page.
So when you load the webpage and you see all the elements on it.
So let's have an example here you have a webpage here we have all these elements on it.
All of this is called the dumb and each one of them is an object within the dome.
So this is an object, this is an object. This is an object.
The text in here is an object. Everything is an object within the loaded page.
But it's all has already been loaded within your browser
and
says
happens within this document. So when you exploit it,
no communication happened between this object and the web server.
The main idea is because there is no communication between the current loaded page,
the document and the server.
Nothing is going to be started on the server side.
There's no logs to show that this has been exploited.
If you have server side filters,
they're not really gonna work because again nothing is
sent to the server and no server side protection.
Whether any kind of protection you have on the server side
is useless because nothing is being sent to the server again.
So usually you have the client in here. You send a request. So we send the client.
If we discover an excess s vulnerable webpage we send this link to the target.
This is an example of a reflected Xs s as we've seen before.
So you have target dot com and then our payload here in yellow.
The target is going to send that to the server.
The server will send a response so that the response is basically going to be html
and CSS and javascript basically what makes up the page but this part of the payload,
the evil code or the evil payload will be
embedded within the page that this guy will get.
Therefore,
if there is any type of protection in here it will actually
detect that there is evil code in here and possibly strip it
now in the case of a dumb ex ss
let's assume you have a text, say a text box. For example for search,
this is known as a source,
a place where you can literally just type user
input and for example when you hit enter,
when you start searching within the search box,
nothing is sent to the web server.
It's going to run client side code in here and therefore
it's going to substitute your evil code somewhere
within this client side code which is written in
javascript as well and as a result it will
execute your evil code within this javascript function.
Now these dangerous javascript functions are usually known as sinks.
So you have a source where you actually put your exploit or your javascript payload,
this will not be sent to the web server.
It will be used within other javascript code within the page.
And because this javascript code is vulnerable, it's dangerous.
It's gonna execute your payload therefore
resulting in an excess s vulnerability and
all of that is happening without sending anything to the web server.
And that's the main difference between dom based X. S.
S and the reflected and restored
and the reflected and restored.
The payload basically comes from the server back to
the client as a result of a request.
But in that in this case in the dumps case nothing
is sent to the server basically put something in here.
It's already used in javascript which is already loaded
on the browser and therefore the code gets executed.
Now in the next lectures will cover a number of examples of done based X. S. S.
And you'll notice that discovering and exploiting these vulnerabilities
is very similar to reflected and stored Xs.
S.
The main difference is the way they occur in the background