The Security Toolbox For Node

Alright, hey, everybody. My name is Milesha McGregor, and I'm a developer advocate at Conducto. So we make this really cool tool where you can debug your pipelines and do your deploys easier and all that good stuff. So make sure you check me and us out on Twitter. But today, I'm going to talk to you about a security toolbox you can build for all of your node applications. So since we've been virtual for so long, I always like to give an overview. That way, you know where you can kind of, you know, tune in, tune out, fast forward through the video later when you're going back through it.

But to get started, I'm going to jump off with just the OWASP top 10 vulnerabilities. We'll cover pretty much all of them and some of the packages and other tools and strategies you can use to secure your Node apps from these kinds of attacks. And then we'll talk about how you can handle your packages because as every JavaScript engineer knows, we use a package for just about everything. So you want to make sure that you're taking care of those. And we'll also talk a bit about managing your data. So we all know on the back end that we don't want other people or people that shouldn't have access to the data to actually be able to access the data. So we're going to talk about some different strategies that we can use to just make sure that, you know, nobody that got fired three months ago is going to come back and drop all the databases. And we'll talk some more about protecting your server from different attacks, like the ones that just shut down your server. I know the word for this, but I'm going to remember it much later than I should. And then we'll wrap up with just a few key takeaways and some things I hope you can just go back to work and implement as soon as you can.

So to get started, we're going to just jump into the OWASP top 10 vulnerabilities. So there's this node goat app that is just in existence and it'll walk you through all 10 of the vulnerabilities using this cool little node application. So if you want to see some live examples that have been developed by just some of the top security people in the world, go ahead and check out this node goat app. But one thing that you want to keep in mind with this OWASP top 10, these 10 vulnerabilities are present on, I believe it was 85% of all web apps online right now. So almost the whole internet is just vulnerable to some kind of attack. And that is the reason why I want to give you just some tools and stuff you can use to make sure you don't have one of those apps or that when you do encounter one you can clean it up and just make sure that it becomes less attack-friendly. So the first thing we're going to talk about is cross-site scripting. This is basically when somebody injects JavaScript into your app, and it makes the app redirect users to some other place, it steals cookies so that they can authenticate themselves as other users, or basically anywhere there is some kind of input field that they can type text into, they're able to execute some kind of JavaScript statement. So we want to make sure that some random person on the Internet isn't injecting or cross-site scripting something really crazy into our app, so we're going to prevent that. And to do that, start by validating all of your inputs. I know we already do that because form validation is everybody's favorite thing. But I just want to make sure that we're really all doing it. So validate those inputs, make sure any numeric fields are actually receiving numbers.

Make sure passwords have their certain security requirements, whether that's lowercase and capital letters, numbers, special characters, whatever you want it to be. But have some validation around these inputs to where a user cannot submit a form if it's not in the right format.

And then something else you can do to just help with that whole session hijacking thing with the cross-site scripting, encode all of the data that you send to your users. So we know that we need to encode data that they send to us, just so people on the Wi-Fi in the airport or Windows were a thing. But when you're on an open network, you know that you always encrypt data going to the server so that prying eyes don't get access to it. Make sure you're doing the same thing when you're sending data. So go ahead and encrypt everything.

Now we'll talk about the denial of service attacks. So this is that thing that I could not say in the intro for some reason. But a denial of service attack is pretty much when some malicious party gets access to your server and they send so many requests that it brings down the server for all of your actual users. This means that someone is sending enough requests that they are using up all of your cloud resources or all of your on-prem resources to the point where your app is basically unavailable. So you don't want the denial of service attacks to happen, especially when your app is something very critical to your users. So to prevent those, we really want to put checks in place to prevent looping and data creation. You don't want somebody to be able to submit a query to your back-end that infinitely adds fake users to your database. That's one of the ways that a denial of service attack can bring your entire application down. And again, validate all of those inputs. There's forums on pretty much every site nowadays, whether it's just getting your email or somehow convincing you to sign in with Google. Validate those inputs. They're around, so make sure you're doing that on the front-end and the back-end.

Now let's talk a little bit about the server-side injection attack. This is when an outside party can inject data as part of just a simple query. This happens when you're able to submit bad queries in forums. So basically, what's happening is somebody's typing in a SQL query where they should be typing in a new username. And now you have your database dropped and nobody knows why. Just because someone was able to actually submit this request to the backend and there weren't any type of checks in place to prevent that from happening. So to prevent that, one thing that you'll want to do is parse any user input. You know what kind of data you're expecting from the front end. You know what values should be stored in the database. You have a whole schema for this. So when you're getting this user input, just go ahead and parse it down into what actually needs to be present.

This will help pick out a lot of those weird things really fast. And it'll save you that extreme panic of having something added to your database without knowing who did it. I'm pretty sure you're catching on to this now, but keep validating all those inputs. Again, the front end is going to hopefully do some kind of validation just client side, but just in case there's a huge refactor and form validation gets left out, not like that's actually happened before, but just in case it does, have that validation in your node app.

So now let's get to the meat of what is JavaScript. So how do we handle our packages? One of those OWASP top tens has to do with using components that have known vulnerabilities. And I'm sure when you run NPM install or Yarn that you see those maybe handful of vulnerabilities, some of them might be high, a lot of them might be medium, but you just assume it's fine. Nothing's going to happen. And boom, you have a backdoor into your application that anybody who's interested actually knows about because likely this has already been patched and you just need to update your version number. So patches are actually routinely released, when someone's package gets attacked or they find a vulnerability in it, typically the maintainer or the maintainers will push a patch for that, detailing all of the vulnerabilities that were present in that version. That's why looking through the versions of your dependencies, if you have anything on GitHub, this is one of the ways that attackers can figure out just a weak spot in your application. They already know there's this whole write-up on why this version of this package is vulnerable. So make sure that whenever you're pushing a new version or you went through a huge refactor or something like that, just check your packages. Do a quick NPM audit. This will list everything that has a vulnerability. It will list anything that's out of date. So just run NPM audit, and then there's NPM Audit Fix, which will automatically update those packages for you. So not a whole lot of work to do on your part most of the time. Sometimes there are some weird version interdependencies, but NPM Audit Fix typically works on a lot of things. And then, just if you want to make sure that all of your packages are up to date, do NPM Outdated, and this will bring up a list of anything in your project that's just outdated. It'll show you which version number you're currently on and which one is the most current. These are just a few commands that you can run to just do a quick check for that dependency on components that have vulnerabilities.

And with your NPM packages, a lot of us publish things whether it's privately within our organization or if it's publicly for other developers to use. Make sure that your access to these NPM packages is actually considered. Use two-factor authentication. Use read-only tokens. This is a surprising way that people get access to parts of your app that you really don't want them to know about. You probably don't want an attacker to know about your custom-built authentication system. You just don't want them to see that source code because they'll know how to break it. But these are two ways that they do get easier access.

When you're just using the password, we know that passwords can be figured out. When you're using tokens that give read-write access, well, if they get access to that token, they have access to pretty much what they need. They could change the code for your custom authentication engine, and nobody would really know who did it.

But most of the time, these tokens are just used in your CICD pipelines, or maybe you have some kind of environment file that you use locally or in different environments. So when you know you're just using your npm package somewhere, you're not trying to publish changes with this token, just go ahead and use the read-only. It'll save you some time. It'll give you a little bit of extra comfort at night, and you'll know exactly who has the right access to your applications.

All right, now on to managing your data. Because data is really this vast mystical, I don't know, phenomenon in our world. But something you wanna do, before you put new data in your database, make sure that you have pre-sanitized these values. You don't want to add a SQL statement to your database. Just, you know what types you expect to be going into each column in your database. Make sure that the value matches that. There shouldn't be any numbers trying to get written to string columns or any emails getting saved to address fields. Just go through the extra check and make sure that this data matches what you're expecting.

And one of the ways that we do this in Node is just type your schema. Most ORMs that we use, like Mongoose or some of the other, I forget the one that comes with Postgres, but whatever. You know the exact types. You know the names of the values. You know everything you need to know to make it impossible to save a different type of data in your database. And you need just a quick package. Just use validator.js. This makes it super easy to add that validation to your Node apps without you having to make up your own validation functions. They have things for emails, phone numbers, passwords, all that good stuff. And requests and responses.

This is something that I think we should all definitely be aware of. Make sure that you're using Helmet.js for your headers. This adds a bunch of just different security settings to your headers that honestly I had never thought about until I used this library. But it basically helps with any course issues, it locks down the differences between git and POST requests and it just takes care of a lot of behind the scenes things that you don't necessarily think of while you're writing your code.

And then when it comes to handling user data, earlier I was talking about making sure everything was encrypted, well use Crypto.js.

This has SHA 256, it has the MD5, whichever thing tickles your fancy, Crypto.js has something that you can use to encrypt your data. And again, we do this because during those moments from the server to the client, anyone can intercept that response or that request. And that means if they intercept that, then they have access to whatever data it was we were sending or receiving. We don't want them to be able to easily see that. And that is why we encrypt things, even if they do get the request or the response, it doesn't matter. It will be encrypted so they won't be able to do anything with it.

And now we can talk about protecting your server because this is like your prize jewel next to the database. It guards it. So you want to make sure you have a strong guard. Use HTTPS. No, it's something that we know we should do, that we've been told to do, that we've been marked as unsafe websites if we don't, but it's still surprising how many people aren't using HTTPS. Just go ahead and use it.

And then do some rate limiting. This will help handle those DDoS attacks and anything else that could crash your server just by having some kind of looping in it. So one of the ways to do this is with the express rate limit package. And it just makes sure that only a certain number of requests are allowed through during a set amount of time. And then, to prevent cross-site request forgery, we don't want somebody using someone else's computer to send requests to our server. So to do that, you can just add csurfjs. And this protects your endpoints from this kind of attack.

So just to wrap up real quick here, few things I want you to take away. First off, use the tools that are out there. You don't have to make your own security toolbox. There are plenty of packages and libraries that do everything for you already. And then don't wait for a security breach to implement security. Go ahead and do things like install helmet.js for a really quick win. And then note itself makes it pretty easy to handle the main threats. There's just a lot of different packages. And once you're using Express, you know how many methods and parameters you have available for that. And lastly, look at some of the tools that attackers are using. They're online. A lot of them are open source. And there's no reason to not know what you're defending against if you're interested. One thing in particular I recommend is the Kali Linux OS. It comes with a bunch of attacker tools just pre-installed. So take a look at that if you're really, really interested in hacking. But that's all I have for you today.

Thanks for sticking around and I'll be here for questions. Good to have you again. So what do you think about this result? Security implementation, that is the hardest thing about backend development. Do you agree? Is it what you expected? I think it is probably one of the hardest parts is just making sure that no weird people or attackers just get access to your data or manipulate your system in some kind of way that you don't want them to. But something else that I think is a hard problem is multi-tenancy. So that's just, I don't know, it's just a big problem.

Yeah, I agree. Well, first off we have a comment from one of our visitors, Marsau001. He says, love this talk so much about my favorite topic cybersecurity. So some love from Marsau001. Thank you. We have a question, or I have a question. Where can I go to get more info about different web vulnerabilities? So what are some good resources? The biggest one is definitely the OWASP top 10 site. They have this really good tool. I think it's like OWASPnode, node goat, that's what it's called. And it's pretty much just this app that's set up to show you what it looks like when a node app has certain vulnerabilities. And they have one example for, I think all of the top 10. Nice. Node goat. So can you share the link after the Q and A in the Discord channel, so people can find this. Awesome.

Another question, are there times where security should just be handled in the front end or should it always be handled in the back end? Of course, there's stuff that can be done on the front end. You know, form validation is important, making sure that you have user permissions and stuff locked down. But the front end should never be the only source of security. So most things should be happening on the back end, most, if not everything, should be happening on the back end. Yeah, so you mentioned, like, form validation. Do you usually do it double, so front end and back end then? Yeah, that doesn't hurt at all. Like, just having that data cleaned before it goes to the back end saves, you know, a little bit of time. Maybe it boosts performance that tiny bit, so if you do get 800,000 requests in a minute, it doesn't add up to be a huge problem. Yeah, exactly.

And, yeah, like you said, it can, like, the faster feedback is also great for user experience, but yeah, the front end can be manipulated by people like you and me. So, yeah, it's good to also check something on the back end.

I see Juliana smiling, and me. Next question is from Fried Zoidberg. We can talk. Do you have any other examples of tools that attackers might be using? And he's already taken a peek at Kali Linux. Some other tools that attackers might be using, I know a few of them that I'm personally familiar with would be Wireshark, and that's just to pick up any requests or data that's being sent across a network. Then there's, I think, I don't remember the name of a lot of them because they're all just bundled in that Kali Linux OS, but Wireshark is probably, I don't know, it's my favorite one to use. You'd be surprised what people access on public Wi-Fi networks.

Okay, cool. Maybe also a good idea to add that to your shared links in the discord after. Next question is from Juan Gonzalez. What are your thoughts related to security between Node and Deno? Ooh, that's a good question. Unfortunately, I haven't gotten the chance to work with Deno much, so I don't have a good comparison. Hmm. Okay, so hopefully there's a Deno expert in our audience that can help Juan with his question.

Next question is from, well, I don't know how to pronounce this, 1-L-V-4-N. It's a handle, not a name. Great job. Any particular security concerns that we should take into account when you're using Node in combination with Docker? Hmm. I think as long as you have those top 10 covered, you'll be good whether it's in Docker or not, but something you might wanna check is just who has access to the different containers that you spin up? Like, are those containers somewhere in your cloud? Are they on-prem? Do you have the password that isn't just admin or 1-2-3-Q-W-E? It's just making those precautions helps a lot. But I don't think there's anything special that you have to consider with Node and Docker. Mm-hmm, cool.

Next question is from Koniki. Are there tools to prevent attacks from different IPS? So proxy or Tor? Hmm. Um, of course you can like blacklist different IPs, but the main thing is just making sure you have it like your Node app set up to where it's not susceptible to DDoS attacks. So if you do the rate limiting to make sure people aren't trying to spam requests to your server all the time. If you put different delays on requests just something to make it so if a person is using a VPN or a cluster of VPNs, it doesn't matter how much they try to attack, they aren't able to get through like they're trying to. That's already blocked on that platform. Well, that's smart. I hope Konniki agrees. And if not, then he or she is able to join you in your speaker room to discuss this further. That is for now on the questions. Oh, I see people are already sharing the links that I'm asking for. So you're off the hook. A wire shark and a Node.js goat is shared already. So thanks a lot people for sharing these links already with the community. That's all the questions we have at this moment. So I will relieve you of your duty for now and invite people that want to ask you more to go to your speaker room. All right. It's been a pleasure having you, Melissa. Thanks for joining. Yeah, thanks for having me.