Secure by Default

[00:00:00]
>> So what I wanna do now is I want to cover some of the things that Ryan talked about in this video that inform the way that DENO is different from what you might be used to. So the first concept that is really key to DENO is this idea of being secure by default.

[00:00:22]
When I hear things like this, to be honest with you, it comes off to me as paranoid, and frankly, not a great reason to write an entirely new runtime. But I would agree in so much as saying that Node is not a secure runtime environment. But I would say that neither are a lot of runtime environments.

[00:00:45]
I don't believe that C sharp or Java are secure either. And what I mean by that is that when you're running these things on your local machine, they have all the rights that you do. They have all the access that you do. If you have write access to a file, so does Node.

[00:00:59]
And most of us as developers, we either have root access or we have admin access, it's just kind of something that we need on our own machines. And even if we didn't, it would be fairly easy for bad NPM packages to do nasty damage to our machines, or worse yet, to our production environments, if we actually deployed those things.

[00:01:23]
The browser by contrast is not like this. The browser is a secure sandbox, your machine is protected from the browser. It cannot do anything to your machine without your permission to do that, it needs permission to access your microphone. It needs permission to access your camera. It needs permission to do access to file system, which is supported somewhat in Chrome not everywhere.

[00:01:46]
Your phone is like this as well, if you think about it, when you install a new app on your phone, what does it do? It asks you what for access to your photos, access to your contacts, access to to send you notifications. These environments are secure by default, and you have to opt out of the security in order for them to work.

[00:02:08]
But let's look at how this actually plays out in Node. So in Node here, I've got this block of code that I wrote that's not terribly concise, but we'll talk about what it does here in a second. But Node has an FS module in it. So I'm gonna switch over here to our secure-by-default branch.

[00:02:27]
And this module allows you to interact with the file system. And so what this code is doing here, we'll just sort of walk through it. Is first thing it does is it runs this findEnvFiles, which basically goes through recursively and searches for any file on your machine that has a .env extension in it.

[00:02:51]
And if you've worked with projects before, you know that a lot of times we put secret keys in .env files and then we don't check those into source control. They're only meant to be used locally. And then what it does is it just goes over each of those and logs it out to the console.

[00:03:06]
So if we were to run this, I'm just gonna run this and say, node. Let me make sure I'm in the right directory, I'm not. So let's do. Actually, I'm still in my remote container. Let me be bounce back over to want to run it locally. [SOUND] There we go.

[00:03:34]
So now I'm just back on my local machine. And you'll notice that I'm using something called the WSL here on Windows, which is why I have what looks like a Linux command line. So let's move into the exercise directory and let's just run this. And what will happen is it's going to search the current directory here.

[00:03:54]
It's going to look for any files that have .env extension and then it's going to shell out the answer here to the terminal. So there you can see some of my private keys. Okay, so this is a real problem. Because this code has now access files that I didn't mean for it to access, and it can just read anything on my machine.

[00:04:15]
There's lots of sensitive data on my machine. So this just goes to show how easy it is to do that. But this is not a shock. We know that Node does this. Why is this a problem? Even if this code exists, how do I get you to run it?

[00:04:33]
You're not going to run this code, you know better than that. You're a developer, you know better than to trust a package or code that looks nefarious. So how do I get you to run this? The open source world is a wonderful place in which nobody would ever take advantage of you.

[00:04:51]
Well, actually, that's mostly true, that's mostly true. But there are a small number of people that would like to exploit that. And anyone can publish a package to NPM. There's not a review that happens on NPM. If you publish a package, it's immediately available for anybody else to consume.

[00:05:10]
So we can take that code that I just wrote and publish as an NPM package. Anybody who runs it, we could get their environment variables and copy them. But again, how do I get you to install and run this module. You are not gonna go install and run this module, so how do I do that?

[00:05:30]
There is a really good talk called how to hack a Node app by a co-worker of mine, Asim Hussain. Who details the extent to which the Node ecosystem is routinely used to hack, hijack, and otherwise exploit people and execute malicious code. It happens all the time. In his talk, he goes over a bunch of different ways that this happens.

[00:05:58]
But the most common way that this happens is so simple that it's almost just disappointing how simple it is. So there's something called typo squatting and you may have heard of this before. Typo squatting is when a package names itself something similar to a legitimate module. So in his talk Asim gives this example of a package called Cross Env.

[00:06:22]
And Cross Env is used in a lot of places. It was written by Kent Dodds, I believe. And it's a phenomenally useful package. And what it does is it normalizes the way that we pass in variables, command line variables to Node so that NPM start scripts work across environments, Windows, Mac, Linux.

[00:06:42]
It's extremely useful. But someone figured out that people commonly tried to install cross-env instead of Cross Env. And so they created a package called cross-env and they published it and sure enough people started using it and that package reads your Env files, you know where all your secrets are and then sends them off to a remote server.

[00:07:10]
Which is the exact same thing that the code that I just wrote does. That's how easy it is to get people to execute malicious code. While I was preparing for this course I just happened to come across this article from ZDNet, where this is like three weeks ago where it says three NPM packages found opening shells.

[00:07:31]
And then NPM responding and saying, any computer that has this package installed or running should be considered fully compromised, your entire system is fully compromised. I mean, that's just heavy and this can happen to anyone, it can happen to anyone. And if you read the article, it says that even if you remove those packages, that your system is still not safe because who knows what those packages did in the background, who knows what they ran and installed.

[00:08:03]
So Node when he says that it's not a safe runtime, it just simply isn't. It's wide open and it's based on a wide open package system. There's sort of a trade off between convenience and security. The fact that the package system is wide open makes it extremely convenient to use, but it also makes it insecure.

[00:08:24]
And Node is optimized for convenience. DENO is optimized for security. Which means that by default programs have no access to your file system. They cannot read any files. They cannot make any HTTP requests. They can't even read environment variables that you pass in. You have to explicitly grant DENO access to do those things.

[00:08:49]
Now, this doesn't make DENO perfectly safe and it doesn't make you perfectly safe. What it does is it puts you in a position of safety, and then it asks you to explicitly opt out of that in order to make things work. And that's secured by default. It's just a different way of thinking about how secure systems should be built and what a secure runtime looks like.