Hi there. This is our last lesson in
the series of lessons on cross-site scripting problems.
For this lesson, you'll be able to compare and contrast
the three various kinds of
cross-site scripting vulnerabilities. Let's dive in.
Now, let's compare and contrast
the three various kinds
of cross-site scripting vulnerabilities.
We saw that with reflected
vs stored cross-site scripting,
in general, the difference was in how
the malicious script was delivered.
In the case of the reflected cross-site scripting,
the victim is induced into clicking on a link.
For example through e-mail or another website.
But in the stored case,
the victim fetches the injected script
from the backend database,
since the injected script was previously
stored on the backend database
of that vulnerable web application.
In both cases, there is a request to
the vulnerable web application and
the application server response back to the client.
Now, let's compare the DOM cross-site scripting
versus reflected and stored.
In general, you can tell the difference
between DOM versus reflected and
stored by the so-called round trip travel
of the malicious injected script.
We saw that in the case of
the DOM cross-site scripting vulnerability,
the malicious injected script started at the DOM,
but a request was never made
back to the vulnerable web application.
The client runs the DOM modification instruction
and once that malicious script.
However, with reflected and stored,
a request is sent back to
the app server and the app server
responds back with some malicious script
that's generated by the server.
To make this even more concrete,
I'd like to give a couple of
real-world examples of cross-site scripting.
The first example here I'm going to
mention is a medium article that was written
about cross-site scripting vulnerability that was
found even with a cookie set to HTTP only.
In this case, if you read this article,
the cookie was actually sent back as a response.
This is a case of a mistake
in the way that a cookie was used.
This resulted in this vulnerability.
Now, in the second case here, we have CVE-2018-10102,
and this particular vulnerability allows
an attacker to execute arbitrary script code in
the browser of an unsuspecting user
in the context of the effected site.
This may allow the attacker to
steal cookie-based authentication credentials.
This vulnerability was found in a WordPress plugin.
As of this recording,
currently there is no exploit for CVE-2018-10102.
However, I encourage you to
try your hand at creating a proof of concept
exploit in order to show how
someone could attack CVE-2018-10102.
In summary, we talked about
the general idea behind injection attacks,
and then we talked about cross-site scripting and
the browser fundamentals that are required in order to be
able to understand cross-site scripting in a deeper way.
Then we mentioned how pages are dynamically generated,
and then we talked about
cross-site scripting vulnerability types.
We also noted that it is important to use the HTTP only
cookie setting in order to keep
cookies private from access to JavaScript.