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.