Welcome back, to continue
our discussion on cross-site scripting.
In this lesson, we'll be talking about HTTP.
HTTP is a protocol that
allows us to be able to view documents on the internet.
HTTP is a protocol that sent
over another protocol called TCPIP.
For this lesson, I'm just going to briefly
note that we're going to simplify things here,
and not discuss HTTPS.
As HTTPS is an encrypted version of HTTP,
but HTTP is a way for us to fetch resources,
and when I say resources,
is things like web pages,
pictures, scripts, that sort of thing.
At the end of this lesson,
you'll be able to identify how HTTP and
document isolation play a role in cross-site scripting.
Let me show you what I mean.
Now we're going to move on to talking about HTTP.
HTTP is a protocol that
allows us to be able to view documents on the internet.
HTTP is a protocol that sent
over another protocol called TCP.
Here, I'm just going to briefly note
that we're going to simplify things,
and not discuss HTTPS,
but HTTPS is an encrypted version of HTTP.
HTTP is a way for us to fetch resources.
When I say resources,
it's things like web pages,
pictures, scripts that sort of thing.
HTTP is a client-server protocol which
means that the communication
is started on the client side,
HTTP is actually a human readable protocol.
One thing to note that is really important about HTTP,
is that it is a stateless protocol,
that means whatever current request you are running has
no relationship to the previous request that you ran.
Now, the question becomes,
how do you add state on top of
the HTTP protocol such
that you can have an actual session?
The answer to that is using something called cookies.
Now, cookies at state to HTTP,
and what this does,
how this is used as basically the server
sends a key value pair which is labeled as a cookie,
and it's sent over to the client, through HTTP.
Then, on subsequent requests to the server,
the client sends back that cookie that he received first.
So, this allows the server to be
able to identify the client and the session,
that the client is currently using.
Now it's possible for a
JavaScript program which is embedded
in that document to read or
write cookies related to that document,
this is done using something called the DOM.
We'll get to the details of what the DOM is later.
Now the name of the game is basically to protect cookies,
because cookies are used to
identify your clients session state.
We don't want for example,
someone to be able to pretend that they are us.
Malicious users could steal clients cookies
to impersonate the user and take over their sessions.
How should we keep cookies private?
The answer to that,
is the server-side sets a cookie parameter to HTTP only.
This makes it such that the browser makes sure that
the cookie is not accessible using JavaScript.
It says, "No, you are
not allowed to access this by JavaScript,
and it's only sent to the server."
However, later we'll see that sometimes
mistakes in code can still lead to cookie access,
even with HTTP only set.
We want to be able to effectively isolate
documents from each other and protect cookies.
We can set something called Cookies Scope,
and you can specify
the domain and the path for the cookie scope.
This basically sets and specifies what URLs
are allowed to get that cookie back from the browser.
When you have the domain parameters set in your cookie,
this basically specifies which hosts can get that cookie.
The detail here is that,
if this domain parameter in
the cookie header is not particularly set,
it defaults to the domain of
the current document of the browser.
It excludes the subdomains of that current document.
If it is set, then it allows domains and subdomains.
In the path parameter,
you can specify which path has to exist in
the URL in order for
the cookie to be set back to the server.
Another way that document isolation
happens or cookie isolation effectively,
is also something called Origin.
We're going to talk about origin first in order to
understand what Same Origin Policy is.
Same Origin Policy is a policy that
basically isolates JavaScript such that,
only the document that has that
JavaScript can be accessed by the JavaScript.
We need to understand what origin is.
Origin is something called a
tuple which is a set of three pieces of data.
Basically, which are the protocol,
the domain, and the port.
We can roughly think of the origin in
terms of inter-process communication.
Specifically, what process is it that has
served the document that the client has requested?
Remember how we wondered if cookies can be
accessed using the DOM through JavaScript,
is it possible for
one document with its JavaScript to have access
to another documents cookies
served from different origins?
The answer is to use Same Origin Policy,
and we'll get to that in a little bit.
Also as a reminder of how we keep these cookies isolated,
is we used cookie scope.
I want to take a little bit of time to say here,
that our cookies scope is actually less
restrictive than using Same Origin Policy.
As you can see with cookie scope,
it only checks the domain and path, but with origin,
you see that it's actually
constrained by domain as well as
the port as well as the protocol of the document.
We're going to look at what's Same Origin Policy is next.
Remember how we were talking
earlier about what origin is.
An Origin is a set of three pieces of information;
the protocol, the domain,
and the port of the document.
We want to say that if
those three pieces of information are the same,
then JavaScript in one document that has
the origin can access.
Say for example cookies for that particular document.
However, if the origin does not match,
then that particular script belonging in one origin,
cannot access a different document
that has a really different origin.
Basically, communication is
restricted between one resource.
So, a document or a script served from one origin,
and another resource served from
a different origin, origin B.
So here for example,
is a conceptual drawing of
what a browser or user agent looks at.
Here, we have a representation of a resource.
A document here we'll call document A,
its origin is HTTP and www.example.com and port 80.
Port 80, is implied here.
Here the script that is being run
is, cookies equals document.cookie.
It wants to access cookies,
all of the cookies,
but it's only restricted to
this document A, let's call it.
It cannot access document B which is from
the origin HTTP, www.google.com, port 80.
Even though the script is run,
it's only allowed to access its own document.
I want to make a note that
it's true that one document from
one domain can access
cookie from another unrelated domain,
effectively following the same origin policy.
However, the same origin policy
is not what's used to enforce cookie access,
it's cookie scope that enforces this.