[MUSIC]
Hello, in this lesson, I'm going to talk about the three
kinds of cross-site scripting vulnerabilities in more detail.
These include reflected cross-site scripting, stored cross-site scripting,
and DOM based cross-site scripting.
At the end of this lesson you will be able to describe and
discuss each of these cross-site scripting issues in more detail.
First we're going to talk in more detail about what reflected
cross-site scripting is, let's go.
Now we're going to talk about more in detail what reflected cross-site
scripting is.
To make this a little bit more concrete,
reflecting cross-site scripting can though of as.
Given as example, let say, a malicious user tricks
a victim into clicking on the link to vulnerable web application.
That link include a malicious script in the link parameter.
For example here we see this particular link to a vulnerable application, and
the one user input is JavaScript here.
This web application is vulnerable to reflected cross-site scripting.
And a malicious user says, I want to take advantage of this.
And they go in, they encode the script in the URL, and then they get someone,
a vulnerable user, to click on this link.
For example, through means of phishing.
Now this victim then clicks on the link, and
the victims client forms a GET request to the vulnerable web application.
The vulnerable web application responds back with a document
that has the malicious script embedded within it.
When the client receives that response from the server, the victim's browser runs
that malicious script during the regular rendering of that fetched document.
To give a little bit more of a concrete example,
here we have an example of a normal use case for this vulnerable web application.
This is how somebody would access this particular resource,
in this vulnerable web app.
It so happens that this page, this resource, is generated by the server
as this particular command here, that says to generate a body tag with
the onload attribute using the parameter for the URL given to it.
When the generated page is then served to the requesting client,
that requesting client will see this body tag and run the onload parameter or
onload attribute, which has a particular JavaScript in it.
For example,
the parameter that the malicious user has used is this particular JavaScript here.
Then it's encoded, and then this is sent to the victim and
the victim clicks on that link.
The victim's client performs a GET request to the vulnerable web application.
And the vulnerable web application server responds back
with a malicious script embedded in that fetched document.
Then the victim's client runs the malicious script
when it trials to render that fetched document.
In a diagram we can see how that works.
We have a malicious user that creates that link with the injected script and
sends it to the victim user.
For example, through means of phishing.
Then the victim user says this link looks ok to me, I'm going to click it.
The browser then fetches a resource with the script as a parameter in the URL.
This induces the server to generate the document without
that particular parameter as an embedded injected script.
Then once the server generates that page it sends it back to the victim.
You can think of reflected cross-site scripting as a server being like a mirror
reflecting awful malicious JavaScript back to the user.
Now let's move on to talking about stored cross-site scripting.
Stored cross-site scripting is a little bit easier to understand in that,
first, a malicious user enters a script into the application.
For example through a form or a parameter field.
So it posts the malicious script to the application.
And the application through normal processing
stores that malicious script into a backend database.
Then, during a normal run a victim user says I would like to fetch
a particular resource on that application.
The application so happens to generate its page or
its document using data from the database.
It takes that malicious script that happens to be in the backend database and
generates that page and sends it back to the victim user.
Now let's talk about DOM-based cross-site scripting.
DOM-based cross-site scripting is a little bit different.
Actually, a lot different from the two previous types that we talked about.
The reason is because it happens all on the client side.
Remember how the documents DOM was intended to be manipulated for
normal use to make the document more dynamic?
It turns out that malicious scripts can be injected into the DOM as well.
When that happens that malicious script is then run when
the DOM is rendered by the clients browser.
As you can see here, this particular example I got from OWASP.
And in this particular example this is how the client-side document is generated.
On the client side, there is a set of options that is generated.
It looks like this is a radio button for the client to see.
Now, these radio buttons are generated by taking as input a parameter from the URL.
Here an option is to select to English or
something else entirely that's controlled by a particular parameter in the URL.
Let's see that in action.
For example, in a regular use case,
the page request could look like this URL here where the default is set to French.
You can then send this particular script to the victim where
you have the default of the parameter set to a particular JavaScript.
This means that the script is embedded into one of the options within the dorm.
When the client then renders this, then that particular script is run.
Notice that in order to run this script, there was no request and
response between the client and the server.
This case the attacker used the URL parameter to feed in malicious data,
so the script and the client runs that malicious script during the DOM rendering