 You can talk. Okay. Good morning. Thank you for coming. Well, my name is Fernando Ortega in foreign Spain. And in this talk, I'm trying to explain what are the main tools, the main best practice that we have in node application for testing the security of node applications and for what are the main vulnerabilities that we can find in Node for explaining the main techniques that attacks the attackers, the techniques that attack is used for hacking these kind of applications. This is the agenda. I will be an introduction to the security of the platform. Later, I will comment the main security package, a white ball in MPM repository. I will comment also a project for starting and learning for this kind of projects. This is called the NodeQuilt project. And finally, other tools related with Node.js for testing the applications. Well, Node, basically, is a multi-purpose runtime environment that allows the creation of highly scalable applications. And in the last years, has reached a group of people by the known as stack mean. That is the combination of MongoDB Express. That is the most common framework where you are developing with Node.js Angular and Node.js, hopefully. In this talk, I will center mainly in Express framework because it's more or less the standard that all developers use. But there are other solutions like CoA and other solutions that we can find for developing these kind of applications. From the security point of view, it's important always to use, for example, the last stable version of Node.js and Express. And it's important also knowing the vulnerabilities published from there. In the express.com site, we can find what are the security updates in this platform. In the list, for example, in this page, we can find the list of Express vulnerabilities that have been fixed in a specific version. We can see, for example, in this repository, we can see the last test vulnerabilities discovered for specific versions of packages and the level of criticality. Basically, each package comes post a critical vulnerability in your application when you install these packages in your application. Your application can be exposed to the vulnerability that you can find in this kind of vulnerabilities. Later, I will comment what are the main tasks, but basically, tasks like cross-scripting, denial service, cross-request forgery. Later, I will comment these attacks in depth. For example, it's very common to find news related with new vulnerabilities that have been discovered. For example, this is related with denial service, with large HTTP headers. All these vulnerabilities are related to all versions of C and later, all vulnerabilities, by using a combination of many requests with maximum size headers. And it's possible to cause the HTTP server to abort from heap allocation fileware. These are the main security level modules that we can use, for example, for establishing a minimal security. For example, for establishing headers, security headers sending cookies in a security way and minimize attacks of type cross-request forgery, cross-scripting, and so on. In this talk, I will center mainly in helmet module. I also will review others related with encryption and securing communication with SSL. Well, for securing, there are some security-related HTTP headers that you should set. These headers are stricter post-security that this header enforce the security connections to the server using HTTP or HTTP over SSL. X-Frame options that provides client-jacking project protection and other related with protect this kind of tags, cross-scripting, and so on. There are other that prevents, for example, attacks for other kind of attacks more advanced. This is the main module that we can find in MPM repository in order to set these headers that we have seen before using the helmet module. The helmet module can help you protect your app for some well-known vulnerabilities by setting the HTTP headers in a secure way. Basically, importing this module and over the main map, the main object, the app object, use these helmet methods that provide helmet. Basically, helmet is a collection of middle-war functions that set HTTP response headers. It's designed for a specific attack vector. For each attack vector, we have a method, a header, for protecting this type of attack. Some of the header that helmet provides, we can highlight, for example, in hide-power-by. Basically, this header removes the X-power-by header in the browser. Now, let's see an example. There are others that HP keep that prevents man-in-the-middle attacks with forget-certificates and other related with preventing, for example, your website from being built on HTTP and avoid, for example, classical attacks related with SSL stripping. For example, if we want to prevent cross-site scripting attacks and that injects an attack in our site, we can use the Content Security Polish header in this way. We can set the, we can use the helmet, those policies and establish the policy of our site. You can check, if you want to check if headers are set in a security way in your application, we can use, for example, these online checkers. If you quickly want to check if your site has all the necessary headers, check out in a security way. This is the first step when we are testing this kind of topic. We can use this service for doing this. Express framework, by default, adds the X-powered by Express header, which tells potential attackers what framework you are using. And therefore, how to exploit advice on public known vulnerabilities. For example, searching in Sodan, we can see information about servers that contain a specific version of Node. We can see that in this header, we can see that the version that the server is using. And attackers can use this header to detect apps running express and then allows specifically touch attacks. To disable these headers, we have two alternatives. Disable it manually of use the helmet module that already is for you. At this point, we can use the app.disable for disabling this feature. And this basically avoids framework fingerprinting for an attacker. And also, we can use anti-fingerprinting techniques that allows us to hide that is an expression of application. For example, we can indicate another language, last PHP in the header, for an attacker know the version of our application. In Node.dis, you can easily manage cookies in a security way also. For example, using the cookie session package, we can use specific attributes, specific properties that allows securing your cookies that allow prevents that an attacker can read the cookies of your application. For example, the HTTP only. This attribute is used to help prevent attacks such as cross-scripting since it doesn't allow the cookie to be accessed via JavaScript. There are attributes like domain and path that basically the domain and path are used for the application. What are the domains allowed for reading the cookies of the application? By default, cookies can be read by JavaScript on the scene domain. This can be dangerous in case of a cross-scripting attack. In any city party, JavaScript library can read them with document.cookies, for example. To prevent this behavior, you can set the flag that is coming for HTTP only on cookies. We will make your cookies unreachable for JavaScript, and also you can use the security flag for ensuring cookies can only be sent over HTTPS. Now in common, some attacks, they are very common for attacks, for injecting code in an application. For example, cross-scripting attacks occurs when an attacker injects a executable code to an HTTP response. When an application is vulnerable to this kind of attack, it will send back a validated input to the client. There are other attacks, for example, cross-scripting attacks are similar. The main difference between cross-scripting and cross-request forgery is that in cross-request forgery, you need that the user you need an authentication session for applying the attack. While in cross-scripting, it doesn't need an authentication session and can be exploded when the vulnerable website doesn't do the basic of validating or escaping input. Cross-scripted forgery is an attack which force an end user to execute unwelting actions on a web application in which the user is currently authenticated. And it can happen because cookies are sent by a very request to a website. How can we mitigate this kind of vulnerability in Node? In Node, for example, we can mitigate this kind of vulnerability with the C-Surf module. This is basically an express middleware for shears-ref protection. And when a request is being served, you can check the idea and send a shears-ref token when the request is when the user is making the request. One of the ways to implement the validation, for example, is to use the custom middleware to pass the shears-ref token to all the templates using response.locals, for example. And on the view layer, on the HTML code, you have to use this token in a hidden input and define this token in this way for... And when a user input is shown, make sure to add a hidden input with the shears-ref token value. To prevent this kind of attack, it's also important that the most critical data requests are made through the POS since the data is sent in the body of the request instead of the URL. And for doing this, this kind of of issue, you have to be aware of this. Well, for phishing, for example, cross-executing vulnerabilities in Node.js applications, we can use some modules like Sanitizer and Splash Variator. Also, we can use, for example, regular expressions. Regular expressions are very common to validating the user input, but these modules help apps extract the issue input validation. Now, we will see an example. For example, we can use Express Variator to filter and sanitize the issue input to protect against cross-executing and command injection attacks. The objective is to filter all those entries that can result in an attack filtering the HTML and JavaScript code that can cause this attack. This is a useful module for validating the issue input and, in general, filtering the input of the user. And avoid that an attacker can use special characters for compromise the application. Express Variator also provides additional request handlers. For example, we can use request.assert and request.validation Errors for validating required fields. For example, we can use if we need to check an email in our application, we can use directly the e-mail method for mail validation without worry about using regular expressions or something else. And in an easy way, we can validate our application for and send it in a secure way to the server, that information. If we are, for example, storing password in a database, this is one of the modules. There are others, but, well, I commend this because I think it's a good point to start in. The module is called Becrib. Basically, we have functions. This module provides functions to generate the hash that is stored later in the password. And another function that allows to verify that the password that the user is entered matches with the hash generated with that password. The idea with this module is to store the hash in a database and then retrieve it to compare it with the password that the user introduced. And to manage the store of passwords, we can do it by first generating the sal that will be applied to the password to obtain the hash. And to compare the password, then the user initates a session, the password entered by the user is converted into the hash and compared with the stored hash. All these attacks can be tested, for example, in a control environment. This is called the Node-Goat application. It's a deployable website created by the all-webs to teach and practice to identify all these rates in Node applications. We can find a deployable. This application is deployable in Node-Goat. . .com and you can find a tutorial for learning these kind of attacks. You can practice with injection, cross-scripting and other related with access control, sensitive data and so on. For example, this application uses the val, the val function that is very common to use for parsing JavaScript. It's a big word that is used in your application. You are supposed that an attacker can inject a code when you are in that function and a val is a vulnerable function if you don't use this function in a secure way. For example, if an attacker were able to manipulate the response of a service it could inject arbitrary code by calling a val which will execute the code in the context of the victim's browser. We could also, for example, perform a deny of service attack by simple sending commands like process.exe process.kill to the val function and this what we do is shut down the server and there are other types of attacks that could even get the list of files from the server. We don't validate the input of the user. And finally, well, I'm going to comment other tools we are so interested to know the system we have, for example, Kraken.js basically this provides some extras to express applications related with security communications this is an example for using this module in the same way that we have seen before with the Hemel module this module provides the same functionality. This is another tool interesting for testing for static analysis tool that can detect security problems in your applications. Basically, it's a Python script that returns a report with evidence it has found that can cause security problems in your application. Well, it's open source you can find in the repository. It's a good tool for introduce in this kind of for testing the security of your node applications. And that's all these are the repositories and other resources and reference. Thank you. Thank you very much. So we don't have time for questions but will you be outside the room? So if you have questions please do get out of the room. If you are going out for any kind of reason pick your trash pick the plastic bottles