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
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?
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]