Reducing Complexity

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

[00:00:04]
>> Douglas: So one of the nice things about this model is it completely changes the economics of hacking. In most architectures, if you can confuse an object, basically, that gives you access to everything in the system. Whereas in this model, if you can confuse an object, you get the capabilities of that object but only that and in most cases-

[00:00:26]
>> Speaker 2: So is a confusing objects?
>> Douglas: Yeah. The object is not created correctly and you can cause it to do something that it's not supposed to do.
>> Speaker 2: Okay.
>> Douglas: You might be able to get control of what that object can do but you don't get control of everything that the system can do.

[00:00:42]
So we changed the economics of hacking, there's a really nice talk on YouTube about this stuff, The Lazy Programmer's Guide to Secure Computing by Mark Stiegler. Stiegler's premise is that the best programmers are lazy but they're lazy in a way which avoids future work. And if you take that approach that you tend to lead yourself to secure systems as well.

[00:01:10]
>> Douglas: So this morning we did this exercise where we've found this leakage because of the unexpected thing that this does which compromised our security. So we need to understand for this stuff, we need to plan for it, we need to improve the language, we need to improve our understanding of the language so that we're not compromised by it.

[00:01:34]
That attack is an example of a confusion attack, and that's why I hate confusion so much because confusion is what causes our systems to fail. Confusion aids the enemy. Bugs are a manifestation of confusion but also security exploits are manifestation of confusion and usually attackers get to take over a systems when their understanding of our systems are better than ours.

[00:02:00]
And unfortunately, that tends to happen a lot and the way we stop that is by getting a better understanding of our own systems and we do that by eliminating is many sources of confusion as possible. I have no tolerance for confusion, I want to eliminate as much confusion as I can.

[00:02:18]
>> Speaker 3: Confusion attack is when you don't understand how [INAUDIBLE] it works.
>> Douglas: We think the system works in a particular way and the attacker by studying those figures out that's not how we work and he's able to exploit that. In fact, virtually all security exploits are like that, that we never intentionally go public and then into production with code that we know has security vulnerabilities in it and yet everything that's ever been deployed has security vulnerabilities in it and it's because we're confused about how our own systems work.

[00:02:54]
We need to stop doing that. So with great complexity comes great confusion. So that's why I'm minimalist, I want to find the simplest solution in all cases because those are the things that are easiest to reason about. So we should keep everything as simple as we can. We should keep our code bases as clean as we can.

[00:03:14]
If we allow our code bases to get crufty then they become harder to understand more likely to be confusing and will get exploited. So we should always code well. Good code is ultimately cheaper to produce than bad code. So we should always make good code. Good code is easier to reason about.

[00:03:32]
Code that is difficult to reason about is more likely to be problematic and we should have strict conformance to good style rules. Which means that if we're writing in JavaScript everything should pass JSLint without exceptions. We should not put anything out on the web which is not at least that good.

[00:03:52]
You should never trust a machine that is not under your absolute control and then I'm not even sure about all of those. But one thing for sure, you must never trust the browser. It cannot and will not protect your interests. You need to properly filter and validate all inputs that you get from the browser, need to properly encode everything that you send to the browser, the context of that encoding and decoding and filtering is critical.

[00:04:19]
You need to filter and code for the correct context. So let me tell you what I mean about trusting the browser. So this is a true story, a few years ago, a friend of mine was going to go visit China. So he bought a ticket on a famous airline and it's an expensive flight so he bought a coach ticket.

[00:04:39]
And then, he realized, wow, it's a really long flight, it's really uncomfortable, it be much nicer to upgrade to first class. And so, he went to the website of the airline, and look to see if upgrades were available. And they were, but you needed a certain number of upgrade certificates, and it told him his number was zero, because he doesn't fly all that often.

[00:04:59]
So he was very disappointed until he opened the debugger.
>> Speaker 2: [LAUGH]
>> Douglas: He found the variable that contained his number of certificates. And he flew first class to China.
>> Douglas: It's a true story.
>> Douglas: The reason that worked was, the guys who designed that system assumed that there is a certain URL that could only be generated if a certain set of conditions were true, and they were relying on the browser to guarantee that.

[00:05:30]
And the browser will not guarantee that, you cannot trust the browser. Another browser story. In the first days as an e-commerce when online stores first started happening, they didn't understand yet how to scale web systems. Right. They tried to do all of the work in one server and very quickly the data, and amount of traffic was bigger than one box could handle, and they were panic.

[00:05:53]
About the same time JavaScript comes online and they go, great, we can now offload all this processing onto the browser. So they now have the browser do all the work of preparing the invoice and totalling everything up. They just allow the browser to then submit this thing which then gets sent directly to fulfillment.

[00:06:13]
>> Douglas: So if you can figure out how to type a URL, you can order anything you want and pay whatever you think is reasonable.
>> Speaker 2: [LAUGH]
>> Douglas: So it turns out there are good reasons to do stuff in the browser, most of them are to provide a better user experience.

[00:06:33]
So you can avoid the thing where the user fills in a form and then you kick it back in their teeth because they got something wrong, we can help them do that and make it pleasant. But that doesn't mean that the server shouldn't check every detail of it and make sure that it happened right, you have to do that.

[00:06:52]
So templating is this process, we'll talk more about templating this afternoon, I hate templating, because the browser is a gun pointed at your head and templating is what pulls the trigger.