8. Web Security Model

June 13, 2019 posted by



The following content is
provided under a Creative Commons license. Your support will help
MIT OpenCourseWare continue to offer high quality
educational resources for free. To make a donation or to
view additional materials from hundreds of MIT courses,
visit MIT OpenCourseWare at ocw.mit.edu. PROFESSOR: All right, guys. Let's get started with
the next installment of our exciting journey
into computer security. Today, we're actually going
to talk about web security. Web security is, actually,
one of my favorite topics to talk about because
it really exposes you to the true horrors
of the world. It's very easy to
think, as a student, that everything will be
great when you graduate. Today's lecture and
the next lecture will be telling you that's,
in fact, not the case. Everything's terrible. So what Is the web? Well back in the olden days, the
web was, actually, much simpler than it is today, right. So clients, which is
to say the browsers, couldn't really do anything
with respect of displaying rigid or active content. Basically they could just get
static images, static text, and that was about it. Now the server side was
a little more interesting because even if there was static
content on a clients side. Maybe the server was
talking databases, maybe it was talking to other
machines on the server side. Things like that. So for a very long time,
the notion of web security, basically, meant looking at
what the server was doing. And to this point
in this class, we've essentially taken that approach. So we looked at things like
buffer to overflow attacks. So how clients can trick
the server into doing things the server doesn't want to do. You also looked
at the OKWS server and looked at how we can do
some privilege isolation there. So to this point, we, sort
of, looked at security through the experiences
that were actually experienced by the security
resources themselves. But now, actually, the
browser is very interesting to think about, in
terms of security, because the browser is super,
super complicated these days. So now there's all kinds
of insane, dynamic stuff that the browser
can actually do. So for example, you probably
heard of JavaScript. So JavaScript now
allows pages to execute client side code,
Turing complete, can do all kinds of wacky stuff. There is the DOM
model, which we'll talk about in more
depth later today. The DOM model, essentially,
allows JavaScript code to dynamically change the
visual appearance of the page. Fiddle with things like font
stylings and stuff like that. There's XML HTTP request. These are, basically,
a way for JavaScript to asynchronously fetch
contents from servers. You may also hear XML HTTP
requests referred to as AJAX. Asynchronous
JavaScript fetching. There are things
like web sockets. This is, actually,
recently introduced API. So WebSockets, essentially,
allow a full duplex communication between
clients and servers. Communication going both ways. We've got all kinds
of multimedia support. So for example, we have
things like the video tag, which allows a web
page to play video without using a Flash app. It can actually just
play that video natively. There's also a geolocation. So now a web page can actually
determine, physically, where you are. For example, if you're running
a web page on a smartphone, the browser can actually
access your GPS unit. If you're accessing a
page on a desktop browser, it can actually look at
your Wi-Fi connection and connect to Google's
Wi-Fi geolocation service to figure out where
exactly you are. That's, kind of, insane. Right? But now web pages can do
do that kind of stuff. So we've also talked
about things like NaCl, for example, which allows
browsers to run native code. So there's many,
many other features that I haven't mentioned here. But suffice it to
say the browser is now incredibly complicated. So what does this mean from
the perspective of security? Well basically, it means
that we're screwed. Right? The thread surface for that
right there is enormous. And loosely speaking, when
you're thinking about security, you can think of a graph that,
sort of, looks like this. So you've got the
likelihood of correctness. And then, you've got the number
of features that you have. And so you know, this graph
starts up here at 100. Well of course, we
never even started 100, even with very simple
code because we can't even do bubble sort right. So essentially, that curve
looks something like this. And web browsers
are right over here. So as we'll discuss
today, There's all kinds of wacky security bugs
that are arising constantly. And as soon as the
old ones are fixed, new ones are rising
because people keep adding these new features. Oftentimes, without
thinking about what the security implications
of those features are. So if you think about what a
web application is these days, well it's this client thing
and it's a server thing. And a web application now spans
multiple programming languages, multiple machines, and
multiple hardware programs. You could be using
Firefox on Windows. Then it's going to go talk to
a machine in the cloud that's running Linux. It's running the Apache server. Maybe it's running an ARM chip
opposed to x86 or something like that, or the
other way around. So long story short, there's all
these problems of composition. There's all these software
layers and all these hardware layers that all can impact
security in some way. But it's also complicated. It's not quite clear how we can
make sense of the entire whole. So for example, one common
problem with the web is this problem of
a parsing context. So as an example,
suppose that you had something in a page
that looked like this. You declare a script tag. Inside that script tag,
you declare a variable. There's some string here. And let's say that this string
comes from an untrusted party. Either the user or another
machine or something like that. And then, you close
that script tag. So this stuff is trusted. This stuff is trusted. This stuff is not trusted. So can anybody
figure out why there might be some problems here if
we take this entrusted string and put it in there? AUDIENCE: You can have a closing
quote mark in [INAUDIBLE] and then have some [INAUDIBLE]. PROFESSOR: Right,
right, exactly. So the problem is there
are multiple context, that this untrusted code
could, sort of, break into. So for example, if the untrusted
code had a double quote here, now we've closed the definition
of this JavaScript string. So now we're added the
JavaScript string context and render the regular
JavaScript execution context. And then the attacker
gets a regular job zip code here and go to town. Alternatively, the
attacker could just put a closing script tag here. Right? And then, at that
point, the attacker can, sort of, get out of
the JavaScript context and then get into
the HTML context. Maybe to find some new HTML
nodes or something like that. So you see this problem
with composition all over the place in
the web because there are so many different
languages and run times for you to think about. HTML, CSS, JavaScript, maybe
MySQL on the server side, and so on and so forth. So this is just
a classic example of why you have to do something
called content standardization. So whenever you get
untrusted input from someone, you actually need to
analyze it very carefully to make sure that it's not being
used as a vector for an attack. So another reason why
web security so tricky is because the web
specifications are incredibly long, they're
incredibly tedious, they're incredibly boring, and
they're often inconsistent. So when I mean the
web specifications, I mean things like the
definition of JPEG, the definition of CSS,
the definition of HTML. These documents
are, like, the size of the EU constitution and
equally as easy to understand. So what ends up happening
is that the browser vendors see all these specs. And they essentially
say, OK, thanks for that. I'm going to do something
that somewhat resembles what these specs look like. Then they call it a day
and they laugh about it with their friends. OK, so what ends up happening
is that these specifications end up being like these vague,
aspirational documents that don't always accurately reflect
what real browsers are doing. And if you want to understand
the horror of this, you can go to this site
called quirksmode.org. I mean, don't go to this
site if you want to be happy. But you can go there. And it actually documents all of
these terrible inconsistencies that browsers have with
respect to what happens when the user hits a key press? There should just be one key
precedent that's generated. You are so wrong. So go to quirksmode.org
and check that out, and see what's going on. So anyway, in this
lecture, we're going to focus on the client
side of the web application. In particular,
we're going to look at how we can isolate
content from different web providers that has
to coexist, somehow, in the same machine
and the same browser. So at a high level, there's
this fundamental difference between the way
you traditionally think of a desktop
application and the way you think of a web application. Abstractly speaking, most of the
desktop applications that you use, you can think of it as
coming from a single principal. So word comes from Microsoft. And maybe TurboTax comes
from Mr. and Mrs. TurboTax, so on and so forth. But when you look at a
web application, something that looks to you, visually,
as a single application is actually composed of a
bunch of different content from a bunch of
different people. So you go to CNN, it looks
like it's all on one tab. But each of those visual
things that you see may, in fact, come
from someone different. So let's just look at a
very simple example here. So let's say that we were
looking at the following site. So HTTP food.com. And we're just
looking at index.html. So you know, you look
at your browser tab. What might you see? So one thing that you might
see is an advertisement. So you might see
an advertisement in the form of a gift. And maybe that was
downloaded from ads.com. Then you also might see, let's
say, an analytics library. And maybe this comes
from google.com. So these libraries are very
popular for doing things like tracking how many
people have loaded your page, looking to see where
people click on things to see which parts of their
site are the most interesting for people to interact
with, so on and so forth. And you might also have
another JavaScript library. Let's say it's jQuery. And maybe that comes
from cdn.foo.com. So some content distribution
network that foo.com runs. jQuery is very popular
library for doing things like GUI manipulation. Things like that. So a lot of popular
websites have jQuery. Although, they serve it
from different places. And then, on this page
you might see some HTML. And here's where
you might see stuff like buttons for the user to
click on, text input, and so on and so forth. So that's just raw
HTML on the page. And then, you might
see what they call inline JavaScript from foo.com. In my inline, you
have a script tag. And then, you have
a closed script tag. And then you just have
some JavaScript code included in their directly. That's as opposed to where
you say something like script. And then, the source
equals something that lives on some server remotely. So this is what's called
inline JavaScript. This is what's referred to
as an externally defined JavaScript file. So you might have some inline
JavaScript there from foo.com. And the other thing that
you might have in here is actually a frame. So we'll talk about frames
a bit more in a little bit, but think of a frame as almost
like a separate JavaScript universe. It's a little bit equivalent
to a process and UNIX. So maybe this frame here,
maybe this guy belongs to https://facebook
.com/likethis.html. So maybe here we have
some inline JavaScript from Facebook. And then, maybe, we
also have some image. So you know, f.jpeg. That comes from
https://facebook.com. OK, so this is what a single
tab might have in its contents. But as I just
mentioned, all this can, potentially, come from
all these different principles. So there's a bunch of
interesting questions that we can ask about
a application that looks like this So for example, can this
analytics code from google.com actually access
JavaScript state that resides in the jQuery code. So to first approximation,
maybe that seems like a bad idea because these two pieces of
code came from different places. But then again, maybe
it's actually OK because, presumably, foo.com
brought both of these libraries in so that they can
work with each other. So who knows. Another question
you might have is can the analytics
code here actually interact with the
text inputs here. So for example, can
the analytics code define event handlers? So a little bit of
background in JavaScript. JavaScript is single
threaded vent driven model. So basically, in
each frame, there's just an event loop that's just
constantly pulling events. Key presses, network events
timers, and stuff like that. And then, seeing if there
are any handlers associated with those events. And if so, it fires them. So who should be able to define
event handlers for this HTML. Should google.com
be able to do it. It's not from foo.com
so maybe, maybe not. Another question, too, is
what's the relationship between this Facebook frame
here and the larger frame? The Facebook frame
is an HTTPS, secure. foo.com is an HTTP, nonsecure. So how should these two
things be able to interact? So basically, to
answer these questions, browsers use a security model
called the same-origin policy. So there's, sort
of, this vague goal because a lot of things
with respect to web security are, kind of, vague
because nobody knows what they're doing. But the basic idea
is two websites should not be able to
tamper with each other, unless they want to. So defining what tampering
means was actually easier when the web was simpler. But as we keep adding
these new APIs, it's more and more
difficult to understand what this non-tampering goal means. So for example,
it's obviously bad if two websites, which
don't trust each other, can over write o each
other's visual display. That seems like an
obviously bad thing. It seems like an
obviously good thing if two websites, which
want to collaborate, are able to, somehow,
exchange data in a safe way. So you can think of mash up
sites you may have heard of. So sometimes you'll see
these things in the internet. It's like someone
takes Google map data, and then takes the
location of food trucks. And then, you have
this amazing mash up that allows you to eat cheaply
and avoid salmonella, right? So that seems like a thing
you should be able to do. But how, exactly, do we enable
that type of composition? Then there's other things that
are, kind of, hard to say. So for example, if JavaScript
code comes from origin x inside of a page
that's from origin y, how exactly should that code
and that content compose? So the strategy that the
same-origin policy user can be roughly described as follows. So each resource is
assigned an origin, which we'll discuss in a second. And essentially,
a JavaScript code can only access resources
from its own origin. So this is the
high level strategy the same origin policy uses. But the devil's in the details. And there's the ton of
exceptions, which we're going to look into in a second. But first of all,
before we proceed, let's define what an origin is. So an origin is, basically,
a network protocol scheme plus a host name plus a port. So for example, we can have
something like HTTP foo.com. And then, maybe,
it's index.html. So the scheme here is HTTP. And the host name is foo.com. And the port is 80. Now the port, in this
case, is implicit. The port is the port
on the server side that the client uses to connect. So if you see a URL
from the HTTP scheme and there's no port that's
explicitly supplied, then, implicitly, that port is 80. So then, if we look at
something like the HTTPS, once again, foo.com index.html. So these two URLs have
the same host name. Right? But they have, actually,
different schemes. HTTPS vs HTTP. And also, here, the
port is implicitly 443. That's the default HTTPS port. So these two URLs have
different origins. And then, as a final
example, if you had a site like HTTP
bar.com, then you can use this colon
notation here. 8181. You know, these
things beyond here don't matter with respect to
the same origin policy, at least with respect to this
very simple example. Here, we see that we have
a scheme of HTTP, a host name of bar.com, and here we've
explicitly specified the port. So in this case, it's a
non-default port of 8181. So does that make sense? It's pretty straightforward. OK, so this is, basically,
what an origin is. Loosely speaking, you can think
of an origin as a UID in Unix with the frame being loosely
considered as, like, a process. So there are four basic
ideas behind the browser's implementation of the
same origin policy. So first idea is each origin
has client side resources. So what are examples
of those resources? Things like cookies. Now you can think of
cookies as a very simple way to implement state in a
stateless protocol like HTTP. Basically, a cookie is
like a tiny file that's associated with each origin. And we'll talk about the
specifics of this in a bit. But the basic idea is that when
the browser sends a request to a particular website,
it includes any cookies that the client has
for that website. And you can use these
cookies for things like implementing
password remembering. Maybe if you were going
to an ecommerce site, you can remember stuff
about a user's shopping cart in these cookies,
so on and so forth. So cookies are one
thing that each origin can be associated with. Also, you can think
of DOM storage as another one of
these resources. This is a fairly new interface. But think of DOM storage
as just a key value store. So DOM storage allows
an origin to say, for this given key,
which is a string, let me associate
it with this given value, which is also a string. Another thing that is
social with an origin is a JavaScript name space. So that JavaScript
name space defines what functions and
what interfaces are available to the origin. Some of those
interfaces are built in. Like, let's say, the string
prototype and stuff like that. And then, an application
might actually fill the JavaScript namespace
with some other content. There's also this thing
called the DOM tree. So DOM is short for
Document Object Model. And the Dom tree
is, essentially, a JavaScript reflection
of the HTML in a page. So you can imagine
that the DOM tree has a node for the topmost
HTML5 node in the HTML. And then, it's going to have
a node for the head tag. Then, it's going to have
a node for the body tag. All right, so on and so forth. So the way that a lot
of dynamic web pages are made dynamic is
the JavaScript code can access this data
structure in JavaScript that mirrors the HTML content. So you can imagine an
animation takes place by changing some
of these nodes down here to implement different
organizations of various tabs. So that's what the DOM tree is. There's also a
visual display area. Although, we'll see that
the visual display area actually interacts very
strangely with the same origin policy. So on and so forth. So at high level,
each origin has access to some set of client side
resources of these types. Doe that make sense? And then, the second big
idea is that each frame gets the origin of its URL. So as I mentioned
before, a frame is, roughly, analogous
to a process in Unix. It's, kind of, like
a name space that aggregates a bunch of
other different resources. So third idea is that
scripts, so JavaScript code, execute with the authority
of it's frame's origin. OK, so what that means is that
foo.com imports a JavaScript file from bar.com. Well, that JavaScript
file is going to be able to act with
the authority of foo.com. So loosely speaking, this
is, sort of, similar to if you were in the
Unix world to run a binary that, sort of,
belonged in someone else's home directory. That thing would sort of,
execute, with your privileged there. And the fourth thing is
there's passive content. So by passive content I mean
things like that images, for example. Or CSS file or things like that. These are things,
which we don't think of as having executable code. So passive content gets zero
authority from the browser. So that, kind of, makes sense. We'll see why this fourth
thing is a little bit subtle in a second. So going back to
our example here. So we see, for example,
that the Google Analytics script and the jQuery script
can access all kinds of stuff in foo.com. So for example, they can
read and write cookies. They can do things like attach
event handlers to buttons here. So on and so forth. If we look at the Facebook
frame and its relationship to the larger foo.com
frame, then we see that they're from
different origins because they have
different schemes here. They have different host names. Different ports. So what this means is that they
are, to a first approximation, isolated. Now they can communicate
if they both opt into it using this interface
called postMessage. So postMessage allows
two different frames to exchange asynchronous
immutable messages with each other. So think of this facility
as allowing Facebook to try to send a string. Not a reference, a string up
to the enclosing foo.com frame. Now note that if foo.com doesn't
want to receive those messages, it doesn't have to. So this has to be opt
in from both sides to get this thing to work. So note that the JavaScript
code here in the Facebook frame cannot issue an XML HTTP
request to the foo.com server. That's once again because
network destinations also have these origins that
are associated with them. So because Facebook.com does not
have the same origin as foo.com it can't asynchronously fetch
stuff from it via HTML request. So the last thing
we can look at we can say, OK, we got an
image up here from ads.com. This is rule number
four over there. So it seems pretty
straightforward. This is an image. It has no executable code. So clearly, the browser's
going to give it no authority. Now that seems kind
of like a dumb thing. Like, why are you even
talking about images having authority or
not having authority? It seems obvious that images
shouldn't be able to do stuff. Well it's a security class. So clearly, there is mischief
that hides in statement number four up there. So what happens if the browser
incorrectly parses an object and misattributes it's type? So you can actually get into
security problems there. And this was actually a
real security problem. So there's this thing called
the MIME sniffing attack. So the MIME type–
I mean, you've probably seen these before. You knows it's Something
like text dot HTML or image.JPEG Things like that. This was like a MIME type. So old versions of i.e used to
do something that they thought was going to be helpful for you. So sometimes what
web servers will do is they will misattribute the
file extension of an object. So you can imagine that
a web server that's been configured incorrectly
might attach a dot HTML suffix to something
that's really an image. Or it might attach
a dot JPEG suffix to something that's really HTML. So what IE would do
back in the olden days is try to help you out. So IE would go out. It would go fetch this resource. And it would say,
OK, this resource claims to be of some type,
according to its file name extension. But then it would actually
look at the first 256 bytes of what was in that object. And if it found certain
magic values in there that indicated that there
was a different type for that object, it would just say, hey,
I found something cool here. The web server
misidentified the object. Let me just treat the
object like it's type that I found in these
first 256 bytes. And then, everybody's
a winner because I've helped the web
server developer out because now their website's
going to render properly. And the user's
going to like this because they get to
unlock this content that would have been garbage before. But this is clearly
a vulnerability because suppose that a page
includes some passive content. Like, let's say, an image
from a domain that's controlled by the attacker. Now from the perspective of
the victim page, it's saying, even if this attacker site is
evil, it's passive content. It can't do anything. Like, at worst, it displays
an unfortunate image. But it can't actually
access any code because passive content
gives 0 authority. But what would happen is that
IE could sniff this image. The first 256 bytes. And the attacker
could intentionally put HTML and
JavaScript in there. So what would happen is
that the victim site brings in what it thinks is an image. IE coerces it into
HTML and JavaScript. And then, executes that
code in the context of that enclosing page. So does that attack make sense? so This is, sort of, an example
of how complex browsers are and how adding even a very
well intentioned feature can cause these very
subtle security bugs. So let's now dig down
and take a deeper look at how the browser
secures various resources. So let's look at frames
and window objects. So frames represent these
separate JavaScript universes that we discussed over here. I mean, implementation
wise, a frame with respect to JavaScript
is an instance of a DOM node. So I forget where
I drew– oh, yeah. This DOM node up here. So the frame would
exist as a DOM node object somewhere in
this hierarchy that's visible to JavaScript. In JavaScript, the window
object is actually an alias for the global name space. It's, kind of, this wacky idea. Like, if you were to find
this global variable name x, you can also access it
via the name window.x. OK, so basically, frames
and window objects are very powerful references
for you to be able to access. And they actually contain
pointers to each other. The frame can
[INAUDIBLE] a pointer to the associated window
object and vice versa. So these two things
are, essentially, equivalently powerful. So frame and window objects get
the origin of the framed URL. Or because there's always
an or in web security, they can get a suffix of
the original domain name. The original origin. So for example, a
frame could start off having an initial origin. x dot y dot z dot com. So let's ignore the scheme
and the protocol for a second. So initially, the page
can start off like this. It can then intentionally
say I want to set my origin to be y dot z dot com. A suffix of that. And the way that
it indicates this is by doing an assignment
to the special document dot domain value that's
accessible via JavaScript. So we can set document dot
domain explicitly to this right here. And that's allowable
because this guy is a suffix of that guy. And then, similarly,
it could also set document dot domain to
z.com and effectively reset it's origin like that. Now what it cannot do is
it cannot do something like setting document domain
to a dot y dot z dot com. That's disallowed
because this is not a problem this is not a proper
suffix of the original origin. And also, it cannot set
its suffix to dot com. So does anyone have any theories
about why this is a bad idea? Right, exactly. So people are laughing
because, clearly, this is going to bring out
the apocalypse, right. So if it does this,
then this means that the site could somehow
be able to impact cookies or things like that in
any dot com site, which will be pretty devastating. The motivation for why these
types of things are allowable is because, presumably,
these origins have some type of preexisting
trust relationship. So this seems to be vaguely OK. Whereas, this would
seem to be bad. AUDIENCE: So you can
make these splits on any dot or actual end point? Like, for example,
for your x.y.zz.com, can you change
that to your z.com? PROFESSOR: No, it
says on every dot. AUDIENCE: OK. Is there a reason
that it wasn't made so that you could specify
super- or subdomain, but somehow they had to agree
on where the information was coming from. So, like, you said some kind of
I want to consider all of these to be the same origin as me. So any of them can attack me. And then you made this
symmetric in order for me to impact them as well? [INAUDIBLE] .com means anything
that's .com can impact me. And then you put [INAUDIBLE]. PROFESSOR: Yeah, it's tricky. So there's a couple of
different answers to that. So first of all, people were
very worried about this attack here. So they wanted to make
the domain manipulation language be, at least,
somewhat easy to understand. So they don't allow
more broke settings. I'll get to one thing in a
second, which kind of allows what you're talking about but
only with respect to domain [INAUDIBLE]. I'll get to that in one second. And another to mention, too, is
that the post message interface does allow arbitrary domains
to communicate with each other if they both opt into it. So in practice, people
use post message to cross domain
communication if they can't set their origins
to be the same using these tricks here. So yeah, so browsers
can constrain or widen, I should say, their
domain to these suffixes of the original domain. And there's also this little
interesting quark here, which is that browsers actually
distinguish between a document dot domain value
that has been written and one that has not
been written, OK. And there's a subtle
reason for this we'll get into in a second. So basically, two frames
can access each other if one of two things is true. The first thing is both of
the frames set document dot domain to the same value. And the other way that two
frames can access each other is that neither of those frames
has changed document domain. And of course, both
values have to match. And there's a value match. So the reason for
this is a bit subtle. But the basic idea is that
these two rules prevent a domain from being attacked by
one of its own buggy or malicious sub-domains. OK? So imagine that you have
the domain x.y.z.com. And then, imagine that it's
trying to attack y.z.com. So this guy up here
is buggy or evil. So what this guy could try to do
is actually shorten his domain to be y.z.com. And then, start messing
around with JavaScript state, or cookies or stuff
like that here. Right? So basically, what these
two rules over here will say is that if y.z.com does not
want to actually allow anyone to interact with
it, it will never change it's
document.domain value so that when this frame
up here does shorten it, the browser will say aha. You've shortened it. You have not. There's a match here
in terms of the values. But this person
hasn't indicated they want to opt into this
type of chicanery. So does that makes sense? OK, so that is, basically,
how frames work with respect to the same origin policy. So then we can look at how
our DOM node's treated. So DOM nodes, it's pretty
straightforward for DOM nodes. So DOM nodes, basically,
get the origin of their surrounding frame. Makes sense. Then we can look at cookies. Cookies are complicated
and a bit tricky. So cookies have a domain. And they have a path. So for example, you can imagine
a cookie might be associated with the following information. So asterisks dot MIT.edu. And then, 6.858. So you've got this domain
thing sitting here, and then, you've got this
path thing sitting over here. So note that this domain
can be, possibly, complete suffix of the pages
current domain. So you can play,
somewhat, similar tricks as we had over there. And note that this path
here can actually just be set just to the slash with
nothing else there, which indicates that all
paths in the domain should be able to have
access to this cookie here. But in this case,
we actually have one of these nonempty paths. So whoever sets this
cookie, basically, gets to choose what the
domain in the path look like. And it can actually
be set by the server or can be set on
the client side. So on the client side,
you can basically right to this JavaScript
object called document.cooking. And there's, sort of,
this Byzantine format that you can use to
indicate all these paths and things like that. But suffice to say
it can be done. So JavaScript can set
cookies like this. And also, the
server can actually set cookies on HP responses when
they come back over the wire. So you can, basically, just
use the set cookie header, if you're the server, to
set some of these things. And know that there's
also a secure flag that you can set in the cookie
to indicate that it's an HTTPS cookie, meaning that
HTTP content should not be able to access that cookie. So that's the basic
idea behind cookies. Now note that whenever the
browser generates a request to a particular web
server, it's going to include all of the matching
cookies in that request. So there's a little
bit of, sort of, string matching
and algorithms that have to take place to
figure out what are all the exact cookies
that should be sent to the service for
a particular request because you can have
all these weird, sort of, suffix
domain things going on and so on and so forth. But that's the basic
idea behind cookies. So does that all make sense? AUDIENCE: So can frames
access each other cookies if they match those rules? PROFESSOR: Yeah, so
frames can do that. But it's dependent on how the
document.domain has been set. And then, it's dependent
on what the cookie domain and path have been set. So yeah, after a bunch of
these strained comparisons, yes, frames can access
each others cookies if all those tests pass. OK, so yes, that leads me
into the next question. So we're trying to figure
out how different frames can access each others cookies. So what's the problem? What would be the problem is
we allowed arbitrary frames to write arbitrary
people's cookies? So what do you think? Well, it will be bad,
suffice it to say. The reason it would be bad
is because, once again, these cookies allow the
client side of the application to store a per user data. So you can imagine that if
an attacker could control or override a users cookie,
the attacker could actually, for example, change
that cookie for a Gmail to make the user log into
the attackers Gmail account. So when the user logged
into the attacker Gmail account, any email
that the user typed in could be read by the
attacker, for example. You could also imagine
that someone could tamper with the Amazon.com cookie. You know, put all kinds of
embarrassing ridiculous stuff in your shopping cart,
perhaps, or so and so forth. So cookies are, actually, a very
important resource to protect. And a lot of web
security attacks try to steal that cookie to
do various kinds of evil. So here's another
interesting question with respect to cookies. So let's say that you've
got the site that's coming from foo.co.uk. So should the site
from this host name be allowed to set
a cookie for co.uk? So this is a bit subtle
because, according to the rules that
we've discussed before, a site from here should
be able to shorten its domain, set a cookie for this, and
that all seems to be legal. Now of course, as
a human, we think this is kind of suspicious
because, as a human, we actually understand that
this is morally speaking a single atomic domain. Morally speaking, this
is equivalent to .com. The British got screwed. They have to have
a dot in there. But that's not their
fault. History's unfair. Right? So morally speaking,
this is a single domain. So you actually have to have
some special infrastructure to get the cookie setting
rules to work out correctly. So essentially, Mozilla,
they have this website called publicsuffix.org. And basically, what
this website contains are lists of these rules for
how cookies, and origins, and domains should be shrunk
given that some things might have dots in them. But actually, they should be
treated as a single, sort of, atomic thing. So actually, when your
browser is figuring out how it should do all these
various cookie manipulations, it's actually going
to consult this side. Or it's going to have
this baked in somehow or something like
that to make sure that foo.co.uk can't actually
just shorten its domain to co.uk. And then, perform
some chicanery. So once again, this
is very subtle. And a lot of the
interesting web security issues that we find
come about because a lot of the original infrastructure
was designed just for the English language. You know, for ASCII text
or something like this. It wasn't designed for an
international community. So as the internet became more
popular, people said, hey, we made some pretty big
design decisions here at the beginning. We should actually
make this usable on people who use our narrow
understanding of what language means. You run into all
these crazy problems. And I'll give you
another example one of those a later lecture. So does this all makes sense? OK. So with respect to
XML HTTP responses, how are they treated by
the same origin policy? So by default, JavaScript can
only generate one of these if it's going to
its origin server. However, there's this
new interface called cross origin request or CORS. All right, so this
is the same origin unless the server has
enabled this CORS thing. So basically, this adds a new
HTTP response header called access control allow origin. So let's say that
JavaScript from foo.com wants to make an XML
HTTP request to bar.com. So that's cross origin, as we
described in the rules so far. So if the server in bar.com
wants to allow this, it will return in it's HTTP
response this header here that's going to say, yes, I
allow, for example, foo.com to send me these cross
origin XML HTTP request. The server on bar.com
could actually say no. It could refuse the request. In which case, the browser
would fail the XML HTTP request. So this is, sort of,
a new thing that's come up in large part because
of these mash up applications. This need for,
somehow, applications from different developers
and different domains to be able to share data in
some type of constrained way. So this could also be
asterisks over here if anybody can fetch
the data cross-origin, so on and so forth. So I think that's
pretty straightforward. So I mean, there's a
bunch of other resources we could look at. For example, images. So a frame can load images from
any origin that it desires. But it can't actually inspect
the bits in that image because, somehow, the
same origin policy says that having
different origin directly inspect each others
content is a bad thing. So the frame can't
inspect the bits. But it can, actually,
infer things like what the size of the image
is because it can actually see where the other
dominoes in that page have been placed, for example. So this is another one of
these weird instances where the same origin
policy is ostensibly trying to prevent all
information leakage. But it can't actually
prevent all of it because embedding
inherently reveals some types of information. CSS has a similar
story to images. So a frame can embed
CSS from any origin. However, it cannot directly
inspect the text inside that CSS file, if it's from
a different origin. But it can actually imply what
this CSS does because it just can create a bunch of nodes. And then, see how they're
styling gets changed. So it's a bit wacky. JavaScript is actually
my favorite example of how this same
origin policy struggles to maintain any type of
intellectual consistency. So the idea here is that, if
you do a cross origin fetch of JavaScript, that is allowed. You can allow that
external JavaScript to execute in the
context of your own page. You cannot, however, look
at the source code for it. So if you have a
script tag source equals something
outside your domain, then when that
source gets executed, you can call functions in it. But you can't actually look
at the JavaScript source code in it. OK, fine. So that seems very nice. However, there are a
bunch of holes in this. So for example, JavaScript is
dynamic scripting language. And functions are
first class objects. So for any function f, you
can just call f.tostring. And that will give you the
source code for the function. And people do this all the time. Do things like dynamic
rewriting and stuff like that. So you know the
same origin policy doesn't allow you
to directly look at the contents of
the script tag itself? You can just call this
for any public function that that external
script has given you. And just get the
source code like that. Another thing you
could imagine doing is you could just get your
home server from your domain to just fetch the
source code for you. And then, just send
it back to you. So oops. I mean, you essentially
just asked your home server to run Wget. And you get the
source code that way. OK, so that's, kind
of think, goofy. So long story short,
the same origin policies here are a bit odd. AUDIENCE: Presume that
par of the reason they do it is to prevent the user
from fetching JavaScript because then cookies
will be sent as well. So you can get JavaScript
tailored to you. PROFESSOR: Yeah. AUDIENCE: So if you get your
server to fetch it for you, it won't have the user's
cookies [INAUDIBLE]. PROFESSOR: That is true. Although, in practice,
a lot of times, the raw source code, itself, is
not user tailored in practice. But you're right
that it will prevent some cookie-mediated
attacks like that. Modulo, some of the
cookie [INAUDIBLE]. But that's exactly correct. So because it's actually pretty
easy for users and applications to get JavaScript source
code, a lot of times, JavaScript source code,
when it's deployed, it's actually
obfuscated and minified. So if you've ever tried to look
and see how a web page works, if you look at the
source, sometimes people will do things like move
all the white space. They will also change
all the variable names to be super short and have
all these exclamation marks. Looks like cartoon characters
cursing in the cartoons. So that's, sort of,
like a cheat form of digital rights management. But it's all, ultimately,
a bit of a crap shoot because you can do
things like execute that code in your own browser. See what it does. Sniff the network. See who it talks to,
so on and so forth. But that's, basically, the same
origin story for JavaScript. Plug-ins– AUDIENCE: I was
under the impression that the reason you
do that is [INAUDIBLE] take less time to download
rather than [INAUDIBLE]. PROFESSOR: So that is also
a reason they do that, too. That's a good point. But I mean, if you type
into the internet, sort of, web page obfuscation
or stuff like that, people often try to, somehow,
make some type of secrets into either their HTML
or their JavaScript. Maybe they want to
obscure the protocol. For example, if the client
uses it to talk to the server. Some people will also do the
obfuscation for that reason. Pure minification–
in other words, just making the
variable names small and moving the
[INAUDIBLE] space– yeah, that's mainly just to save
download band, download time. OK, so that's the
story for JavaScript. There's also plug-ins. So this is stuff like
Java and things like this. So a frame can easily run a
plug-in from either origin. Now plug-ins, depending
on who you believe, are actually going to
the way of the dinosaurs. Because a lot of the
new HTML 5 features, like video tag and
things like this, can actually do
stuff that you used to only be able to do
with a plug-in like Java. So it's not clear how
much longer these things are going to be around. OK, so any questions. OK, so remember that when
a browser generates an HTTP request it automatically
includes the relevant cookies in that request. So what happens if a
malicious site generates a URL that looks like this? So for example, it
creates a new child frame. It says that URL to bank.com. And then, it actually tries to
mimic what the browser would do if there was going to
be a transfer of money between the user
and someone else. So in this URL, in this
frame that the attack is trying to create, it tries
to invoke this transfer command here. Say $500. And that should go to the
attacker's account at the bank. Now the attacker
page, which the user visited because, somehow,
the attacker is [INAUDIBLE] go there. What's interesting
about this is that, even though the
attacker page won't be able to see the contents
of this child frame because it's probably going
to be in a different origin. The bank.com page will still
do what the attacker wants because the browser's going
to transfer all the users cookies with this request. It's going to look
at this command here and say, oh, the user
must've, somehow, asked me to transfer $500
to this mysteriously named individual named attacker. OK, I'll do. All right, seems reasonable. So that's a problem. Then the reason
this attack works is because, essentially,
the attacker can figure out
deterministically what this command should look like. There's no randomness
in this command here. So essentially,
what the attacker can do is try this on his
or her own bank account, figure out this
protocol, and then just, somehow, force the
user browser to execute this on the attackers behalf. So this is what's called a
cross site request forgery. So sometimes you hear
this is called CSRF. C-S-R-F. So the solution to
fixing this attack here is that you actually just need
to include some randomness in this URL that's generated. A type of randomness
that the attacker can't guess statically. So for example, you can imagine
that inside the bank's web page it's going to have some form. The form is the
thing, which actually generates request like this. So maybe the action of
that form is transfer.cgi. And then, inside this form,
you're going to have an input. Inputs are usually used to
get in user input like text, key presses, mouse clicks,
and stuff like that. But we can actually
give this input a type of hidden, which
means that it's not shown to the user. And then, we can give
it this attribute. We'll call it CSRF. And then, we'll give
it some random value. You know, a72f. Whatever. So remember, this is
generated on the server side. So when the user goes to this
page, on the server side, it sometimes generates
this random here and embeds that in the HTML
that the user receives. So when the user
submits this form, then this URL that we
have up here will actually have this extra thing up here,
which is this token here. So what this does
is that this now means that the
attacker would have to be able to guess the
particular range of token that the server generated
for the user each time the user had gone to the page. So if you sufficient
randomness here, the attacker can't just
forge one of these things because if the attacker
guesses the wrong token, then the server orders
will reject your request. AUDIENCE: Well why
should these always be included in the URL and not
in the body of the [INAUDIBLE]? PROFESSOR: Yeah, yea. So HTTPS helps a
lot of these things. And there's actually
no intrinsic reason why you couldn't put
some of this stuff in the body of the request. There's some legacy reasons why
forms, sort of, work like this. But you're correct. And in practice, you can put
that information somewhere else in the HTTPS request. But note that just moving
that information, for example, to the body of the
request, there's still a challenge there,
potentially because if there's something there that
the attacker can guess. Then the attacker may
still be able to, somehow, conjure up that URL. For example, when I'm making
XML HTTP request and then, explicitly, setting
the body to this thing that the attacker
knows how to guess. AUDIENCE: Well if the
attacker just gives you a URL, then that just gets encoded
in the header of [INAUDIBLE]. PROFESSOR: If the attacker
just gives you a URL. So if you're just
setting a frame to URL, then, that's all that
the attacker can control. But if you're using
an XML HTTP request if, if somehow the attacker
can generate one of those, then XML HTTP interface actually
allows you to set the body. AUDIENCE: The XML
HTTP request would be limited by, say, an origin. But the attacker could just
write a form and submit it. There's nothing [INAUDIBLE]
submitting a form like using [INAUDIBLE]. And then, it's sent in the body. But it's still– PROFESSOR: That's right. So XML HTTP request is
limited to the same origin. However, if for example,
the attacker can, maybe, do something
like this, for example. And the attacker can inject
the XML HTTP request here, which would then execute
with the authority of the embedded page. AUDIENCE: Can the
attacker [INAUDIBLE] by inspecting the
HTML source code? PROFESSOR: Yes, that's actually
a good question. right so it depends on what the
attacker has access to. If the attacker– for example,
by doing something goofy like that– can actually
access this JavaScript property called inner HTML. This is a property
[INAUDIBLE], right. So if I document that
body dot inner HTML, I will get all of the HTML
that's inside that page right now. So yeah. So if the attacker can
do this, then yeah. Then you're in trouble. That's right. So a lot of these
details, though, depend on exactly what the
attacker can and can't do. So it, kind of, makes sense. So if the attacker can or
cannot generate Ajax request, that means one thing. The attacker can or cannot
look at the right HTML, then you have another thing. So on and so forth. All right. So yeah. So this is token based
thing is a popular way to get around
these CSRF attacks. All right, so another
thing we can look at are network addresses. So this gets into some of the
conversation we've been having about who the attacker cannot
contact via XML HTTP request, for example. So with respect to
network addresses, a frame can send HTTP
and HTTPS requests to a host plus a port
that matches it's origin. But note that the security
of the same origin policy is, actually, very tightly tied
with the security of the DNS infrastructure because
all the same origin policies' rules are
based upon what names me. So if you can control
what names me, you can actually want some
pretty vicious attacks. So an example of this is
the DNS rebinding attack. So in this attack, the
goal of the attacker is run attacker controlled
JavaScript with the authority of some victim website. We'll just call them victim.com. So the attacker wants to
bus the same origin policies and somehow run code
that he has written with the authority
of some other site. So here's the approach. So the first thing that
the attacker is going to do is register a domain name. So let's say we just
call that attacker.com. Very simple to do. Just pay a couple of bucks. You're ready to go. You own your own domain name. So note that the
attacker is also going to set up a
DNS server to respond to name resolution
requests for objects that reside in attacker.com. So the second thing
that has to happen is that the user has
to visit attacker.com. In particular, the user has
to visit some website that hangs off of this domain name. This part is
actually not tricky. See if you can create
an ad campaign. Free iPad. Everybody wants
a free iPad, even though I don't know anyone
who's ever won a free iPad. The click on this. They're there. It's in the phishing
email, so and so forth. This part's not hard. So what's going to happen? So this is actually going
to cause the browser to generate a DNS
request to attacker.com because this page
has some objects that refer to some objects
that live in attacker.com. The browser's going to say I
never seen this domain before. Let me send the DNS resolution
request to attacker.com. So what's going to
end up happening is that the attackers
DNS server is going to respond to that request. But it's going to respond
with a DNS result that has a very short time to live. OK? Meaning that the
browser will think that it's only valid for a
very short period of time before it has to go out
and revalidate that. OK? So in other words, the attacker
response has a small DTL. OK, fine. So the user gets
the response back. The malicious website is now
running on the user side. Meanwhile, while the user's
interacting with the sight, the attacker is going
to configure the DNS server that he controls. The attacker is going to
bind the attacker.com name to victim.com's IP address. Right? So what that means is that
now if the user's browser ask for a domain name resolution
for something that resides in attacker.com,
it's actually going to get some internal
address to victim.com. This is actually very subtle. Now why can the attacker's
DNS resolver do that? Because the attacker
configures it to do so. The attacker's DNS
server does not have to consult victim.com
to do this rebinding. So perhaps, you can see some of
the outline in the attack now. So what will happen
is that the website wants to fetch a new object
via, let's say, AJAX. And it thinks that
that AJAX request is going to go to attacker.com
somewhere externally. But this AJAX request
actually goes to victim.com. And the reason why that's
bad is because now we've got this code on
appliance side that resides on the attacker.com web
page that's actually accessing now data that is from
a different origin from victim.com. So once this step of
the attack completes, then the attacker.com web page
can send that contact back to the server using [INAUDIBLE]
or do other things like that. So does this attack make sense? AUDIENCE: Wouldn't it be more
sensible to do the attack the other way around? So to [INAUDIBLE] victim.com
to the attackers IP address. Because that way you're the
same origin as victim.com so you can get all
the cookies and such. PROFESSOR: Yeah, so that
would work, too, as well. So what's nice about
this though is that, presumably, this allows you o do
nice things like port scanning and stuff like that. I mean, your approach
will work, right. But I think here the
reason why you do– AUDIENCE: [INAUDIBLE]. PROFESSOR: Because,
essentially, you can do things like constantly
rebind what attacker.com points to to different machine names
and different ports inside of victim.com's network. So then, you can,
sort of, step through. So in other words, let's say
that the attacker.com web page always thinks it's
going to attacker.com and issuing an
AJAX request there. So every time the
DNS server rebinds, it [INAUDIBLE] to some
different IP address inside of victim.com's network. So it can just, sort of, step
through the IP addresses one by one and see if anybody's
responding to those requests. AUDIENCE: But the client,
the user you're attacking, doesn't necessarily have inside
access to victim.com's network. PROFESSOR: So what this
attack, typically, ensues is that there are certain
firewall rules that would prevent attacker.com
from outside the network from actually looking through
each one of the IP addresses inside of victim.com. However, if you're inside
corp.net– if you're inside the corporate
firewall, let's say– then machines often do have the
ability to contact [INAUDIBLE]. AUDIENCE: [INAUDIBLE]. PROFESSOR: Yeah, yeah. Exactly. AUDIENCE: Does this
work over HTTPS? PROFESSOR: Ah, so that's
an interesting question. So HTTPS has these keys. So the way you'd have to
get this to work with HTTPS is if somehow, for example,
if attacker.com could– let me think about this. Yeah, it's interesting
because, presumably, if you were using HTTPS, then
when you sent out this Ajax request, the victim
machine wouldn't have the attackers HTTPS keys. So the cryptography
would fail somehow. So I think HTTPS
would stop that. AUDIENCE: Or if the the victim
only has things on HTTPS? PROFESSOR: Yeah. So I think that would stop it. AUDIENCE: If you
configure the [INAUDIBLE] use the initial or receiving
result [INAUDIBLE]? PROFESSOR: That's
a good question. I'm actually not
sure about that. So actually, a lot
of these attacks were dependant on the devil
in the details, right? So I'm not actually
sure how that wold work. AUDIENCE: It uses
the first domain. PROFESSOR: It would
use the first domain? OK. Yep? AUDIENCE: So why
can the attacker respond with the victims IP
address in the first place? PROFESSOR: So why
can't– what do you mean? AUDIENCE: [INAUDIBLE]. Why has the attacker
team [INAUDIBLE] has to respond with the
attacker's IP [INAUDIBLE]? PROFESSOR: Oh, well, yeah. Since the attacker
has to, somehow, get it's own code on
the victim machine first before it can then start
doing this nonsense where it's looking inside the network. So it's that initial
step where it has to put that code
on the victims machine. All right, so in the
interest of time, let's keep moving forward. But come see me
after class if you want to follow up the question. So that's the DNS
rebinding attack. So how can you fix this? So one way you
could fix it is so that you modify your
client-side DNS resolver so that external
host names can never resolve to internal IP address. It's, kind of, goofy that
someone outside of your network should be able to create a
DNS binding for something inside of your network. That's the most
straightforward solution. You could also imagine that
the browser could do something called DNS pinning. Whereby, if it receives
a DNS resolution record, then it will always treat
that record as valid for, let's say, 30 minutes,
regardless of whether it has a short TTL set inside
it because that also prevents the attack, as well. That solution is a little
bit tricky because there are some sites that actually,
intentionally, use dynamic DNS and do things like load
balancing and stuff like that. So the first solution is
probably the better one. OK, so here is, sort
of, a fun attack. So we've talked about
a lot of resources that the origin protects–
the the same origin policy protects. So what about pixels? So how does the same origin
policy protect pixels? Well as it turns out, pixels
don't really have an origin. So each frame gets its
own little bounding box. Just a square, basically. So a frame can draw wherever
it wants on that square. So this is, actually,
a problem because what this means is that
a parent frame can draw atop of it's child frame. So this can lead to some
very insidious attacks. So let's say that the
attacker creates some page. And let's say,
inside of that page, the attacker says
click to win the iPad. The very same standard thing. So this is the parent frame. Now what the parent frame
can do is actually create a child frame that is actually
the Facebook Like button frame. So Facebook allows you to run
this little piece of Facebook code you can put on your page. You know, if the user
clicks Like, then that means that it'll go on
Facebook and say, hey, the user likes the
particular page. So we've got this
child frame over here. That actually turned
out remarkably well. Anyway, so you've got
this Like thing over here. Now what the attacker can do
is actually overlay this frame on top of the click
to get the free iPad and also make this invisible. So CSS let's you do that. So what's going to happen? As we've already established,
everybody wants a free iPad. So the user's going
to go to this site, click on thing– this area
of the screen– thinking that they're going to click
here and get the free iPad. But in reality, they're
clicking the Like button that they can't see
that's invisible. It's like layered
atop the C index. So what that means is
that now maybe they go check their Facebook profile,
and they've liked attacker.com. You know, and they don't
remember how that happened. So this is actually called
click jacking attack because you can imagine you
can do all kinds of evil things here. So you can imagine you could
steal passwords this way. You could get raw input. I mean, it's madness. So once again, this
happens because the parent, essentially, gets the right
to draw over anything that's inside this bounding box. So does that attack make sense? Yeah. AUDIENCE: [INAUDIBLE],
what do you mean the parent gets to draw
over anything [INAUDIBLE]? PROFESSOR: So what I'm
trying to indicate here is that, visually speaking,
what the user just sees is this. AUDIENCE: Oh, that's
the parent frames. PROFESSOR: Yeah, this
is the parent frame. That's right. This is the child frame. So visually speaking,
the user just sees this. But using the miracle of my da
Vinci style drawing techniques, this is actually overlaid
atop this transparently. So that's the child frame. That's the parent frame. OK so, there's a couple
different solutions– you can imagine–
for solving this. The first solution is to
use a frame busting code. So you can actually use
JavaScript expressions to figure out if you have
been put into a frame by someone else. So like, one of these tests is
you compare the reference self to top. So in the JavaScript
world, self refers to frame that you
yourself aren't in. Top refers to the frame at the
top of the frame hierarchy. So if you do this
test and you find out that self is not
equal to top, then you realize that you
are a child frame. And then you can refuse to
load or do things like this. So this, in fact,
is what will happen if you try to create a frame
for, let's say, CNN.com. You can actually look
in the JavaScript source and see that it does
this test because CNN.com doesn't want other people
taking credit for it's content. So it only wants to
be the top most frame. So that's one solution
you can use here. The other solution
that you can use here is also to have your web
server send this HTTP response hitter called x-frame options. So when the web server
returns a response, it can set this header. And it can basically
say, hey, browser, do not allow anyone to put
my content inside of a frame. So that allows the browser
to do the enforcement. So that's pretty
straightforward. So there's a bunch of
other, sort of, crazy attacks that you can launch. Here's another one that's
actually pretty funny. So as I was mentioning
before, the fact that we're now living in a
web that's internationalized actually mean that there's
all these issues that come up involving name and
how you represent host names. So for example, let's say that
you see this letter right here. So what does this look like? This looks like a C, right? What is this? A C in ASCII in
the Latin alphabet? Or is this a C in Cyrillic? Hard to say, right? So you can end up having these
really strange attacks where attackers will register a
domain name, like cats.com, for example. But this is a Cyrillic C. So users will go to this domain. They might click
on it or whatever thinking they're going to
Latin alphabet C, cats.com. But instead, they're
going to an attacker one. And then, all kinds of madness
can happen from there, as well. So you might have
heard of attacks like this are like
typo squatting attacks where people register for
names like F-C-E book.com. This is a common fumble finger
typing for Facebook.com. So if you control this, you're
going to get a ton of traffic from people who think they're
going to Facebook.com. So there's a bunch of different,
sort of, wacky attacks that you can launch
through the domain registry system that are tricky
to defend from first principles because how are you going to
prevent users from mistyping things, for example? Or how would the browser
indicate to the user, hey, this is Cyrillic? Is the browser going to
alert the user every time Cyrillic fonts are included? That's going to make people
angry if they actually use Cyrillic as their native font. So it's not quite clear,
technologically speaking, how we deal with
some of those issues. So yeah, there's a bunch
of other security issues that are very subtle here. One thing that's interesting
is if you look at plugins. So how do plugins treat
the same origin policy? Well plugins often have very
subtle incompatibilities with the rest of the
browser with respect to the same origin. So for example, if you
look at a Java plug-in, Java, oftentimes, assumes
that different host names that have
the same IP address actually have the same origin. That's actually a pretty big
deviation from the standard interpretation of the same
origin policy because this means that if you have something
like x.y.com and, lets say, z.y.com, if they map
onto the same IP address, then Java will consider these
to be in the same origin, which is a problem
if, for example, this site gets [? owned ?]
but this one doesn't. So there's a bunch
of other corner cases involving plug-ins. You can refer to the tangled
web to see some more about some of those types of things. So the final thing that
I want to discuss– you can see the
lecture notes for more examples of a crazy Attacks
that people can launch– but the final thing
that I want to discuss is this screen sharing attack. So HTML 5 actually
define this NEW API by which a web page can allow
all the bits in it's screen to be shared with
another browser or shared with the server. This seems like a
really cool idea because now I can do
collaborative foo. We can collaborate on a
document at the same time. And it's exciting because
we live in the future. But what's funny
about this is that, when they designed this API,
and it's a very new API, they apparently didn't think
about same origin policies at all. So what that means is that
if you have some page that has multiple frames, then
any one of these frames, if they are granted
permission to take a screenshot of your monitor,
it can take an entire screen shot of the entire
thing, regardless of what origin that other
content's coming from. So this is, actually, a
pretty devastating flaw in the same origin policy. So there's some pretty obvious
fixes you can think about. So for example, if this person's
given screenshot capabilities, only let it take a
screenshot of this. Right? Not this whole thing. Why didn't the browser vendors
implement it like this? Because there's such pressure
to compete on features, and to innovate on features, and
to get that next new thing out there. So for example, a lot of the
questions that people were asking about this particular
lecture online [INAUDIBLE] was like, well, why
couldn't you do this? Wouldn't this thing
make more sense? It seems like this current
scheme is brain dead. Wouldn't this other
one be better? And the answer is, yes. Everything, yes. That's exactly correct. Almost anything would
be better than this. I'm ashamed to be
associated with this. But this is what we had. So what ends up happening
is if you look at the nuts and bolts of how web
browsers get developed, people are a little bit
better about security now. But like, with the
screen sharing thing, people were so pumped to
get this thing out there, they didn't realize
that's it's going to leak all the bits on your screen. So now we're at his
point with the web where– I mean, look
at all these things that we've discussed today. So if we were going
to start from scratch and come up with a
better security policy, what fraction of websites
that you have today are going to actually work? Like, approximately,
.2% of them. Right? So users are going to complain. And this is another constant
story with security. Once you give users a feature,
it's often very difficult to claw that back, even if
that feature is insecure. So today, we discussed a
lot of different things about the same origin
policy and stuff like that. Next lecture, we'll
go into some more depth about some of those things
we talked about [INAUDIBLE].

12 Comments

12 Replies to “8. Web Security Model”

  1. Someone register аpple.com where "a" is Cyrillic 'a' . For that reason apple products never display domain names in Cyrillic but they IDNs meaning instead of аpple.com it will show "xn--pple-43d.com/" when "xn--" means that domain is in Unicode.

  2. L W says:

    can someone explain to me where the script is being put?

  3. vaibhav M says:

    Great lecture. Prof sounds like Aziz Ansari 😀

  4. Jason Hord says:

    You know you are in the right place when you are given the warning "everything is horrible" within the first minute. Securing the web is like solving P=NP. While on fire.

Leave a Comment

Your email address will not be published. Required fields are marked *