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.