Now we're going to start talking about the rules for
DOM based cross-site scripting prevention.
Now we have to talk about
some terms before we can do that.
The first one is a JavaScript Execution Context,
and the JavaScript Execution Context
is basically a way that
the JavaScript runtime uses to
track the JavaScript code as it's executing.
The JavaScript code is tracked using a call stack.
Now this means that for example,
a call to a JavaScript function causes data that's
related to that function call
to be pushed onto the call stack,
and then when the JavaScript function is ending,
in order to return from that function,
the data that's related to
that currently running function
is popped off of the call stack.
Now you can think of a JavaScript execution context
like a set of painters palettes,
where the palettes and their colors are
the data related to a function.
So for example, you have
a pallet with different hues of blue,
and another palette with different hues of red.
The first instruction says to use the palette with blues.
So you put it on
your painters stack and then you
go and use your palate with blues.
Then the next instruction says to
use the palette with reds.
So you put that palette on top of
the stack and use that palette with reds,
and then the next instruction says to
stop using that palette with reds.
So you pop that pallet off of the stack.
Then the next instruction says to
stop using the palette of blues.
So you pop that pallet off of the stack.
Now if you'd like more specific information,
more detailed information about
JavaScript execution context,
here is a link in the slide to
a pretty decent description of
the JavaScript execution context.
Now the second term that we're
going to use when looking at
the DOM based cross-site scripting
prevention rules is this term of parsers.
What is a parser?
A parser is a program that analyzes a string to
determine whether that string follows
a specific grammar for that parser.
So basically is a program that checks whether
that string has a correct syntax
for the grammar that it's examining.
So for example, if I have a string that has
the proper grammar for a Linux command let's say,
and I put that into a parser,
that parser will check to see whether
that string indeed represents a known Linux command.
Now the browser uses
different parsers for
different types of document entities.
So a parser for HTML,
a parser for URL,
a parser for CSS etc,
and the browser switches contexts
depending on the type of
document entity it's trying to parse.
So now that we have these terms out of the way,
we can look at the particular DOM rules.
So DOM rule number one,
HTML escape then JavaScript escape before
inserting untrusted data into HTML of your DOM.
So before adding an element into the HTML of DOM,
first HTML escape then JavaScript escape
your untrusted data using your secure encoding library,
and here's an example pseudocode of what this means.
So here's your untrusted input and you put it through
your secure encoding library to encode it in HTML,
and then take that result and JavaScript escape it,
and that whole result is what set as
the inner HTML property of this particular DOM element.
Next, DOM rule number two.
Before modifying an HTML attribute
and adding untrusted data there,
use your secure library encoder and
JavaScript escape that untrusted data.
In other words, JavaScript
escape before inserting untrusted data into
HTML attribute subcontexts within the execution context.
So here is an example.
It's a pseudocode example from OWASP.
As you can see here,
here is the untrusted input
of the company name and that is
JavaScript encoded before it's set as an HTML attribute.
DOM rule number three,
avoid including untrusted data
within your JavaScript code,
because it is difficult to cover all of
your edge cases even when
you JavaScript encode that untrusted data.
DOM rule number four.
When inserting untrusted data into a CSS attribute,
JavaScript escape it using your secure encoding library.
Furthermore, you want to URL escape before JavaScript
escaping when inserting untrusted data
into the URL CSS method.
So here is an example pseudocode from OWASP.
As you can see here is the untrusted data
fed into the URL encoder or URL parser,
and the result of that is then
fed into the JavaScript as skipper or encoder.
The whole result of that process is
used as input for the URL CSS method.
DOM rule number five.
Using your secure encoding library,
first URL escape and then JavaScript escape
the untrusted data before using it in a URL attribute.
So as you can see here from the OWASP example,
this is a pseudocode from OWASP.
Here is some user data that is used as a URL.
So what they do is to feed
that untrusted user input into
the URL encoder and then from the URL encoder,
the output of that is then
fed into the JavaScript encoder
before putting it as a URL attribute in the DOM.
DOM rule number six.
You can use the "textContent" property
to place untrusted data into the DOM.
This is because it is treated solely as text,
and as you can see from this OWASP example,
you can feed the untrusted data into
this DOM element called textContent,
and because of that,
this untrusted data is treated
solely as texts and this never gets executed.
So in summary, we talked about why it's really
useful to use OWASP's Positive Prevention Model,
and we talked about making things easier for us
by using security encoding libraries.
Then we talked about the various cross-site scripting
prevention rules as well as
the DOM based cross-site scripting prevention rules,
and remember that cross-site scripting attacks
always execute in the browser,
and for more detail,
look at OWASP's DOM based cross
and scripting prevention cheat sheet,
as well as the cross-site scripting
prevention cheat sheet on the website. Thank you.