[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