Security and the Browser

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Douglas Crockford: So that brings us to the browser. So the browser platform is horribly insecure, we're still fixing it later after over 20 years. HTML5 made things worse instead of better by providing powerful new capabilities to the attacker without mitigating any of the preexisting weaknesses. And yet it is still the world's best application delivery system.

[00:00:26]
It is better than everything else including systems that were designed after the Web. Everybody refused to learn the Web's lessons. So one of the things that the Web got right, that virtually every other platform has gotten wrong is the web does not have a blame the victim security model.

[00:00:44]
A very common thing in systems is, that if a system has to make a decision about security and does not have enough information to make a correct decision, it will ask the user. And it will ask the user in language that the user cannot understand. And if the user says no, then it fails.

[00:01:04]
And if the user says yes, it is the users fault for giving up their security. This is not a valid model of security but we see it all the time. For example, I recently bought an alarm clock at the Android store. And it was only after I bought it, that I looked at the permissions.

[00:01:22]
And one of the permissions it wanted was unlimited access to the internet. [INAUDIBLE] Wait a minute, why does a clock need unlimited access to the internet? And my choices are now, to let my clock leak everything it can find in my device and send it who knows where.

[00:01:38]
Or I'm out the money I spent on the clock, and it's just, that's not a good model of security. So the thing that the browser got right, that everything else got wrong was the answer to this question. Whose interest does the program represent? From the beginning of computing it is always been assumed that a program represents the owner of the machine or at least the owner of the account.

[00:02:05]
And the browser says no, the program represents a site and a site does not necessarily represent the user. Which was absolutely right. And nobody else has figured that out. Unfortunately the web got a lot of other things wrong. The web didn't anticipate that there could be more interests involved in a page than just the user and the site.

[00:02:31]
And that a malicious party can exploit coding conventions to inject malicious code. And that malicious code gets all of the rights of the site. This is known as the XSS problem. We'll talk more about XSS in a minute. But to ground this, I mean, you're always hearing people whining about security and how terrible all the problems are.

[00:02:49]
Let's get really specific. In this XSS attack, what can actually go wrong? What can an attacker do, if he can get some script onto your page? The attacker can request additional scripts from any server in the world. Once it gets a foothold, and it only needs about that much text in order to do that, it can then obtain all of the scripts it wants.

[00:03:14]
Browsers have a security policy called the same origin policy which limit the ability of the browser to get data from other servers but there is no limit at all on how much program you can load from the most evil server in the world. An attacker can read the document.

[00:03:32]
The attacker can see everything the user can see, and even things the user can't see. The attacker can see comments and hidden fields, cookies, everything we transmit to the browser, the attacker gets access to. The attacker can make requests of your server and your server cannot detect that the request did not originate with your application.

[00:03:54]
If you're using SSL, and you should, the attacker gets access to your secure connection. If your server accepts SQL queries then the attacker gets access to your database. Now if instead your server is constructing SQL queries based on information that it gets from the browser, then you're only probably giving access, to the attacker to your database and that's because SQL was optimized for SQL injection attacks.

[00:04:26]
>> Speaker 2: [LAUGH]
>> Douglas Crockford: Thank you. [LAUGH] An attacker has control over the display and can request information from the user and the user cannot detect that the request did not originate with your application. So modern browsers have anti-phishing chrome. And unfortunately most users don't pay any attention to that.

[00:04:49]
But if they are paying attention to it, in this case, the browser is saying, it's good, because all the browser's concerned with is where did the HTML come from. The browser doesn't pay any attention to where did the script come from. And the script could have come from anywhere, and the script is what's gonna cause the damage, not the HTML.

[00:05:08]
So knowing this on some sites, whenever something dangerous is about to happen, they will ask the user to type their password again. And the theory is that only the user will know the password. And that way, we can be confident that this is not going on. Except that the attacker has control of the display.

[00:05:25]
And so the attacker can ask the user, what's your password? And the browser was saying, good tell him. So if If you're operating one of these sites which asks people to re-identify themselves at unlikely times, what you're actually doing is training your users to give up their passwords the instant the attacker gets control.

[00:05:48]
>> Douglas Crockford: Then the attacker can send information to servers anywhere in the world. Everything that they learned by scraping the page, by talking to the user, by querying your database, they can then send this to the most evil server on the planet. Again, the browser has a same origin policy which limits their ability to receive data from other servers but it puts no limit on their ability to send all of these stolen information.

[00:06:16]
So, and the browser, is this starting to freak anybody out? Because why are we doing business on this platform? Is that anyone-
>> Speaker 3: [INAUDIBLE] I just kind of what's in the world course. Takes care of all this for us right?
>> Douglas Crockford: No, no, nobody's taking it.
>> Speaker 3: I'm really waiting for you to explain to me, I don't know.

[00:06:37]
Where, I wanna know what I'm doing.
>> Douglas Crockford: I think I'm making it clear. Anyway but the browser does not prevent any of these. Web standards require these weaknesses. If you were to build a new web browser from scratch. If it didn't subject you and your customers to all of these potential problems, it would not be standards compliant.

[00:07:03]
And the consequences of a successful attack are horrible, there's harm to customers or loss of trust, there are legal liabilities. There's even talk now about criminal liabilities for negligence, for allowing people to have their identity stolen.