Hi everyone, thank you for joining my session. Today I'll be talking about how to secure your JavaScript applications. Before we get started, let me introduce myself. So I am Joshua Arvin Lat. I am the chief technology officer of Nuworks Interactive Labs. I am also an AWS machine Learning hero, and recently I am one of the five winners who were awarded the Digital Leader of the year award. I'm also the author of the following books, Machine Learning with Amazon Sagemaker, cookbook, machine learning engineering on AWS, and then the third book, building and automating penetration testing labs in the cloud. So without further ado, let's begin. So there's going to be three parts in this talk. So for part one let's start by talking about the reality. So what do you mean by the reality? So if we have been building JavaScript applications, whether it's in front end, in back end, using JavaScript for mobile applications, maybe you think that if you were an amazing developer or engineer, you would be able to automatically secure your applications in real life, in real projects. That's not really the case. Why? Because once you get to work in an organization or in a team, there's that reality that organizations, especially right now, would definitely prioritize, as you can see in the screen, the short term financial objectives as well as the long term financial objectives. At the same time, the overall goal is to make the clients and customers very happy. So what does that mean? What's the applications? The implication? There is, there's that chance, a very big chance, that we'll all be focusing on the features and less on the engineering best practices as well as the security best practices left alone compliance. So in order for the team to be able to build systems really quickly, a lot of the other items that's in your pipeline, it's probably the security checks, that's probably the other compliance requirements. Those will be deprioritized so that you'll be able to launch your product faster. It happens to all companies, whether big or small, whether you're in a startup, because right now a lot of the leaders and managers would say, well, there's nothing to secure if there's no business. So let's focus on the business first. However, in reality you need to take care of the security from day zero or day one, because security is kind of tricky to include once the app is already running. It's not just about adding firewalls to an existing JavaScript application. You have to make sure that the developers are already aware of the different security implications and risk and threats available so that when they build the system it's already secure and hardened. In addition to that, developers usually know a lot about the best practices from the development end they may know a few security best practices as well. However, in reality most developers have no idea how an attack really works because for one thing, being a developer is already hard enough and they have to learn a lot of things already. Right now, if you want to become a developer, it will probably take you two months, three months, six months or even a year of experience before you're really able to contribute to more complex projects. How about you spend another one to two years or three years trying to learn how to securing your JavaScript applications? So one of the ways to help us understand what to prioritize and what to do when it comes to security, one of the more important things is for us to understand what we call the cyber attack chain. So let's start with a simple example. Right now a developer would probably think that this is code which has harmless lines of code. In most cases they would say oh, there's that evil statement there which technically evaluates that expression and that could be used to compromise the entire application. So if this piece of code is part of an overall web application, developers would say that's risky. So before we go into that, let's first check how this application works. Let's start by entering a mathematical expression. So you input one plus one and your application behaves normally so it produces two. So amazing, right? So your application is supposed to do what it's supposed to do. That's the bare minimum requirement. However, most developers, even though they know that using the evil statement is not recommended, they don't know how their applications would be compromised because it's not really part of their training. However, somebody is just playing around and trying to input different things in your application, they could easily input something like this. And what would the output be? It would create a hello text file where the server files are running inside the production server. So very scary because this well crafted input is used by a potential attacker in order to perform something which shouldn't be happening in the first place. The application you built is just supposed to evaluate a mathematical expression. And for some reason your applications was used to misbehave or to do something which it shouldn't have, which is in this case to create a hello text file. Is it really that bad? I mean, what more can you do with this example? What if a potential attacker runs the following command in a different server? So let's call that the attacker machine. So the attacker machine is different from the target machine. So the target machine is your production server where this application is running. So again, this is kind of simplified because the lines of code I've added, they're basically just there as a standalone line of code. In reality, that evil statement, that block of code, may be part of a larger web applications. So going back to this example, if the hacker or the attacker runs the following command, what happens there is the attacker machine listens and waits for the malicious input to be pushed to your vulnerable application. So this time, the moment that that specific block of code is invoked again, and instead of entering or inputting a mathematical expression, you input this instead and the IP address is now replaced with the public IP address of the attacker machine. So what happens here is that the victim machine, the target machine, now connects back to the attacker machine. And what happens there is the attacker would now be able to run commands as if it was his or her own machine, similar to Ssh. So very scary, because the moment the attacker has direct access to your machine using something called a reverse shell, then it's technically game over for that machine. The next steps there would be for the attacker to perform other types of attacks, maybe look for other passwords, look for databases there, download the data and use the data collected to basically perform other malicious actions. In other cases, it's possible for the attacker to perform something called IAM privilege escalation. So if your application is deployed in the cloud and the server where your applications is running, there is a big chance that other attacks and chains and sequence of steps would be performed by the attacker after the initial set of actions. Again, it's a chain. It doesn't end with this simple set of steps. There would be other more steps that the attacker would do. So on your end. It's important that you practice code review. You have code review sessions in your team and you need to have someone knowledgeable about these types of security best practices. Because even if you guys know that it's not recommended why we should not use evil, you should be able to explain and demonstrate why that's the case. Now let's proceed with part number two. Let's now talk about how to secure machine learning powered JavaScript application. So right now there's a lot of innovations and new solutions when it comes to AI and machine learning. Right now you've probably heard about large language models and at the end of the day, these large language models would be deployed inside a server, right? However, in some cases when you have to build aipowered applications or machine learning powered applications, you usually no longer need to follow this set of steps. So when you have the time, the money, and your organization has their own data, they would be able to build machine learning models. So you start with data collection, you prepare the data, you do feature engineering, you perform a bit of analysis, and then after model training and hyperparameter tuning, you evaluate the model or models and then you choose the best one and then you deploy. So the moment you deploy the model, it's now usable by other applications so that they would be able to mimic human intelligence. So for example, let's say that there's an image of a cat and you uploaded that image of that cat to a mobile application, and then your mobile application pushes it, let's say to a JavaScript server. That JavaScript server utilizes a machine learning model to perform inference, basically to predict if it's a cat or not a cat, and then you return the response back to the mobile app and then there you go, the user would receive if it's a yes or a no. So the input would be image and then the output would be one or zero. So if it's one, it's a cat, if it's zero, it's not a cat. So basically that's how machine learning powered applications work. In the past you would generally have to deploy it inside a server using various different approaches or techniques. However, right now there's now an option to even deploy your machine learning model in the browser. So wow, right? So using javascript you would be able to deploy your machine learning model in the browser. So in the left hand side you can see that, yes, you can deploy your machine learning model on the server side, and then on the right hand side you can see that you can deploy your machine learning model in the front end side. So what happens there is the browser is able to download your machine learning model from the back end and then there from within the browser you can do a lot of awesome stuff there already. So there's no longer any more back and forth after the initial request because everything is going to happen inside the browser. So for example, continuing the example earlier about that cat being pushed CTo the machine learning model in the back end, instead of that image being pushed to the back end from the front end, what happens instead would be the image of that cat stays in the front end and the machine learning model in the front end. Also in the browser what happens there is the inference happens in the browser and the model responds whether it's a cat or not. A cat but this time that request no longer reaches the back end, the server, because the model is already in the client side, the browser. So why do this? What's the advantage of this approach? The advantage of this approach is that, number one, you can work offline and then there are no servers needed if the model is in the front end, right? Second, it helps with data privacy because the request from the browser no longer reaches the back end, and there's better latency. Also because there's no more back and forth from the front end to the back end and back to the front end. So in order for us to appreciate this further, it's basically your favorite libraries and frameworks in the front end combined with a specific machine learning library. And here, these are just a few examples on what you can use to perform this type of scenario. However, before you do that, there are several security considerations you have to research and think about before you have this type of architecture. Because for one thing, anything that is pushed to your browser can be downloaded by someone who knows how to do it. So let's say that you have a website and it's used by a lot of users. What if the machine learning model used and pushed to the browser for that browser? Side inference, what if it's downloaded by your users and they create a new website using the same model? So again, in most cases you would prefer the model being deployed in the back end. However, in some cases, if you're really okay with the security impact or risks, then that's fine as well. So if you're doing a demo, if you're not using data which is proprietary, if you're okay with your model being downloaded, or if you know how to further secure your model in the front end, then that's the time you deploy your model in a way that can easily be downloaded by the browser and perform this type of approach. Now let's proceed with part three, the last part. In order for us to secure our JavaScript applications again, in the previous examples we've focused more on the back end part, and in some cases you focus more on the specific JavaScript implementation. But in order for us to fully secure our applications, we need to be fully aware of how to secure the libraries and library configurations as well, the framework configurations as well. What I mean by that is, every time we use a library or a framework, we need to be well aware of the different vulnerabilities and risk involved with that specific framework. For example, if you accidentally forgot to enable production mode using a specific framework or a library, what would be the impact. So again, in addition to having a good understanding of the different vulnerabilities for the language, it's important that we have a good idea on what risk and vulnerabilities are also possible when using this specific libraries and frameworks. At the same time, when using libraries, be very careful because there may be some malicious libraries as well and you don't want your application to be compromised because there's some sort of backdoor in that library. So there are different tools available online, whether they're paid or free, and you can use that to further secure your JavaScript applications. Also, when it comes to vulnerability management, it's preferred number one for your organization or for your team to utilize something like this. This is what they call an automated vulnerability management service or tool. So there are different tools available online. And the great thing about this is every time there are changes in a server or there are changes in a container image, this automated tool would automatically scan those servers or containers and provide this output. So this output is a list of the different risk and vulnerabilities involved in that system. So in addition to having that code review layer, whether that's manual or automated, you can also have this layer which makes use of an automated vulnerability management tool. In addition to that, when dealing with network infrastructure where your JavaScript applications are hosted, it's important to practice this network solutions. So with network isolation, even if some of your servers get compromised, hopefully not. If some of your servers get compromised, the other systems in the same network would be protected. If there's network isolation in place, if you're able CTO properly design the subnets. If there's a private subnet here, if there's a public subnet here, then the damage can be limited only to a certain portion. So network isolation helps a lot because even if the attacker is able to fully compromise one machine, the other machines are not automatically compromised also. So my question for you guys is how about IAM privilege escalation? So for one thing, how does this work? So the first set of steps may involve your JavaScript application compromised, and then let's say there's that reversal and your attacker is able to access the server. It has the ability to run commands inside that server. Even if from a network standpoint the attacker is not able to attack other servers because of network isolation, it is still possible for an attacker to utilize something which is called an IAM role. So this IAM role is attached to the server when it's deployed in a cloud environment. So this IAM role is called differently in Azure, GCP and AWS, you can just think of it as a configuration which allows the scripts inside that server to run cloud computing actions or commands. So for example, this security IAM role allows the server or the scripts inside the server to create a new resource, or even to modify or delete resources from within that instance. So the scary thing there is what if that instance has an IAM role attached? CTo it, which allows any user to run a script inside it which deletes all the resources in that account. So no matter how secure the other applications are, the weakest link will be the weakest link. That will be the source of chaos from within that entire cloud account. So there are different ways to handle this, and there are different strategies to manage the risk and potential impact of that kind of attack. But one of the ways would be to restrict the IAM permissions. Never give too much power or permissions to a server. So in the past you give permissions to a human, but right now when you're deploying your applications in the cloud, you can either give permissions to a human or you might be able to give permissions to a machine resource, which is in this case a server. So limiting those permissions, or maybe not giving any permission at all would help improve the security of your application. So again, securing JavaScript applications is not just about securing the code, it's also securing where your JavaScript applications are running. So how about denial of wallet attacks when it comes to securing JavaScript applications right now you also need to understand the architecture aspect. What if you have a serverless implementation or architecture which uses AWS Lambda and JavaScript to process web request? So AWS Lambda is a function as a service which processes an event and provides a response or an output. So if you have a web API that can be your backend web server, but behind the scenes you have a serverless web API resource, and you also have serverless functions which processes each of the requests. Having a good idea on how the finance aspect works would help you, because if your application is not able to process denial of service attacks, well then you might encounter a similar issue here where you might be surprised that your cloud bill would be amazingly large. When I say amazingly large, you wouldn't be able to pay the bill at all because there's too much request which force your infrastructure to scale automatically. And then you have to pay a lot of money because you pay for what you used in a cloud platform. So this affects different cloud providers and it's important that you're aware that this attack is possible because it's going to really cost money which would then close that cloud account. So in order to protect against denial of wallet attacks number one you need to be aware that that's possible and second you need to be able to include in your plan and architecture how to deal with ddos and denial of wallet attacks. So that's pretty much it. In this session we learned a lot of things. There were three parts. The first part focusing more on the JavaScript code and making sure that the developers are well aware on how that JavaScript code can be used to compromise the overall system and server. The second part involves how to secure your JavaScript applications which are machine learning powered and part focuses more on the other aspects like securing the libraries and frameworks used as well as the other aspects like the infrastructure and the network as well. So thank you again for listening to my talk and hope you learned something new. Have a great day ahead guys. Bye.