[MUSIC] Welcome back. In this lesson, I'm going to talk about how to prevent
cross-site scripting vulnerabilities. These prescriptions are given out
by OWASP, and they're tried and tested, so
these are really good rules to follow. First we're going to talk about
why we would use OWASP's positive prevention model in order to prevent
cross-site scripting vulnerabilities in our web applications. Then we're going to talk about the use
of security encoding libraries, and the various cross-site
scripting prevention rules. Now remember, the cross site scripting attacks
are always executed in the browser. That's a thing that we learned
from the last set of lessons. This lesson is on the longer side, so for
your benefit, I split it into two parts. After you view both lessons, you'll be
able to formulate a plan to prevent cross-site scripting issues
within your own organization. We have a lot to cover,
so let's get started. We're going to talk about how to prevent
cross-site scripting vulnerabilities. These prescriptions are given out by
OWASP, and they're tried and tested, so these are really good rules to follow. First, we're going to talk
about why we would use OWASP's so-called positive
prevention model, in order to prevent cross-site scripting
vulnerabilities in our web applications. Then we're going to talk about the use
of security encoding libraries, and the various cross-site
scripting prevention rules. Now remember that cross-site scripting
attacks are always executed in the browser. That's the thing that we learned
from the previous videos. So now why would we want to use OWASP's
positive prevention model in other to prevent cross-site
scripting vulnerabilities? The reason is because it reduces
the complexity of being able to determine where we can place untrusted data. The idea here is to basically treat
an HTML page like a template with a slot where developers
are allowed to put untrusted data. So keep in mind that putting untrusted
data in other places in your HTML page, is not allowed in this
positive prevention model. These allowed slots are what we're
going to talk about later on in various rules that we'll see. Now, this positive prevention model gives
us a way to add even further mitigations against future vulnerabilities, that could
be caused by changes in the browser. To sum it up,
it's effectively a whitelist for where it's okay to place untrusted data,
if you need to do that. Each of these so called slots has
different security rules, and this is to make sure that the untrusted data
can't be interpreted in a different way. The key here in order to
make this successful, is to use a security encoding library. This helps you to make sure that you
don't make mistakes when you encoding entrusted data. The secure encoding libraries
are already out there and they exist so you don't have to reinvent the wheel. And it's already been
tested by many people, so you can be sure that these
are fairly safe to use. One that is useful for
Java is OWASP's Java Encoder Project. So now we're going to talk about
the cross-site scripting rule from OWASP's cross-site
scripting rule cheat sheet. Rule zero,
this is the most fundamental rule. Do not insert untrusted data except in
the slots that we're going to talk about. And this is because we want to simplify
being to able to prevent cross-site scripting. And now as you can see here in these
following examples from OWASP, you should never put untrusted data
directly in between script tags. You should never put your untrusted
data directly inside an HTML comment. You should never put untrusted data
directly into an attribute name. And you should never put untrusted
data directly in a tag name. And last, you should never put
untrusted data directly in CSS. Rule number 1, use your secure
encoding library to HTML escape before inserting untrusted data
into HTML element content. For example, you want to use your
security encoding library to encode the untrusted data before you
use it as data between an HTML element. And here is an example pseudocode for
the server side document generation. So here, as you can see, the untrusted
input data is being fed into your securing coding libraries HTML Escaper. And that once you get that
output from the HTML Escaper, that's what you use as the input for the data that you put into the HTML
element, or the contents of HTML element. Now, rule number 2,
you want to attribute escape before inserting untrusted data
into HTML common attributes. So again, you would use your
secure encoding library to encode the untrusted data before
you use it as an HTML attribute. For example, here in this pseudocode,
you would initialize your encoder for your HTML attribute. And then you would take your untrusted
input data and feed it into your encoder. Then, the output of that process
is what you would put into, for example, your HTML attribute,
like this span title here. You can see a similar idea
with a Zend Escaper that is in a Zend framework as shown in this link,
this document here. Now, rule number 3,
you want to JavaScript escape before inserting untrusted data
into JavaScript data values. But here is a big word
of warning from OWASP. There are some JavaScript functions
that can never safely use untrusted data as input,
even if it is JavaScript Escaped. So, it would be really wise to steer
clear of these, just so that it's not putting you at risk unnecessarily, because
it's so easy to make a mistake here. Now bonus number 1 rule for
preventing cross-site scripting vulnerabilities is to use
the HTTPOnly cookie flag. And this is an additional mitigation
to prevent cross-site scripting. You would use and set the HTTPOnly
cookie parameter on cookies that should not be accessible by JavaScript. Now typically, you have to manually
set this cookie parameter, but in .NET web apps. It's turned on by default, so
it's good to be aware of that.