[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.