Hi there. In the last couple of lessons,
we discussed briefly about cross-site scripting,
HTTP, and document isolation.
In this lesson, we'll continue on
this path and talk about the DOM,
which is also known as
the Document Object Model
and dynamically generating pages.
These two topics are shown on
the concept tree in their own branching area.
Once we've discussed these concepts,
will be able to dive deeper
and discuss cross-site scripting.
You're doing great. So stay with me.
It will all connect soon. I promise.
Now, to begin, let's recall that HTTP
is a protocol for fetching resources or documents.
Now, we can talk about the DOM,
which is also known as a document object model.
Remember that HTTP is
a protocol for fetching resources or documents.
In the early days, documents were static.
The question became, how do we
make these documents more interesting?
Someone develop this idea of the DOM,
the Document Object Model.
The DOM is a way for us to
think about a document as an object.
When I say object,
it's in the object-oriented sense of the word.
It's a form of an abstraction that allows us to
manipulate the document that's fetched from the server.
This means that the document has
properties and methods like
objects have properties and
methods in the object-oriented sense of the word.
Two important properties that documents have are,
one its origin into its cookies.
The DOM is an API for
document manipulation on the client side.
The way this works is that there is a script
or instruction embedded within a document,
which the client fetches from the server.
These instructions are run on the client's browser.
These instructions can access parts
of the document via the DOM in
order to make the document more
interesting to see on the client's browser.
Let's recap. HTTP is
a stateless protocol that allows fetching
of resources or documents.
We know that cookies are used to
add session state for HTTP.
We also saw that we need to use
the HTTP only cookie setting on
the server side to create that cookie,
to send back to the client side in order to
prevent access on the client side through JavaScript.
JavaScript on the client side can use the DOM
of a document to access cookies.
Remember this is very important
that cookies that are accessible via
JavaScript can be stolen
using cross-site scripting vulnerabilities.
To keep cookies within their originating documents.
A policy is applied and
that policy is called cookie scope.
Remember that cookie scope is less
restrictive than Same Origin Policy.
Now, we're going to talk about
dynamically generating pages.
Remember how we said that the DOM was invented to
basically make documents more
interesting to look at on the Internet.
The way this is done is two ways.
One way is through server-side and
another way is on the client side.
On the server side, you can do this by
manipulating a document or generating
a document before sending
back to the client as a response.
Then on the client side,
this can be done by modifying the DOM using
JavaScript that the server
has given it on the client side.
It's very important to note that on
the client side when the pages dynamically generated.
There is no communication back to the server to make
dynamic pages when it is done on the client side.
This is important to know,
because it helps us to understand
the difference between reflected and stored
cross-site scripting
versus DOM based cross-site scripting.
Now, we can talk about
cross-site scripting in more detail.
The idea here is for an attacker to be able to
obtain a session cookie in order to impersonate a user.
What about using Same Origin Policy?
Why can't Same Origin Policy help us here?
This is because cross-site scripting
bypasses Same Origin Policy.
The reason why, is because the malicious script is in
the same document object as
the cookie that the attacker wants to steal.
In other words, the malicious script is
injected into the document object.
The document that the vulnerable client is viewing.
The tactic that an attacker would
take is to use a malicious script
and inject that in the document of the vulnerable client.
Now, this is the reason why it's important to
set the HTTP only cookie header.
That's because as we saw before,
the HTTP only cookie header says that,
the cookie is disallowed to be accessed
by JavaScript on the client side.
Let's assume that we didn't know anything about
the HTTP only cookie setting.
We just have a server that sends back a cookie
to the client and that is
how we create the client sessions.
Now we can imagine how
cross-site scripting can be performed.
Cross-site scripting has three different ways
you can take advantage of,
depending on the vulnerability
that exists in the web application.
One way, could be something
called reflected cross-site Scripting.
If your web application is
vulnerable to reflected cross-site scripting,
it means that a malicious script can be
injected into a URL parameter for example.
The URL parameter is then used by
the server to then create
the page with the injected script in it,
and right away sent it back to the client.
You can think of it as having malicious script being
reflected off of the server and back to the client.
That's why it's called reflected.
In the store, cross-site scripting way,
If your web application is
vulnerable to sort cross-site scripting.
This means that an attacker could
inject malicious script, for example,
using post-data, and have
your vulnerable application store
that information in a backend database.
Storing this data on a backend database,
is just taking advantage of
normal operations on your web application.
When a client wants to fetch
a particular document which
embeds data from that database.
The server generates that document
with that injected script,
then the client fetches
that information and renders it on their browser.
In the third case, if your web application is
vulnerable to DOM based cross-site scripting,
the way this works is when
the DOM environment of the document is modified.
Say a URL is used to generate data that modifies the DOM,
then you can have malicious data or
malicious script injected when that DOM is modified.