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.