What is a Vulnerability and What’s Not? Making Sense of Node.js and Express Threat Models

Hola, I'm Ulisses Gascon, and in this talk we are going to discuss a lot about security. We are going to go deeply about understanding what is a vulnerability and what is not, while you are using your most loved tools like Node.js or Express, right?

So basically who I am. I am a software engineer at NodeSource. I'm also part of the core team of Yeoman, Node.js, and Express, and I'm trying to help in the ecosystem a lot about security. I'm participating in a lot of collab spaces and working groups and so on. And the idea today is discussing about what is a vulnerability and not, and how you can improve your own security overall.

So basically, what is a vulnerability? In very simple terms, and if we use the Wikipedia, we will understand that a vulnerability is basically a flaw, a security misconfiguration or a weak point in our system. So basically, they are flaws. The thing is, these flaws can be used by third parties to exploit our systems, right? And make them work in ways that we don't anticipate. That's what we consider a security problem. And basically today we are going to discover a lot of these flaws.

The first thing is like, when we face any kind of security challenge, for example, here we have two examples that are actually weak code, let's say. So in the first example, we see clearly that there is a SQL injection here, right? We are not doing any kind of validation on this data.name, right, basically. So that's something that can be bad. And in the second example, we don't see nothing especially weird aside of this huge limit that we say in one of the arguments when we did the configuration for the body parser. But yeah, basically we are using Express, nothing super weird and body parser, right? So in the first example, it's very clear for us that maybe who we can blame, basically might be the developer.

And in the second case, it's not very clear, right? Because depending on how you are managing this, you have two perspectives here. So one is like, if you have a SQL injection, that is how you are using the tool and you are using the tool wrongly. So in this case, for example, is blaming the developer, right, to make the mistake to include the SQL injection. But in the other case, it's not that simple. It's mostly our vulnerability, right? So we define how the framework should work, how the libraries should work in this case. And there is a misconfiguration from the decision that we made in the project that make this weak point possible to be exploited, right? So we got a CVE the last year and we can see clearly that this can end up on a denial of service because there are some options to make, you know, crafted payloads that might, you know, float over server. So this is the kind of scenarios that we deal. We are going to discuss a lot today on what are the two main difference between these kind of things and how we can understand and expect what is considered a vulnerability in the eyes of the developer and what is considered a vulnerability in the eyes of the maintainers of the libraries or the runtime that you love to use, right?

So basically, the most important thing today, the introduction of this talk is going to be about the threat models. So basically, what is a threat model? So for us, a threat model is a simple document. I mean, the final output is a document, but mostly it's a structured approach to understand the security risk, possible mitigations, we try to identify the attackers and the actors and what can go wrong. So basically, it's an exercise that we do as part of the project and we try to respond to some of these questions, right? Like what we are trying to protect, you know, what can go wrong? What are the issues that we might see around this? What are the potential threats that we are seeing here? It is something that can be caused by a misunderstanding, can be a bot, can be, you know, attackers, can be whatever, right? What are the boundaries? That is a very important question that we should ask when we build a library, when we build a runtime, right? Like what are the things that we consider trustfully or not trustfully so we can understand that. And also we discuss a lot about the mitigations, right? What, what we need to do, I mean, how are the scenarios and what the users of our own environments can do to improve the security, right? And we build the recommendations and so on so that people get a better understanding on how this works.

You can find these threat models, for example, in the case of Node.js, inside of the security.mt document, which is a fantastic document. If you want to understand a little bit more about how Node.js take the security seriously and understand what are the processes and how you can report vulnerabilities and so on.

And the threat model, most of the time is used a lot by the researchers to understand what we consider a vulnerability or not. And this is a lot based on what we trust and we don't trust. And the same goes for Express, right? We have a specific threat model which is included inside of the security working group of the Express organization. And basically, if we take both models, both documents together and we try to combine some ideas, we can understand that these libraries and the runtime basically are trusting some things, right?

So from this understanding, you might think like, OK, so basically the framework is taking care of, you know, making some mechanisms to prevent us from the user input and so on. And it's true and false. Right. So basically the idea here is like when we see that we don't trust this kind of thing, it's like when we build applications and we provide you these tools, we should not, you know, just blindly trust the user input as we do for the operating system. But this means that we basically delegate this responsibility into you as a developer. So you should be the one, you know, working on the network data and understanding what's going on there. You should be the one, you know, thinking about the user input and external data and the files that you load in. The, you know, dependencies that you installed as part of the project, these decisions that you made, that's something that you are fully responsible of. And the same goes for other amounts of things. Right.

Right. So basically the idea here is like when we see that we don't trust this kind of thing, it's like when we build applications and we provide you these tools, we should not, you know, just blindly trust the user input as we do for the operating system. But this means that we basically delegate this responsibility into you as a developer. So you should be the one, you know, working on the network data and understanding what's going on there. You should be the one, you know, thinking about the user input and external data and the files that you load in. The, you know, dependencies that you installed as part of the project, these decisions that you made, that's something that you are fully responsible of. And the same goes for other amounts of things. Right.

So the amount of things that we blindly trust is very low and the amount of things that we don't trust is a huge list basically. And this is expected from you to take ownership on this. And if you're familiar, you know, with any kind of cloud services, most of the time, especially if you work with Azure, if you work with Google, if you work with AWS and so on, you might get familiar with this shared responsibility model. Right. So so you end up building your application. You want to expose this application to the Internet and you need a server that is running 24-7 and so on with certain conditions to be as much available as possible. Right. Especially if you have if you have a huge, big number of SLAs. Right. So you have a lot of options, right, from the on-premise to PaaS, SaaS models and so on. Right. And if you run on-premise, you are responsible for a lot of things, you know, from the hardware equipment, from the physical security of the equipment and so on, from that physical level to the application configuration. And if you are delegating this and the provider, then you are less responsible for these kind of things. Right. So, for example, if you are using S3 as a service from AWS, you are not responsible of providing the servers, you know, and the physical security so no one can get access physically to those computers, I mean, to those servers and make some manipulation in the hardware and so on. Right. That's how this shared responsibility model works. Right. Depending on on how you structure these responsibilities. So you need to understand this threat model in a very similar way. Like there are things that the frameworks and the runtime are trying to be responsible for. And there are things that we let you the responsibility to handle that.

So it's important to have this very clear. Unfortunately for us, it's not that clear. Like it's not you just cannot make a table and say, like, this is what the libraries do and doesn't. Right. You need to treat every threat model when it's available and understand how these libraries are interacting and taking, you know, the security and the perspective they are using. So that way you understand what is expected, most or less from you to take ownership on.

Best practices that you need to take into account just, you know, some key takeaways from this. So please always do validation and sanitization of any input that you have. It doesn't matter if it's a form input, if it's a URL input, if it's a file input, I mean, any kind of input that, you know, someone can send it to you and can be manipulated and grafted and so on, should be validated. You should understand very well how the authentication works and, you know, having updated policies and strategies and, you know, using the right security approach on this. You need to use, for example, security headers and having a clear understanding of the typical web attacks that you see in the OWASP top 10 and so on, that's important for you as well. You need to, you know, take full ownership on your own dependencies.

You need to, you know, take full ownership on your own dependencies. I mean, dependencies are great. We there are like millions of packages right now on NPM that we can use to speed up how we don't work, right? And we don't have to rebuild every second, every project that we do. But it's important to understand that those libraries have some maintainers around, right? And we should be able to understand how the security of these libraries work, if they are maintained or not maintained and so on.

I mean, there are tools already there that we can use, you know, like Snyk and Socket and so on. But it's important that you include this, you know, review and audit of these kind of dependencies and having this, you know, updated them over the time. So include this in your development life cycle.

You need to understand as well that if you, you know, create any kind of service that is outside and available on the internet, you have to, you know, put some limits on the use of resources, right? It can be like the typical API, apply for it limits on the APIs, calls, you know, limit the communications, IP restrictions, you know, having policies, these kinds of things. As well, you need to understand how to manage the cookies, you know, sensitive data exposure is a very common thing, especially when we have errors on the server.

I see, unfortunately, recently, a lot of scenarios where the people didn't handle properly the errors on the server and you end up sending this information back as the content of the request and so on. So you basically are providing even much more information that needed to a potential attacker as well. So that's important, you need to handle errors properly. And you need to log these kind of things as well, right? You need to have a proper logging in place so you can understand what happened with every request and what's going on in your server on the services that you have online. So later on, you can do a proper outlet and trace what happened and understand what's going on, right? Not only for misconfiguration and books and errors, but also in terms of security, understanding how the people are exploiting your system will help you to understand how to secure them basically. And you need to have some kind of security monitoring and so on.

I'm saying a lot of things, right? So you end up having a big list. So prioritization is important. So let me show you some real-world vulnerabilities that might be quite common or I see quite common. So prototype pollution is one of the most tricky things in my experience. I see this a lot. It's a very common thing in JavaScript. We have some mechanisms in Node.js and Express to prevent these kinds of things. But we don't do that for the payloads that they send you, right? So you need to be clear that when someone sends you like a JSON or so on, you can see there a lot of malicious payloads that can force this kind of prototype pollution. So it's important to understand in this how it works deeply and also to do these sanitizations.

For example, it's understood that people think that Express provides you like a, you know, pretty full security headers on place. So you have a lot of policies and so on on the headers and these make your application much more secure. Actually, Express doesn't do that today. But there are libraries that help you with that, like Helmet, right? So it's important to understand these kinds of things because we'll reduce a lot the surface for attack on your applications. Malicious third-party packages. This is a very common thing.

You depend on a lot of things and the things that you depend on depend on more things and so on. So you basically have a huge full play chain. And that's unfortunately will add you more work because you need to have a real control and understanding of what's going on there and having some strategies to mitigate this. This requires as well that you understand how CVEs work, how, you know, when you need a CVE that has been published recently in one of your libraries. This is affecting you. You need to migrate. You need to change. I mean, you need to take decisions and basically take ownership on this. And it's a full work on their own.

As well, you need to understand everything that the people can send you, for example, especially files and stuff like that. You need to understand how are the limits, right? So as we say before, the same way that you put limits on the API, you have to put limits on the length of the things that they can send you, especially in files and stuff like that. So don't get exhausted in terms of lacking of space, services, and so on.

Basically, as a conclusion, just first conclusion, not all the security issues are vulnerabilities, right? At the end, we are discussing about flaws in your system that someone might, at a certain point, use that to exploit your own system. That's the thing, right? And make the software work in a way that you didn't expect it. So that's how, when someone really explodes your system. The most weaknesses you have in your system, the highest is the chance to get the vulnerability and that goes to security incidents. So basically, if you understand the vulnerabilities and the surface that you have, it's going to help you a lot. Developers are doing a key role here, as we say before. I mean, we have a certain responsibility between the library creators and maintainers, like myself, and all the developers that are using the things that we build and create, right? So we need to understand and have a good relationship here. And especially as a developer, you need to understand where I set my boundaries as a maintainer. So you understand where do you need to take more responsibility on the things that we do. And the same goes for the thread models, right? If you understand really well how these thread models work, it can help you a lot. As well, these thread models only not help you to understand the libraries. You can use these kind of thread models to help you to build your own thread models for your own surface, your own projects, and so on, and get a better understanding of what's going on. Because security is a huge matter. It's a huge matter not only because the importance it has, it's also because the surface and the amount of time that it might require from you, right? So it feels like a huge thing to accomplish. And it's not something that you can just accomplish one day or just invest in like, you know, one quarter dedicated to that. And from that moment on, you are secure and you forget about it. It's something that it will be together with your application, as long as you're running the Internet and you still have a surface that someone can attack, right? So basically, you need to understand and take everything seriously. But you also need to, you know, understand how these flows are there and will be there. So you need to have some policies in place and some ideas of what's going on. I included as well here some resources. So basically, you can, you know, go deeply on this and understand more things. You have also some examples on how, for example, we can create a very simple backdoor on Express Middleware and how you can inherit this into your application. How the CVs works in terms of how do the patterns run, as well the threat models that we say before. Well, thank you so much for watching this session. I really like the idea of sharing this knowledge with all of you. I hope that you have the opportunity to learn something new today and I'm really open to have a lot of discussions about security on social media at any time. So thank you so much for being here and share this time with me.