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.