Hello and welcome to secure JavaScript programming with Vladimir de Turckheim. This is a bit of a special video because this one is not aimed at giving you hints on how to build cipher applications, but give you hint at how to protect yourself, your identity, your desktop or laptop machine. As a web developer, you are under attack. You are under attack when you download dependencies from the network. Even if you are using Deno, the security flags won't protect you if you build a web application because for instance, if you are building a web application, you probably need a low net flag and probably the [inaudible] system flag because you have a building toolchain located to build your app. They've done that, they can still do pretty much what they want on your system, on to network. You are under attack and Deno won't save you. It's not about not being vulnerable to injections in modules of two attacks in modules. That's the same in Python, that's the same in Ruby, that's the same in Go, that's the same in Roost. All people write code on their machines, debug it, build web applications, and use modules from the Internet, are under attack. I will show you a few hints on what to do when you're not sure where you're going. First thing, we talked about malicious dependencies. There is actually one good way that is pretty straightforward. If you are used to do web programming, you should be used to doing that, is to use a Docker file. Just do a Docker file is from node 14, WORKDIR/app, copy the dots. Of course you don't want to do that. You want to read a page on how to do a docker file with NodeJS and NodeJS.org. But if you get sources from a repo you don't trust, meaning that it's just a random repo from the Internet from GitHub. Just actually run it first in a Docker and understand what happens. That's the first thing to do. Also, when you install it, run npm audit. Because npm audit knows about malicious modules and derivations. Same thing, feel free to install, SNYK, S-N-Y-K and do the same thing. They have a bigger database that's are dropped to find vulnerable and malicious modules. Next thing to take care about, is what happens when web server is running on your machine. Right now the web server is running on my machine. How do I know that nobody has access to it from another machine in the network? If is my cell phone is in the same Wi-Fi, does it have access to it? Probably doesn't mean much when you're at home. In COVID era, everyone is at home. But when you are in a public shared office, maybe when there are thousands of people on the same network, they can access your website on your local host machine. Or maybe when you are in MacDonalds and Starbucks and sharing your public Wi-Fi or in an airport or a plane. Well, they might have access to your public machine. There's only one way to prevent that, actually two. It's either to know on which interfaces or process is listening. In that case, you need to check the specification of the framework. For instance, by default, the framework for node fastify only listens on loopbacks interface. Meanings that you can't access by default server from another machine when it's running in fastify. That's why when you are using fastify in a Docker you made, you actually want to tell it to listen on all interface. You check the Dock and you give it the interface to listen on. Listen and then the interface. Another thing you can and must do depending on your system is to know about your firewall configuration. Your firewall will limit who has access to which port on your machine. By default on macOS, I won't show you because I have personal information, you've got a firewall, but that won't prevent these things on all port's. You can configure it or install an extra firewall. Samely, it's actually very dangerous to debug a process on your machine, whatever the technology you use. Here, I started the debugger. Of course, because I started it in the ID, it doesn't like it. Give me one sec up node minus minus inspect. Here, I can see my local instance. However, it has discovery network target, and no because someone could add all the IP addresses on the network and scan for the debugging WebSockets of Node.js. Because that's who Chrome and Node.js do remote debugging through a web socket in a specific protocol. When you have access to a process running Node.js remotely through the debugger, that's a good mode. You can actually require fs, exec, sync and echo, hello, doc.txt. I get an error because exec sync does not exist. That so you look like you're stupid hacker because you actually were thinking about child process instead of fs and document phase. Why not? Because I'm not in your shell. That's a demo effect. I want it to be scary. But you could use fs to write locally or you can run any arbitrary process. As you can see, the logs are actually displayed here for the error rebuilt. When you build a web application locally, you need to be worried about few things. Dependencies you don't trust. If the project is just something you got on GitHub, don't turn it on your machine directly. That can be vulnerable or malicious code. When you have your project running on your machine, there can be vulnerable code running on your machine. For instance, if you have seen the video about Node.js injection in this learning path, well, you would know that shell injection and secret injections are a real thing. You can obtain a shell injection from a secret injection under certain condition. Or you can access a file system and those are conditions. A lot of tool used to serve file locally for development purposes that are vulnerable to directory traversal. That's why when you run your machine, you want to make sure that the listening interface is only on localist and that your firewall present remote connections. Whilst again, when you are running the debugger, make sure that nobody can access it from the network. As a rule of thumb, don't develop on a public network. That's actually extremely dangerous. Don't npm install from a public network. When you are working in a company, there are usually a private and a public network; the private for employee and the public for guests. Don't develop connected to the guest networks. That's extremely dangerous. Nobody thinks about taking care of which way files are connected to when they developed. That's actually a critical part. Also, make sure that in your package log, every dependency is resolved through HTTPS. It used to be a vulnerability in yarn where it'll load resolving dependencies of our HTTP. It actually still walk when you have a local that show sever with that SSL enabled. It's extremely dangerous because someone listening on the network could actually give you malformed packages. Hopefully, the signature will protect you, but it's SHA-1, so sometimes it's not enough. Well, I hope you're not too terrified at the end of this video, I just wanted to show you a few things and a few ways to hack web developer. It's the time for that disclaimer. I told you that when you are on the same network as someone mallicious, and you're developing web applications, so someone mallicious can do a lot of harm. Don't be a terrible person. Don't try to attack your coworkers locally when they develop. That just not fair. That's actually a big hazard for your job. Thanks so much for watching this video. I hope you enjoyed it. Have a great day and take care of yourself.
