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. So let's get started
with the second lecture in our stunning series
on web security. So to start off the
class today, I actually want to go over
some quick demos. So as you know, demos
almost never work. So hopefully, you won't just
be seeing my empty terminal up here. But the basic idea
is that I first wanted to show you an
example of the Shellshock bug that you may have heard of. This has been a pretty
sort of popular topic in the security literature. And people were
saying that Heartbleed was like a 10 out of
10 security [? bug. ?] But people were saying, like,
we should not have reserved 10 out of 10 for Heartbleed. This is potentially worse. All right? And so I thought that this would
be a great idea for you guys to see some living history, and
for you to tell your parents that, you know, they're getting
their tuition's worth out of MIT. So what is the basic idea
behind the Shellshock bug? Well, it's a really
great example of why it's so difficult
to build secure web applications that span
multiple technology stacks, multiple languages,
multiple OS's, so on and so forth. So the basic idea
is that Shellshock is going to take
advantage of the fact that the attacker can
craft a special HTTP request to a server and
control the headers that are in that request. And so I've written
an example up here. It's very simple. So let's say that the attacker
wants to send some GET query. They're going to send that
query to some CGI interface. And then there's going
to be some question mark. The person wants
to search for cats, because that's all
that people search for. And then there's some
standard headers here, like host, for example. So this is saying
that this URL here is hanging off of example.com. Now, note that the attacker can
also specify custom headers. Right? So the attacker can
just say, I want it to find some
application-specific header called Custom-header, and I want
to specify some value there, because you can imagine that
a web application might define certain functionalities
that can't be expressed using the simple,
pre-defined HTTP headers. OK. So that all seems
fairly innocuous. But what ends up happening is
that in a lot of these CGI web servers, they will actually
take these custom header values and use them to set
environment variables for Bash. OK? So they will use this header
to create a Bash variable name custom header. Then they will take
this value here that the attacker
has supplied, and use that to be the value of
that Bash variable, right? And then once that
variable is set up, then the CGI server
will do some processing in the context of
that environment. Right? So this is clearly bad. You can probably see
where this is going. Web servers should not be
taking these arbitrary values from arbitrary unwashed masses. So in the particular example
of the Shellshock bug, what ended up happening is that
if you set your Bash variable to this, this kind of malformed,
evil-looking thing, then there's going to be
insanity that happens. Basically, this is a malformed
[? Select ?] function definition in the Bash
scripting language. You don't have to worry
about the specifics of it. But what was intended to
happen, if Bash were correct, is that this part over
here wouldn't be executed. So basically, you just defined
some stupid function here that doesn't do anything. And in the [INAUDIBLE]
terminate here. But this sequence of
characters actually confuses the Bash parser. And so what ends up happening
is that it sort of stumbles through this nonsense here. And then it says, oh, I
might as well keep on parsing and execute some
commands here, right? And so in this case, this
just does the bin/id command, which displays some
information about the user. But this could be
any code right here. So that's the heart
of the vulnerability. So I'll give you a very
simple example here, so you see up on the screen. So basically, we've got a very
simple Python server here, just the dumbest one you
could possibly imagine. It's got this do GET method. And so with the
do GET method, it is going to basically iterate
through all of the HTTP headers in the request. OK? So that's what this four
key value for the header and the value in this request. And then it'll just print out
the headers that it finds. And then in this
dirt-simple example, it's going to do
something very dumb, which is execute the system
call and just directly set the environment value to the
value specified in the header. So that's the whole
root of vulnerability. So if I come over here and I
start my victim web server-- OK, so it's now ready
to accept requests. And then I can write my special
Shellshock client like so. And this is actually
pretty dirt-simple. So here, I just define one
of these malformed strings. So I have these kind of janky
characters at the beginning. And then I know that everything
after this is essentially going to be executed on my
behalf on the server side. So in this case, I
pick something that was actually pretty innocuous. It just says, echo,
I own your machine. But this could be anything here. You could start another Bash
shell kind of like I do here. And then, echo attacker command,
where in the real world, that could actually be
something very dangerous. So then I set the headers
and my custom request. And then I just use Python
to create an HTTP connection and just send it to server. So what ends up happening? So I execute my
Shellshock client here. So it's saying that
I had a 404 here, because it doesn't matter
what file I requested. So I just put in some index,
an HTML that doesn't exist. But if we look over here, this
is the output for the server. And so what you see is
that you have this output, I OWN UR MACHINE,
and ATTACKER CMD. And that's because as the
server got that header, it set the Bash variable. It set it with this
weird thing here. And as a result, an
ATTACKER-controlled command got the run. So does that all make sense? AUDIENCE: So does this happen if
the program is run under that? I'm still unclear on, like-- PROFESSOR: Yeah. So the specifics of how
the attack works actually depends on are you running
Apache, like what exactly your web server looks like. So in this example, it's
a little bit contrived, because I actually called
[INAUDIBLE] explicitly spawned off another Bash shell, set the
environment variable in there, and then we were ready to go. But you could imagine that
if you were spawning off a different process for
each incoming connection, you could set the environment
variable for that directly if that guy was using--
was living inside of a Bash environment. AUDIENCE: So if you go back
to your web server code, it seems that you have a
much worse vulnerability than the Shellshock, because
you're calling [? though ?] a system. And I can execute a command just
by setting the custom header to something [? that I ?]. I wouldn't have to use the
Shellshock bug in this example. PROFESSOR: That's correct. Yeah. So in this particular web
server, which is something I wrote just for sort
of teaching value, yeah, this thing you
shouldn't trust for anything. AUDIENCE: But the
Shellshock exploit was on assigning something
malicious to an environment variable using [? set N ?]
or something like that, which is something [INAUDIBLE]. PROFESSOR: Oh, yeah, yeah. So that gets back
to his question. That's right. So if you had, like,
let's say, Apache up here, Apache's a little bit
tricky to sort of configure in a way that's obviously
what's going on. But you're exactly right. So Apache would
call Set nth, which is another way that you can
directly set the environment value for whatever
particular service [? I ?] process you have. But you also actually
have some servers like this that you can
imagine that they actually do a spawn of a separate process
and do something very morally equivalent to this. But you're exactly
right, that the way that a patch in
particular was violated was the way that you described. So does it all make sense? OK. So that's sort of a
quick and dirty example of Shellshock stuff. And so another example
I wanted to give you was an example of
a cross-site scripting. And so the Shellshock
bug was sort of an example of how content
sanitization is very important. So as we'd just been
discussing, you shouldn't just take inputs from
an arbitrary person and them use them directly
in commands of any type. So cross-site scripting
attacks are another example of how something can go wrong. So in this example,
I have another sort of dumb CGI server here. And if we look at
this CGI server, so what is it going to do? So once again, I've written
something very simple in Python. This is going to
be the handle that executes when a request
comes in from the client. And so essentially,
what happens is that up here, I'm going to print
some headers for the response. So I'm going to
say, my response is going to be of type text HTML. This line here we'll
actually explain in a second. So as it turns out, browsers
have some security mechanisms to try to prevent the attack
that I'm about to show you. So I put this example-- I
put that header line in there to turn some of the
protections off. And then what the
CGI script does is it gets access to all of the
fields and the CGI requests. So imagine that everything
in a query string after this question mark-- like
these header and value things, that's what goes into
that form example there. And so what the CGI script
does is something very simple. It just directly prints
the value of something that was passed from the attacker. So same basic idea. This is a bad idea, because
this Print statement, it's printing directly
into the HTML itself. So what can happen
is as follows. So let's say that I have a
bunch of queries I want to run. So in this first query here, I'm
just setting the message value to Hello. So if I go over here
and I run that page, well, then you're going to
see that this Hello shows up, because once again, the
server was taking directly what I pass to it. And it prints Hello. So no big surprises there. Now let's say I realize
that I can actually pass arbitrary HTML in there. So now I actually try to
embed some styling in there. So I say, h1 and
then Hello again /h1. So that worked, right? So once again, we're printing
directly into the [? pake. ?] So now you might think,
OK, we're in business now. This is cool. So let's just directly embed
some JavaScript code in there. All right. And so I do this. And here, I've actually just
put in-- for the message, I put script. And then I want it to just
alert XSS and then script. So now that's interesting. So it seems like something
didn't quite work. So I don't see any output. I didn't see the alert either. And if I actually look at the
output for the web server-- and what I see is
that here, the web server itself didn't actually
get that trailing script tag. So it seems like the
browser itself has somehow detected something evil
even though I tried to disable the XSS filter. So that's interesting. We're going to come to this
defense mechanism a bit in the lecture. But suffice it to say,
it seems like the browser is trying to resist this
cross-site scripting attack. But of course, what
we can take advantage of is the fact that HTML,
and CSS, and JavaScript, they're extremely
complex languages. And they compose in these very
difficult to understand ways. So here, this is what I've been
setting my attack string here. This is malform URL. I'm saying, image, and
then three quotation marks in a row, and
then a script tag. Like, this shouldn't
actually parse. But what's going
to end up happening is that the browser's
going to get confused here. So it's built-in cross-site
scripting detection actually fails here. And so what ends up happening
is that now you see the alert. OK? And what's interesting
is that if you actually look at the contents of the page
now, it's kind of messed up. Like, where did this quotation
mark and brace come in? If we do a Control,
U, we can see that this does not make the
browser happy in some way. That's a little bit unclear. But it doesn't matter
if we're their attacker. We saw that alert. That means that
[? our code ?] got the run. And from the perspective
of the attacker, who cares that the page is messed up now? Because I could
have used that code to steal the cookie
or things like that. So does that all make-- yeah? AUDIENCE: What's the
cross-site aspect? PROFESSOR: Ah. So the cross-site aspect is that
if the attacker can convince the user to go to
a URL like this, then the attacker's the
one who's specifying that stuff in the message. It's the attacker who's
specifying the alert XSS or something like that. And so essentially,
what's happening is that the victim
page is executing code on behalf of someone
that is not that page. AUDIENCE: Can you explain
exactly what the browser roles are for sanitizing
[? games ?] for [? play? ?] PROFESSOR: Yeah, yeah. So we'll get to
that in a second. So we'll get to
that in a second. OK. So that is all for story time. And let's see here. So I guess I can
turn this guy on. And maybe he will
[INAUDIBLE] guy here. This guy here. AUDIENCE: Front wall. PROFESSOR: Ah, OK. There you go. All right. Eighth time's the charm. OK, thanks. OK. So yeah, so those are just two
quick demos to sort of show you the filthy and dirty world
that we live in right now. So why is cross-site
scripting so prevalent? Why are these problems
such a big deal? Well, the reason
is that websites are increasingly more
and more dynamic, and they want to incorporate
a user content a lot of times, or they want to incorporate
content from other domains. So think about the Comment
section on a news article. Those comments come
from untrusted folks, from the users. So somehow, these sites
have to figure out, what are the rules for
composing those types of things? And also, the websites might
host user-submitted documents, a thing like Google Docs
or Office 365, for example. Those documents all come
from untrusted folks, but somehow, they have
to live with each other and with the large
infrastructure from Google or from
Microsoft or whatnot. So what are some of the
cross-site scripting defenses we can use? This kind of gets
to your question. So we'll actually look
at some of those now. So one type of defense
is to basically have cross-site scripting
filters in the browser itself. And so these filters
will essentially try to detect when there's a
potential cross-site scripting attack. And so we actually saw one
of those filters in action. And I think that was the third
example that we looked at. If you have some website--
or some URL-- excuse me-- that looks like
this-- so foo.com. And then you have some question
mark and then some query string you're going to submit. This is very similar to the
example that I tried third. So I just set this
source to something like evil.com/cookiestealer.js. And so what ended
up happening was that when I tried an
example similar to this, the browser actually
rejected it out of hand. So we saw that it
didn't even work. And the reason
why it didn't work is because the browser
looked and said, is there an embedded
script tag in a URL? So basically, it's a
very simple heuristic for figuring out if something
evil's probably going on, because no legitimate
developer-- or no developer that's sane-- should be
doing stuff like this. So there's actually these
configuration options in your browser you can use to
turn these things on and off. Occasionally, this
is useful for testing if you just want to inject
some JavaScript really quick and dirty. But this is almost always
assigned [INAUDIBLE]. So for example, Chrome and IE
have a built-in filter that will look at your URL
value in the address bar, look for things like this. And if it's there, they will
do things like maybe delete this whole thing completely. They will maybe change
the source to be empty, stuff like that. And so essentially, to
get to your question, there's a bunch of heuristics
that the browsers have to identify things like this. And if you look
at the OWASP site, they actually collect
examples of heuristics you can use to detect
cross-site scripting, as well as tricks you can
use to bypass those filters. So it was very funny. So the first thing I
wanted to do for the demo is do something like
this, and it didn't work. So then I went to the
OWASP cheat sheet. I looked at, like, the
third thing they suggested, and the third thing
they suggested worked, which was that sort of
broken image syntax type stuff. So the basic problem
with just relying on this is that, like I said, there's
a lot of different ways to force the CSS and HTML
parsers to mal-parse something. So these things are
not complete solutions. They don't have the
perfect coverage. AUDIENCE: Shouldn't this
just be like the lead-in from the browsers? Because it seems like not
the browser's job to do this. PROFESSOR: You mean it's
not the browser's job to sanitize this kind of stuff? AUDIENCE: Yeah. PROFESSOR: I mean,
you could imagine sort of having a browser sit
atop a proxy, for example. And maybe the proxy did
sort of cleaning like this. I mean, intuitive reason
why it might make sense to do it inside the
browser is because so many of the legitimate parsing
engines are inside the browser. So presumably, if you're closer
to where the actual parsing's being done, it's better. But you're right. In practice, you can imagine
there being sort of defense in layers, basically. AUDIENCE: I think
what he might be saying is that it's the
web developer's job, not the client's job
to sanitize this. PROFESSOR: But, I mean, that's
kind of like saying-- so in a certain sense, we could
say that about processes, too, in Unix or Windows. So we could say it's
sort of developers' jobs to make sure those
things stay isolated. But in fact, the
OS and the hardware as well has an
important role to play, because [INAUDIBLE] trusted
whereas any two arbitrary programs developed by any
two arbitrary developers may or may not be trusted to
sort of implement security correctly. But you're correct. And in fact, frameworks
like Django or whatnot, they actually try to
help you to get around some of these problems. So anyways, so yeah, so filters
are not a perfect solution. And also, filters
can't prevent what's known as a persistent--
persistent-- cross-site scripting attacks. This is known as sort of a
reflected or transient one, because this script code just
sort of lives in the URL. Then once the user's
closed that URL, basically, the attack's gone. But you could imagine
that you could have someone who-- user puts
malicious HTML in the Comment section for a website. And if the web server actually
accepts that comment is valid, then that comment, with
this malicious payload, can essentially
live there forever. So whenever any user
goes there, they would be exposed to
that malicious content. Another example,
which is sort of funny and sad, as
all these things, is if you look at
dating websites. So some dating
websites actually allow users to put full-blown
HTML in their profile. So what does that mean? So when someone else is
lonely, presumably, or looking to find their one true soul
match, they go to your website. They're going to
run HTML that you've crafted in the context
of their session. And so that can also be a
very damaging attack as well. So just doing these
kinds of filters don't protect against
things like that. AUDIENCE: So [INAUDIBLE]
in the Comments section presumably does
that by setting a post-- the information goes to the
server in a post variable or something like that? PROFESSOR: So there's a
bunch of different ways you could imagine doing it. Yeah. So one way you could
imagine doing it is a post. Another way you could imagine
doing it is a dynamic XML HTTP request. AUDIENCE: OK. But if it's like a post, why
can't you just scan through it and do the same thing
that you have in the-- PROFESSOR: Yes. So you're exactly
correct about that, and we'll discuss some
of that in a second. But you're exactly
correct that the server side of the
application should be very defensive and
mistrustful of this stuff. So you're exactly right. So you could imagine that
when the server maybe saw something like
this, [INAUDIBLE] even if the browser did not. You're correct about that. All right. So that's basically a survey
of these cross-site filters in the browser. So another defense against
cross-site scripting is something known
as HTTP-only cookies. And so the basic
idea behind this is that a server can
actually tell the browser that client-side
JavaScript should not be able to access a
particular cookie. And so basically,
the server can just send a header value in response
in the set Cookie field. It can say, hey, don't let
clients like JavaScript manipulate this cookie. So only the server
could do this. And so this is only a
partial defense, though, because the attacker can
still issue requests that contain the user's cookies. So this was the
cross-site request forgery that we looked at
in last lecture. So even if JavaScript code
can't manipulate cookies, the attacker can still
do things like conjure up a URL to some e-commerce
site, let's say buy.com. The attacker can put whatever
item the attacker wants to buy. So puts a Ferrari, for example. And then the attacker can then
say, who should this go to? This should go to the attacker. And so even though
clients like JavaScript can't access the
cookie, there's nothing that prevents the attacker
from just conjuring up a URL like this. This is what some
of the CSRF tokens help to prevent
against, which we'll talk about a little bit later. So another thing
that you can try to do to prevent these
cross-site scripting attacks is privilege separation. And so the idea
here is basically that you want to use a separate
domain for all the content that is untrusted. And so for example, a lot of
the online server providers were things like email or
online productivity suites. So think Google Docs, Office
365, so on and so forth. They actually use
a separate domain to host user-submitted content. So Google, I think
they still use this. They used to put all
the stuff that users submitted into
some special domain called googleusercontent.com. And so here, they
would put things like cached copies of pages,
your Gmail [INAUDIBLE], and things like this. And at least as of
a year or two ago, this is like one of the top 25
[? Alexa-visited ?] domains, because Google services
were so popular. And so what's the advantage
of putting stuff in here? Well, the hope, at
least, is that if there is some type of cross-site
scripting vulnerability or something like this in
a user-submitted content, then hopefully, the
daemons would just be limited to that domain. It wouldn't actually affect
the full-blown google.com. This isn't a perfect
defense, though, because user-submitted
content may have references to things from google.com. And so once again,
this is only sort of a partial fix for a much
more pervasive problem. Now, another thing
you could do-- and this gets back to the
gentleman's suggestion over here is that
we can actually do content sanitization. And so the idea here is that,
essentially, whenever you-- where you can be the browser,
where you can be the web server, or whatever-- whenever
you receive untrusted content, you don't trust it at all. And so you go through it, and
you do things to sort of render it sort of neutral such
that it can't actually execute code or subvert
your system in any way. And so an example of this is
the Django template system. And so Django is an
example of a web framework. So basically, the
high-level web framework is something that helps
to automate and secure some of the sort of tedious
tasks of developing a website. So it will help you with
making database access easier. It'll help you with doing
things like session management. And it will also help you with
maintaining a consistent look and feel across your website. And so one way to maintain
that consistent look and feel is to use this
notion of templates. So all of your
pages automatically start out with the
same CSS and things like that, the same styles. But then there's these
portions in the web page where you can specialize
it with the particular news article that's at the top of
everybody's mind that day, or something like that,
or user-specific content. So for example, in Django,
you can look at a template, and it might look like
something like this. So you have a bold tag. It says, Hello. And then you have these braces
here, these double braces. And it says, name. And so essentially,
what this means is that this is like a
placeholder variable. So essentially, these pages
get dynamically generated. So when the user goes
to a Django site, the Django server says,
OK, well, this name is going to be somewhere,
who knows, in the cookie. Maybe it's going to be in
a CGI string, whatever. And so as the Django
server dynamically generates the page
[? to return ?] to user, it replaces this
special reference here with whatever the value
of this variable is. So it's pretty straightforward. This is kind of like that
dinky CGI server I showed you. So just reflecting
user-submitted content right here. But Django actually does it
better than the silly CGI server that I showed you,
because it uses this notion of content sanitization. So Django expects that
users may be adversarial. So it's not just
going to directly put the value of the
name variable here. Instead, it is going to
encode it in such a way that this content will
never be able to escape out of the HTML context
and execute JavaScript or something like this. So for example,
one thing it'll do is it'll take the
angle brackets, and it will translate them
into these HTML entities. So the less than character
gets transformed into this. The greater than character
gets translated into this. Double quotations get
translated into ampersand quote, and so on and so forth. And so what this ensures is
that if the content the user put in name actually tries
to contain angle brackets or things like this, then
it'll basically be neutered. And it'll be translated
into something that would not be
interpreted as HTML on the client-side browser. So does that make sense? So now I know that this is not
a completely foolproof defense against some of this
cross-site scripting stuff. And the reason, as we
showed in the example, is that these grammars for
HTML, and CSS, and JavaScript are so complicated that
it's very easy to confuse the browser's parser. So for example, let's say that
you had something like this. And this is a very
common thing to do in frameworks like Django. So you have some div. And then you want to set
its class dynamically. So you set its class to some
var, so on and so forth. So the idea is that when
Django processes this, it should figure out what the
current styling is and then put it in here. Well, one thing
you can do is maybe the attacker supplies something
like a string like this. So attacker will say, class 1. OK, so far so good, because
that seems like a valid CSS expression. But then the attacker
will then try to put some JavaScript here. So it might say, onclick
equals-- and then put JavaScript URL. And then put some
function call here. So this is malformed. The browser should probably
just do a fail-stop here. But the problem is
that if you've ever looked at the HTML for a
real web page, all of it's broken, even for like
legitimate, benevolent sites. People just can't hack HTML. So if the browser
were to be fail-stop, literally, no site that you
enjoy would ever work ever. If you ever want to be
disappointed by the world if I haven't helped
you do that enough, open up your JavaScript console
when you browse a website and see how many
errors get spit out. Like, go to CNN and just see
how many errors get spit out. CNN basically kind of works,
but it's very disturbing, because if you were to
open up Acrobat reader and you're just
constantly throwing null pointer
exceptions, you would feel a bit cheated by life. But in the web, apparently,
we've learned to accept this. So because browsers have to be
so tolerant of these things, they will actually try
to massage malformed code into something that
seems reasonable. And therein lies a
security vulnerability. So I guess the
take-home point for this is that content
sanitization kind of works. So it is literally
better than nothing. It can actually
catch a lot of cases. But in many cases, it
is not a full defense. And so one thing you might
actually think about doing is-- actually, let's
put this over here. You might think about sort of
using a less expressive markup language. So what do I mean by that? So HTML and CSS and JavaScript
are [? touring ?] complete. They allow you to do all kinds
of fun things, but-- yeah? AUDIENCE: Sorry to bother you. When does content
sanitization not work? PROFESSOR: When does content-- AUDIENCE: In many
cases, it doesn't work. PROFESSOR: Oh, yeah. So like in this
case, for example, Django will probably not be
able to statically determine this is a bad thing. Like, in this particular case. But in the case where I inserted
that malformed image tag-- I basically said-- AUDIENCE: In that
particular case, I would expect the
class=assignment to be in quotes and then for that
thing to not have any effect. So Django could enforce
codes that [INAUDIBLE]. PROFESSOR: Well, see, there's
a little bit trickiness there, because if we assumed that
all pages were written-- well, pull me back up a little bit. If we assume the HTML
grammar was well specified and the CSS grammar
was well specified and so on and so
forth, then you could imagine a world in which
perfect parsers would be able to sort of
catch these problems or somehow convert
them to normal things. But in fact, the HTML
grammars and the CSS grammars are not well specified. And then on top of that,
browsers don't implement specs. So it's like Babushka
dolls of terror. So I mean, this, in fact,
gets into this notion here. Because I think essentially
what you're saying is, well, look, if we have
the grammar for something, that should mean something. And as it turns
out, if you stick to a less expressive grammar,
then it is actually much easier to do content sanitization. There's some language. It's called Markdown
instead of markup. [? Wall, ?] right? And so with Markdown,
the basic idea is that it's designed
to be a language that allows, for example,
users to submit comments, but it doesn't actually have
things like the blank tag, and applet support,
and stuff like that. And so in Markdown, it's
actually much easier to do what you suggested, which
seems like a reasonable thing at first glance. Just define the grammar
unambiguously and then just enforce that grammar. So it's much easier
to do sanitization in a simple language than
in the full-blown HTML, CSS, and JavaScript. And in a certain
sense, think about it like the difference between
understanding gnarly C code versus gnarly Python code. There's actually
a big difference in trying to understand that
much more expressive language. Because it can do
many more things. By constraining
expressivity, you oftentimes improve security. Does that all make sense? All right. So another thing
that you can imagine doing to protect against
cross-site scripting attacks is to use something called
CSP, Content Security Policy. And so the idea behind
CSP is that it's going to allow a web server to-- oh. AUDIENCE: Yeah, I'm just curious
about this Markdown language. So all browsers know how
to parse this language? PROFESSOR: No, no, no. So what happens with a lot
of these types of languages is that you essentially--
you can convert them. You can pile them down to
HTML, but they're not natively understood by the
browser, typically. So in other words, you've got
some comment submission system. It internally expresses
stuff in Markdown. But then before it can
be rendered to the page, it essentially goes to
the Markdown compiler. The Markdown compiler then
translates it to HTML. AUDIENCE: I see. Thanks. [INAUDIBLE] Markdown
might not be the best trick
[? to use Markdown ?] [INAUDIBLE]. PROFESSOR: So Markdown
does allow inline HTML. As far as I know,
there's a way to disable that in the compiler. I could be wrong about that. But I believe that
there's a flag you can pass to get rid of it. But you're correct. If you use a
constrained language but then you embed an
unconstrained language, then that-- I mean, the
terrorists have won. So you're right about that. OK. Yeah. So another thing you can
do to improve security is this thing called
Content Security Policy. So like I was saying, what
this allows the server to do is to tell a web browser
what types of content can be loaded in the
page it's sending back, and also where that
content should come from. So for example, in
an HTTP response, the server might be able
to say something like this. It'd include the Content
Security Policy header. And then it might say
something like the default source is going to equal self. And it will also accept things
from asterisk mydomain.com. So what does this mean? So essentially, the server
is saying the content from this site should
only come from whatever it is that the domain is
for the particular page. And any other subdomain
from mydomain.com. So what that means,
basically, is that let's say if self
was bound to foo.com, let's say, that's the origin
of the server that's sending this thing back to the browser. So if, somehow, there is
a cross-site scripting attack and the page tried
to generate a reference to, let's say, bar.com,
the browser would say, OK, bar.com is not self. Bar.com is also not in this
sort of set of domains. So therefore, the
browser can just say, I will not allow that
request to go forward. So this is actually a
pretty powerful mechanism. And you can actually specify
more fine-grained controls here. You can say, my images
should come from here. My scripts should come from
here, so on and so forth. This is actually pretty nice. And one nice thing
about this, too, is that it actually
prevents inline JavaScript. So you can't have script tag
and then some literal JavaScript and close script tag. Everything has to come from
a script tag with a source. So it can be validated
through this. And also, a Content
Security Policy prevents these danger
statements like eval. So eval basically
allows a web page to check dynamically
generated JavaScript code. And so if the CSP
header is specified, the browser does
not execute evals. So does that all make sense? AUDIENCE: So since it's a
kind of ad-hoc set of things, is that like a complete set
of things that it [INAUDIBLE]? PROFESSOR: No. So there's a whole
list of resources that it actually protects. So this is sort of like the
most blanket type protection you could get. But like I said,
it actually allows you to specify, I think,
like, where CSS can come from, like a bunch of
different things. AUDIENCE: But on preventing
evals, that seems like the system's [INAUDIBLE]. Are there are other
things [INAUDIBLE]? PROFESSOR: So yeah, there are. So there's always this
question of completeness. So for example, eval
is not the only way JavaScript can actually
generate code dynamically. There's the function
constructor, for example. There's certain ways you
can call a set timeout. You pass in a string. You can evaluate code that way. So I believe that CSP actually
shuts down those vectors as well. But if you're asking, is this
provably complete in terms of what it isolates, no. And I don't think that
any of these solutions are provably complete. AUDIENCE: One really
interesting thing about CSP is the fact that you can set
it to disallow all inline [? dom ?] script on a page. PROFESSOR: Yeah. That's right. Yeah, yeah. AUDIENCE: Which [? helps ?]
[INAUDIBLE] to be sanitized. PROFESSOR: Yeah. AUDIENCE: [INAUDIBLE]
prevents an attacker from-- PROFESSOR: So that
helps with some things. But that still would allow,
like, [INAUDIBLE] to use eval. So that's why it's
important to try to get rid of all of those dynamically. All of those interfaces
[? use dynamic ?] code generation. AUDIENCE: If you list your tag
with a source but then also inline code, is there like
standardized [INAUDIBLE] that all browsers do with-- PROFESSOR: Yeah. So what should happen
is that the inline code should be ignored. The browser should
always get the code from the source attribute. I actually don't know
if all browsers do that. I've actually
personally experienced browsers exhibit different
behavior [? in that. ?] This was a couple years
ago, so I'm not sure. And so yeah. So one thing to keep in
mind about doing work in web security is
that in a sense, it's almost like
a natural science. So it's like people
actually propose theories about how browsers work. And then you go
seeing them do that. And so that can be a
little bit disappointing, because we're taught, yay,
algorithms, and proofs, and stuff like that. But these browsers are
so ill-behaved that a lot of times, the answer
is maybe or maybe not. And then [? you go ?]
see, as we'll see. They keep on adding features. It gets back to
your question about, are these things
provably complete? I think web vendors have punted
on this notion of creating a browser that is
provably [INAUDIBLE]. Basically, what
they try to do is just try to keep one step
ahead of the attackers. And we'll see some examples of
that further in the lecture. So yeah. So CSP is actually pretty cool. Another thing that's useful is
that the server can set this HTTP header called
X-Content-Type-Options, and then can say, nosniff. And so what this means is
that this prevents the browser from doing some of those, quote,
unquote, helpful optimizations, like we discussed last lecture,
where it will say, a-ha, there's a mismatch
between the file extension and the actual [? bytes ?] that
I have sniffed in the contents. So let me somehow
massage this content to some different thing. And then all of a sudden, you've
given the barbarians the keys to the kingdom. So you can set this
header to basically say, browser, do not do that. And so that can be
useful in mitigating some types of attacks as well. All right. So that's kind of a
quick survey of some of these cross-site
scripting vulnerabilities. So now let's look at another
popular vector for attacks. And that vector is
going to be SQL. And so you've probably heard
of these SQL injection attacks. And so what these attacks do is
they take advantage of the fact that on the back end,
for a lot of websites, there's some type of database. And so to dynamically
construct a page that's shown to the user,
there have to be some database queries that are
issued to that back-end server. So imagine that you have some
query that looked like this. So you do a SELECT asterisk. So give me all the values
from this query FROM some particular table,
WHERE the User ID field is equal to something
that is specified over the web from some
potentially untrusted source. So at this point, I may think
we all know how this story ends. It ends very badly
There are no survivors. So basically, if this comes
from someone untrusted, then you can do all kinds of
[? chicaner ?] stuff here. So one thing you could do
is if you want to be a jerk, you could just set
this to the string, 0 and then something
like DELETE TABLE. So what happens here? So basically, the database
server's going to say, OK, I'll set the user ID to 0;. Here's a sort of a new command. DELETE TABLE. OK, cheers, there
goes your table. And you're done. And in fact, there
was a viral image that went around a couple years ago. It's unclear if it
was true, like many of these viral images. But it was that
people in Germany had license plates that
actually said 0; DELETE TABLE. [LAUGHTER] Because the idea is that
the security cameras, they would use OCR, Optical
Character Recognition, to figure out what your license
plate was, and then put it in a SQL database. And there were images
floating around. These Volkswagens,
people would have this as their license plate. I don't know if that works. It's funny. So I like to believe
that it's true. But who knows. But you get the basic
idea behind that. So once again, the
idea is you want to be sure to sanitize this
content that you're getting from these untrusted sources. And so note that
there may be some sort of straightforward things
that don't quite work. So you might think,
OK, well then why can't I just put another
quote here and then put another quote here
such that whatever it is that the attacker
submits, it's going to be enclosed in a string? So this doesn't work, because
then the attacker can always just put a quote inside
his or her attack string. So a lot of times, these
sort of half-hearted hacks don't really get you the
security you think they might. So the solution here
is that you need to rigorously encode your data. And once again, that just means
that when you get information from an untrusted source,
don't just stick it in the system sort of as it is. Make sure that, for
example, it can actually escape from whatever
sandbox or whatnot you think you're actually putting into. So for example, you want to
put in an Escape function that would prevent
maybe the semicolon operator from showing up in a
raw form and things like this. And so a lot of
these web frameworks like Django will actually have
built-in libraries to do things like character escaping
for SQL queries to try to prevent
some of this stuff. And a lot of these
frameworks actually encourage developers not
to ever directly interface with the database. So it's like Django
itself would provide some high-level interface which
does sanitization for you. It takes care of some of
these icky corner cases. But performance,
performance, performance. Sometimes people think
that these web frameworks are too slow. So you will still see, on
the back end a lot of time, people will still make
these raw SQL queries. And that can lead to problems. So you can also
imagine that there are problems if the web
server takes in path names from untrusted images. So imagine that
somewhere in your server, you do something like this. You have an open call. And then you say
that you're going to read from the WWW directory. You're going to read from the
images subdirectory in there. And then you're going to read
from some file name that, once again, is supplied by the user. So as we saw in some of the
discussion of [? Troot ?] and things like this, what
if this file name maps to something like a bunch
of instances of the dot dot character? So if you're not careful,
then the untrusted entity can specify basically
glub, glub, glub, glub, and go down to etc
password and may be able to do some evil here. So once again, if you want
to be able to use the web server or the web
framework, you need to be able to detect these
dangerous characters, escape them in
some way to prevent sort of those raw
commands from executing. So yeah, it's all
pretty straightforward. OK. So let's move on from
the discussion of content sanitization, and now let's
talk a little bit about cookies. So cookies are a
very popular way to do session
management, to bind the user to some
set of resources that exist on the server side. And so a lot of frameworks
like Django, like [? zoobar ?] that you see in this
class, they actually put a random session
ID inside the cookie. And so the idea is that
this session ID is the index into some server-side table. So you just supply
the session ID there. And this is where
your user info lives. And so as a result, this session
ID and cookies, by extension, are very sensitive entities. And so that's why
a lot of attacks involve stealing of
the cookie in order to get that session ID. And so as we discussed
in the last lecture, the same origin policy can
help you, to a certain extent, against some of these
cookie-stealing attacks, because there are
origin-based rules that prevent arbitrary
tampering with cookies. But one thing that's
a little bit subtle is that you shouldn't share
a domain or a subdomain with someone that
you don't trust. Because as we discussed
in last lecture, there are these sort
of very subtle rules in which two origins with
the same domain or possibly some subdomain relationship,
they can actually access each other's cookies. And so if you trust a
domain that you shouldn't, then that domain may be able
to do things like directly set the session ID in that
cookie that both of you can access. And that can do things
like allow the attacker to force the user to use a
session ID of the attacker's choosing. And then, for
example-- let's say the attacker sets the user's
Gmail cookie, let's say. The user goes to Gmail,
types some emails. The attacker, later on,
can then use that cookie or specifically use
that session ID, load up Gmail, and
then access Gmail as if he or she were the
user who was victimized. So there's a lot of subtleties
with using these cookies for session management. So there's a lot more we
could talk about cookies. We'll discuss some of it
today and last lecture. So you might be thinking, well,
can we just get rid of cookies? Cookies just seem more
trouble than they're worth, just like [? dribbels. ?] So can
we just not have these cookies? So one thing you could imagine
is you could imagine basically having some notion
of stateless cookies, of somehow getting rid of the
notion of sessions altogether and preventing this
nasty attack vector that seems to be sort of prevalent
in all these discussions that we have. So the basic idea here is if you
want to go sort of stateless, then this essentially
means you have to authenticate every request. Because the nice
thing about cookies is that they basically
follow you wherever you go. So you authenticate
once, and then every subsequent
request you make has this little token in it. But if you want to get rid of
those things, well then now you essentially have to have
some proof of your authority in every request that you make. And so one way you
could imagine doing this is by using something
called MAX, or Message Authentication Codes. And so the basic way to
think about one of these MAX, it's like a hash that
takes in a key as well. So the method
authentication code is the hash of some key
and then some message. And so the basic idea is
that the client, the user, and the server are going to
share some secret key, k. And so the client uses that
key to produce a signature over the message that
it sends to the server. And then the server,
who also knows the key, can then use this
same function here to validate if a
signature is correct. OK. So let's look at a very specific
example of how this works. So one real service
that uses these types of stateless cookies
is Amazon Web Services. So like x3, for example. And so basically, Amazon, AWS,
gives each user two things-- gives that user a secret key. And so this is
equivalent to the k that we were
discussing over there. And it also gives them
a-- just think of it like an AWS user ID. So this part is not
secret, but this part is. And so every time you want to
send a request to AWS via HTTP, you have to send it
in a special format. So you'll have the first
line of the GET request. So you want to
access some photos. No surprises here. And then you will put
the host from which you expect to get it. That's not super important. So this is just some
AWS server that's there. You'll have the date. So maybe this is Monday, June 4. Whatever. And then you have this
thing that's essentially the Authorization field. And this is where the message
authentication code comes in. So essentially, what
this looks like is you've got some string here. This represents your
access ID, the user ID. And then you've
got something here, some other seemingly
random letters. And then these things
are a signature that use this Message
Authentication Code here. So what does that
signature look like? So the details are a
little bit complicated. But basically, this
signature is over a string that encapsulates a bunch
of details of this request. So essentially,
the string assigned looks something like this. So you put the
HTTP verb in there. So in this case,
that verb is GET. And then you put
[? indy5 ?] checksum of the message content. And then you also
put the content type. So it's html or
image or whatever. And put in the date. And then the resource name,
which is essentially the path that you see over here. So in other words,
this string here is the message that you pass
into the H MAC over here. And so note that the server
can see all this stuff in clear text in the request. And so that's what
allows the server to validate that that
message authentication code was correct. Because note that the server
shares that key with the user. So that allows the server to
validate that kind of stuff. So does that all make sense? AUDIENCE: [INAUDIBLE]? PROFESSOR: Oh. So in this case,
for the content, that's probably going to be
nothing, like the empty string. But you can imagine there's like
a post or something like that. You'd actually have
the data of the HTTP. AUDIENCE: [INAUDIBLE] which
is kind of an unfortunate choice nowadays. PROFESSOR: So I
believe that they do. So I checked the Amazon
documentation yesterday. So I believe they do use it. But I think-- I could be wrong,
but I think they actually use a stronger hash here. So that helps a little bit. But you're right.
[? Indy5 ?] is not the best. AUDIENCE: [INAUDIBLE]
this works. PROFESSOR: OK. So allow me to help
you, hopefully, even though I'm the
guy who confused you in the first place. So the basic idea
is that we want to get rid of this notion of
this persistent cookie that's always following
the user around. Now, the problem, though,
is that the server needs some way to identify
which client it's talking to. So what we're going
to do is we're going to ensure that
each client shares a unique key with the server. And so basically, whenever
the client sends a message to the server, the
client is going to send the message
before and then also send this special
cryptographic operation, the result of this
operation here. AUDIENCE: Oh, OK. [INAUDIBLE]
and then again, you hash it. PROFESSOR: Yeah. So basically, to
first approximation, like imagine in
the regular world, like, this would
be some cookie here instead of the authorization. But now we're getting rid of
the cookie, and we're saying, here's this clear text message. And then here's
this crypto thing, which basically allows
the server to figure out who this thing came from. And so the server knows who
the user is, because that's embedded in the clear. That's not a secret, right? But this basically
allows the server to say, aha, I know which
secret key this user should have been using
to create this if that is, in fact, the real user. AUDIENCE: Nice. OK. Thanks. AUDIENCE: So what prevents the
attacker from finding the key? Where is this secret key? PROFESSOR: Yeah,
that's a good question. So in a lot of cases,
the client for AWS is not a browser, but some
VM running in the cloud, for example. So you'll see sort of just
VM and VM communication. You can also imagine,
too, that users can sort of hand out these links
or embed them somehow in HTML. So it's like you just have
sort of this-- inside the HTML or JavaScript source
code, you'd have the code to create a request like this. So that's almost like me
giving you a capability. So if I give you
one of these things, you can make that request
on my behalf, basically. AUDIENCE: So would
it be possible to use MACs on the normal
clients [INAUDIBLE]? PROFESSOR: For a normal--
you mean like browsers? AUDIENCE: For normal users. PROFESSOR: Well, I mean,
you get into these questions like, where does
the key live, which was [? kind of like what ?]
he was asking. So in a certain extent, the
issue of where the key lives is actually super,
super important. Because if the key can be stolen
just as easily as the cookie, well then we're sort
of back to square one. So in many cases, this
stuff is actually just, as I said, sort of
server to server, like a VM to VM
somewhere in the cloud. So the application
developer runs a VM that sort of outsources a
bunch of stored stuff to AWS. AUDIENCE: So do you
think [INAUDIBLE] but isn't that kind of like
a bad way of preventing-- I mean, they have
network latency, so it can't be like too
fine-grained of a constraint that they're putting on. If an attacker sends the same
request again really quickly after the user, wouldn't
they be able to [INAUDIBLE]? PROFESSOR: Yeah, yeah, yeah. So suffice it to say that
secure timestamping is like several
people's PhD theses. But you're exactly right that if
this-- just as a crude example. So imagine this just
said, Monday, June 4. Then if, somehow, the
attacker could get access to this entire
thing and there was nothing that was
different about it-- so there was no [? knocks, ?]
no random stuff like that, then that's right. Then that request
could be [INAUDIBLE]. Now, one thing that
AWS actually does is you can actually
include an expiration date in these things. So one thing you
can actually do is add sort of an Expires
field, essentially, have that thing be assigned. Then I can hand that reference
to a bunch of different people. Kind of like I was saying
in response to his question, it acts as a capability. The server can then check
that expiration date from when it actually sees
it and then not actually-- AUDIENCE: But even if
the expiration date is like 200 milliseconds in
the future or something, as long as the attacker
has [INAUDIBLE] latency, then they might
send two [INAUDIBLE] two copies instead of one. PROFESSOR: Yeah. That's exactly right. That's exactly right. So yeah, if the
attacker can somehow-- like a network
attacker, for example, is seeing these things go over
the wire-- and you're right. If there's enough wiggle
room in the expiration date, then they can exactly
do that attack. That's right. OK. So that is an overview of how
these stateless cookies work. And so one question
that's interesting is you might think, well,
what does it mean to log out with this type of cookie? And the answer is that
you don't really log out. I mean, you have this key. And so whenever you want to send
a request, you just send it. You include this
dude right here, and then you're ready to go. Now, one thing the server
could do, for example, though, is revoke your key. So the server revokes your key. Then you can generate
one of these things. But when you send the
message over there, the server's going to say, aha,
I know what your user ID is. You've been revoked, so I'm not
going to honor your request. But it's a little
bit interesting. And revocation, as we'll
talk more about with things like SSL, is always a tricky
issue, because as it turns out, taking authority
away from human users is often much more difficult
than giving it to them in the first place. So that's the basic
idea behind these sort of stateless cookies. So there's also a
couple other things that you can use if
you want to avoid traditional cookies for
implementing authentication. So one thing you
can imagine doing is actually using DOM storage to
hold client-side authentication information. This says "alternatives" in case
you couldn't [? read that. ?] So one thing you could
do is to use DOM storage to hold some of
that session state that you would ordinarily
put inside of a cookie. So if you remember
from last lecture, DOM storage is essentially
a key value interface that the browser
provides to each origin. So you can say GET and PUT
in both the key and eval [? strings. ?] So you could
imagine putting authentication stuff inside there. Now, the nice thing about this
is that DOM storage actually has much less wacky
rules with respect to the same origin policy. So if it were
cookies, you can do all these tricks with
subdomains and stuff like that. It got kind of weird. DOM storage is actually strictly
tied to a single origin. You can't do any of this
subdomain expansion, all that kind of stuff. And so frameworks like
Meteor use DOM storage for this very reason. But now, note that if you
want to store authentication information in DOM
storage, then you have to write JavaScript code
yourself to actually pass that authentication
information to the server to do the [? encryption ?]
that's necessary and so on and so forth. So that's one
thing you could do. Another thing you
could do is actually use client-side certificates. So for example, like
an x.509 format. And so what's nice
about these certificates is that, basically, JavaScript
has no explicit interface to access these things. So unlike cookies, where
there's always this arms race to find these weird
same-origin bugs, there's no explicit JavaScript
interface for that stuff. So that's very nice from
a security perspective. One problem that I
mentioned very briefly that we'll look at in more
detail in later lectures is that the
revocation [? store ?] is kind of hard for these. So once a user leaves
your organization, how do you take back
their certificates? And it becomes a
little bit tricky. Also, these things don't
have great usability, because who wants to install
a bunch of certificates for each site that you go to? So as a result, these things
have a lot of friction, and these are not super
popular except for in companies or organizations that are
super security-conscious. All right. So that concludes our
discussion of cookies. And so now let's talk about
protocol vulnerabilities in the web stack. And so one kind of
interesting attack is that there are all
these bugs in the way that different browser
components parse URLs, for example. So how can URL parsing
get us into trouble? So suppose that we have a
URL that looks like this. HTTP comes from example.com. And then it's got an explicit
port specifies that it's 80. And then for some
unknown reason, it embeds this @ character here. So the question is,
well, what is the origin of this particular URL? So as it turns
out, so Flash would say that the host name portion
of this was example.com. However, when the
browser would parse this, it would say that the host
name part of the origin was actually foo.com. So this is clearly a bad
thing, because once you have two different
entities who are confused about the origin of
the same resource, then you can get into all
kinds of nasty problems. So for example,
the Flash code can be malicious, can download
stuff from example.com. If it was embedded in
the page from foo.com, it could then do some
evil things there. And it takes some
code from example.com and run it with the
authority of foo.com. So there's a lot of
complex parsing rules like that that make
life very difficult. This is a continuing theme. Like, as we just saw with
the content sanitization-- so the basic idea that
it's oftentimes much better to have simpler parsing
rules for this kind of stuff. It's difficult to do
that in retrospect, though, because HTML's
already out there. So all aboard the wam-bulance. So this next one,
this is actually my all-time favorite
security vulnerability. So it basically attacks
the way that the browser [? rule 1 ?] JAR files,
basically Java applets. So in 2007, I
think-- yeah, 2007. So lifehacker.com--
great website if you haven't been to it. Lifehacker.com
basically explains how you can embed ZIP
files inside of images. Now, it's not quite
clear who you're trying to hide from by doing this. But Lifehacker says you
can do it, so hurray. So basically, what they take
advantage of is the fact that if you look at image
formats like GIF, for example, typically, the way the
parser works is the parser works from the top, down. So it finds information
in the header. And then it sort of computes
on the rest of the bits here. Now, what was interesting
is that, as it turns out, programs which manipulate
ZIP files typically work from the bottom up. So they find some information
in the footer of the file. Then they work up to try to
extract what's inside of it. So what Lifehacker
basically said is that if you wanted to
hide a ZIP file on a merger or something like this, then you
could actually post a GIF there that has this ZIP file here. It will pass all the validation
checks on Flickr or whatever as an image. It will actually display as
an image in your browser. Aha, but only you
know the hidden truth, that if you take this file
here, you can pass it to unzip, and it will unzip [INAUDIBLE]
information there. OK, fine, this seems like it's
sort of like a cheap parlor trick. OK, that's nice. Now, attackers, of
course, never sleep, and they want to ruin our life. So what did they realize? They realize that JAR files
are basically derivatives of the .ZIP format. So this meant that
you could actually create a GIF or
an image that had a JAR file, executable
JavaScript code, at the bottom of it. So then people
called this attack-- they called it the GIFAR attack. [LAUGHTER] Half GIF, half JAR, all evil. Because this was amazing. And so what did this
mean that you could do? Well, it's actually
quite subtle. Because people first
discovered this, they thought it was amazing,
but they didn't quite know how to exploit it. But as it turns out, you can
do things like the following. So first of all, how do you
make one of these things? You just use CAD. There is literally
no [? trickeration ?] that you have to do. Take this, take
this, you CAD it. Boom, you've got a GIF/JAR. So once you have
that, what can you do? Well, there are
some sensitive sites that will allow
users to submit data, but not arbitrary types of data. So [INAUDIBLE]
Flickr or something like that, it may not allow
you to submit arbitrary ActiveX or whatever, arbitrary HTML. But it will allow
you to submit images. So what you could do is
construct one of these things, submit it to one of these
sensitive sites that does allow you to submit images. And then what can you do? Well, the next thing you
need to do is-- so yes, the first thing you do is you
submit one of these things to the sensitive [? cycle. ?] And then the next
thing that you can do is if you have an
XSS attack, if you have a cross-site
vulnerability, then you can use the cross-site
scripting to inject something like this. And due to poor
board management, I will draw this over here. So you can inject an applet,
write JavaScript code that has, as its sort of source,
you just say, cats.gif. And so what's
interesting about this is that this code, because we're
using a cross-site scripting vulnerability, runs in the
context of the vulnerable site. This has been uploaded to
the vulnerable site's origin. So this will pass
the same origin test. But however, this code was
specified by the attacker. So now what happens
is that the attacker gets to run that Java applet
in the context of the victim's site with all the
authority of that origin even though the GIFAR passed
the vulnerable site's image validation code. Because one of these
things will actually parse correctly as a GIF. But it has this
hidden code in here. And so [INAUDIBLE]
when the browser tries to execute the JAR
part of it, once again, it starts from the
bottom, comes up here, and just ignores that part. So this is actually
pretty amazing. And so there's some fairly
straightforward ways you can fix something like this. So for example, you can actually
have the applet loader actually understand that there should
not be random junk up here, for example. What was happening in many cases
is that there was information in the metadata saying, here's
the length of this resource. And then if it said, the
length, it stops here, they would just say, who
cares what's the rest. It's probably zero. But in this case, it wasn't. What I love about
this is that it really shows how wide the software
stack is for the web. So sort of taking these two
formats, GIF and then JAR, we can actually create
this really nasty attack. You can actually do
this for PDFs, too. You can put PDFs here. I think that was called,
like, the [? PDFR ?] attack or something like this. So people had a field
day with this for a day. These vulnerabilities
have been closed now. AUDIENCE: So what can
you do with this attack that you can't do
with [INAUDIBLE] XSS or your own [INAUDIBLE]? PROFESSOR: So what's
nice-- yeah, yeah. So good question. So what's nice about this
is that Java oftentimes can be more powerful than just
running regular JavaScript, because it has slightly
different rules on, [? same origin ?] policy
and stuff like that. [INAUDIBLE] get more
lower-level access to the file systems
or things like that. But you're right, that if you
can do cross-site scripting, running JavaScript's
already pretty damaging. But the main advantage
of this is, once again, running inside the applet. All right. Yeah. So like I said, that's my
favorite attack of all time, mainly just because it forced
serious-minded security individuals to say
GIFAR all the time. So if you're easily
amused, like myself, then this was a bonanza for you. So another thing
that's interesting is that there are
actually attacks that are based on a time. So you might not think of
time as a resource which could be a vector for attacks. But as I was discussing with
someone a few minutes ago, yeah, time can actually be a way
that a system can be exploited. And so these attacks are
called-- the particular attack I'm going to talk
to you about is a specific example of a
covert channel attack. And so the idea behind
the covert channel attack is that, essentially,
the attacker has found some way
for two applications to exchange information. And that exchange vector is
not an officially sanctioned vector. The attacker is somehow
leveraging some other part of the system to pass
bits of information between two different entities. So a good example of
some of this stuff is something called
CSS-based sniffing attacks. So what is this
attack all about? So attacker has a website
that the user can visit. And once again, getting
a user to visit a website is actually usually
pretty straightforward. You create ads. You send them a phishing
email, whatever. So the attacker has a
website that the user visits. And the goal of the
attacker is to learn what other websites
the user has visited. And the attacker might want to
know this for several reasons. Maybe they're trying to figure
out what kinds of search terms the user's looking for. Maybe they're
trying to figure out where that person's
employed, or maybe they want to know if they've
accessed some type of embarrassing material,
so on and so forth. So how is the
attacker going to do that if the only thing
that the attacker controls is a website that he or she
can convince the user to visit? Well, the exploit is to
leverage link colors. So you know like when
you go to a web page and you click on a link, the
next time you see that link, it is now a different color. So zoinks, that's actually
a security vulnerability. Because what that means is
that in this attacker website, if the attacker can trick
you into visiting it, then the attacker can generate
a huge list of candidate URLs that you might have
visited and then use JavaScript to see
what color those URLs are. And if the URL color
is purple, that means, aha, you have visited that site. So this was very subtle. And what's
interesting about this is that you don't even have to
display the URLs in many cases to the user. You can just sort of
conjure up a domino that has a particular href and
just look at its style, and then see if it has
the visited color or not. So this is actually
pretty subtle. So you might be
thinking, well, isn't it going to be inefficient
to scan through all these candidate URLs? We can do all kinds of
clever optimizations. So for example, you can
have multiple passes. In your first pass,
you could only see if the user had
visited top-level URLs-- cnn.com, Facebook.com,
so on and so forth. If the answer is
yes, you can then do sort of a depth-first
search on those hits that you found at the top level. So you can actually
really constrain the search space this way. So this was really,
really funny, too, if you have a demented
sense of humor, because it showed that
this very innocuous feature that browsers support-- they're
just trying to help you out. They're trying to
say, hey, buddy, here's where you visited. It can actually reveal this
very damaging information. So what is a solution for this? So in practice, what the
browser [? runners ?] did is that they made it such that
the browser lies to JavaScript about the color of links. So basically, when JavaScript
tries to look at the link and look at its styling, the
browser always says, unvisited. OK. So that seems
somewhat unfortunate, but it prevents this attack. So I guess we can live with it. JavaScript not being able
to read link colors, eh, not the end of the world. So are we done, though? Does this fix the
problem of the attacker being able to figure
out where you've been? The answer, of course, is no. So the next attack that
the attacker can do is a cache-based attack. And so the intuition here is
that, once again, the goals are the same. Attacker wants to know
what sites you visited. The exploit vector
is that information that has been cached
is quicker to access. That, in fact, is the whole
reason why you cache it in the first place. So once again, the
attacker can generate a list of candidate objects
that the attacker thinks you might have visited
and then just time how quickly those objects
come back to the attacker. And so if the objects
come back quickly, you know [? you need some ?]
threshold, the attacker can guess
that you, in fact, have been to those objects before. So does that make sense? Once again, the browser's
just trying to help you out. But you can leverage these
techniques to figure out some evil knowledge. And what's
interesting about this is that this attack
can actually leverage some very interesting
geographic location information. So imagine that we're doing
attacks on Google Map tiles, for example. So if I detect that
you've actually accessed a series
of Google Map tiles, that probably means you
are either in that place or you're interested
in other people who might be in that place. So it's actually a
pretty powerful attack. So OK. So how can you fix this one? Well, this one is
not quite clear. You could have a site that
doesn't cache anything at all. And then your site's
going to be slow. So that kind of sucks. So it's not quite clear
how you get around this. But OK. Let's suppose that we have the
defense we put in place here-- JavaScript can't
read link colors. Let's assume that
the site is super paranoid it caches nothing. So have we completely defended
ourselves against this attack? One second. So the answer is no. Because the attacker can
actually launch DNS-based attacks. So the intuition is that even if
you don't cache anything, when you access a resource
for the first time, you have to generate a DNS
request for the hosting that's associated with that resource. So once again, the
attacker can look in time and see how long it
takes for the attacker to access these candidate
objects the attacker thinks you may have accessed. And if they come back
quickly, then that's perhaps a good hint that
you've resulted the DNS name for that host before. And so this works even if
you don't cache anything, because the DNS cache lives with
the OS, not with the browser. AUDIENCE: You've mentioned, I
think last class, the ability to get JavaScript
to take screenshots. PROFESSOR: Yeah, yeah. AUDIENCE: So can you just
render the [? link ?] as a single pixel, and
then take a screenshot, and [INAUDIBLE] that pixel? PROFESSOR: Yeah. Well-- so you could. So rendering stuff is
always a little bit tricky, because you have to
play these games. If you want to show
something to the user, it has to flash really quickly. Or else they might see
that someone's entering this huge list of URLs. But you're right. If you have access to
the screen-sharing API, a lot of this becomes
a lot simpler. AUDIENCE: And if you just have
some kind of animated image that looks mostly
random, then you just pay attention to
one pixel of it? PROFESSOR: You're exactly right. I mean, in general, I think
the screen-sharing API is a bad idea. I'm not the president of
the world, so what can I do? So anyways, so DNS-based
attacks work even if there is no caching that takes place. OK. So as the final
piece de resistance, so you might think, OK, what
if we only use raw IP addresses for all of our host names? We don't cache a thing! OK? And we're running on an updated
browser that doesn't expose link colors to JavaScript. So surely we're fine. I'm here to tell you
you are not fine. Because what the
attacker can actually do is take advantage of
rendering attacks. So the basic idea here is
that it is typically faster to render a URL that
you have visited before for various
wacky reasons that have to deal with how
browsers [INAUDIBLE] rendering [INAUDIBLE] internal. And so what the attacker
can do is actually create a candidate iframe, let's
say, puts some content in there that the attacker thinks you
may have visited, and then constantly see if the attacker
loses access to that iframe. Because as that
iframe is loading, the browser typically
thinks that iframe belongs to the attacker's page. And then as soon as that
different origin content comes in, then you'll start
getting these access errors. Because now that different
origin [INAUDIBLE]. So now the attacker
can't touch anymore. So the attacker can do
things like this still to see if there's caching,
rendering information [INAUDIBLE] browser for
these candidate sites. So anyways, so those are
the only hopes and dreams I want to crush in you today. I believe we're
running out of time. But I will see you next time.
