Hello everybody. This is Sund. I am working as technical architect in UBS. Prior to that, I worked with Cognizant and I worked with different clients like Amex X, Broadridge, like financial organizations and especially in wealth management. System. Okay, so today I'm going to give a demo on Java script vulnerabilities. Let's start, let me share the screen. So here is my screen. So securing JavaScript, which means how. We need to protect our code from external attacks. So it may be either front end related or it may be either from backend related or it may be either from any other tools or libraries, any other components that. Security challenges here. Okay, so nowadays many people are using frontend applications as well as backend server side components. The attack can come from any point in the sense like from the front end or. From backend front end, React, not backend, like no js. So there is a lot of opportunity for the attackers to create a lot of attacks and vulnerabilities across our different frameworks across our. Different APAs and across the different components that we are using. So the normal, traditional security approach. So they do not address all the vulnerabilities. Definitely we need a. Some sort of patterns, some sort of mechanism to address all these vulnerable system. Let us see. Okay, so we will cover java script attack landscape. So which means what are different ways of threats? And second vulnerability management framework. How we can mitigate those issues frontend. And third one, frontend security patterns. Definitely we can protect our code by following some patterns like design patterns. No fourth one, no GS security. So how we can manage our backend code? With using some sort of specification. And fifth one, automation and integration. Also, automation and integration means everything is like automated, so it's like workflow and components are integrated. So that is process and risk based patch management. If there are any issues immediately identify that and apply some patches, something like that. Okay. As I said, common Java script attack vectors. So if you consider Dom based excesses. Cross site scripting. So this is one of the major vulnerability attack that our code base is facing. What it means. So it means. For example in JavaScript, our frontend code, if we are retrieving some value from the URL, for example, a name or designation or anything. Okay. And you are including that as part of inner HTML. You are making those values into some document and you are trying to execute the application. So this is like not a bad habit of coding. There is a lot of scope that external attacks can happen. So this is one of attack that can happen. And second thing, prototype pollution. So prototype pollution means for example so you are creating a Java script for example in the sense window, dark location. So in that case it is harm to read those values and definitely, and there may be attack from external site, external pupil dependency, confus. Dependency confusion is like, for example in our application, lots of components we are downloading for Maven website. So lots of components we are downloading. So attackers want to create a confusion between the original component and a harmful component. So they want to. Make use of similar name pom xms components and try to now expose those components into the public websites. And in turn people can download that and try to install and try to put their components in the application. So obviously that's a big attack. And another one is server side injection. Server side injection is nothing but the core will execute at. To interact with the database. So definitely there is a lot of scope. If the code is not written properly, there's a lot of code. They can manipulate SQL queries and they can include. The values, whatever they want. And even non SQL also, they can manipulate and they can attack the data. They can get the data, they can manipulate the data. They can delete the data. So there are lots of possibilities. Like this. The externals can attack. Okay, so now what to do? We can. We can get a vulnerability management framework. We can use some sort of frameworks good frameworks where we can it can handle all these sort of things in appropriate way. So it. First it assessment, so it identifies and quantifies the risk across our JavaScript stack and prevention. Im, so it it implements some security patterns and some controllers, some security related admin, admin roles. Something like that. Detection, so it continuously monitors. And automated the scanning. For example, if there is any code which is vulnerable immediately, it gives alert. So it continuously monitors and it gives an alert if there is any issue. And instant workflow and patch management, which is in the sensor. If there is any incident happened immediately it applies related. Batch. Now, let's see. Quantity to risk assessment for some sort of depend system, evaluation criteria. So vulnerability history. It tracks the fast security issues and resolution terms. How many issues are reported what are the resolution time within what time it has been resolved. So it gets the, all the history of that vulnerabilities, maintenance activity. So monitor, commit frequency. Issue response and active maintenance. So it frequently monitors what is the code committed? Who is the code committed and when it is committed so what are the impacts of that commit? So whether it can be a. Removed or not. So dependency chain chapter SSS translate to dependencies and their security posture. Download metrics, evaluate community adaption and security levels. Another one is automate auditing tools enable consistent data driven security editions across the JavaScript projects. Front end sec. Coming to the point of front end security, client side defense. So how these are all the points how to mediate or how to manage those vulner vulnerabilities, sir? So if you consider accesses right, cross script. Cross set scripting. So these, for example, these externals can attack by giving some dummy values or some images. Or some path to image in the URLs, so when the code traced to get that particular value. The attacker included an image which is n. Not secure. And our code tries to get that image, load, that image, or it may be something like that. Any link or something. Which is obviously it is under attack. So second one, secure API communication. So we have to use proper HTPS implement proper VO RS. Policies and especially validate all the data. So what is that data input, validation, simple input, validation, what it contains what are the re required values or what are the mandatory values that can contain, you cannot simply pass through. So definitely how to validate all the data received from the external source input. Third one, input sanitization. Which means before you do document or using any others so use some validation libraries spec and use some specific formats where the user can give and, and we can validate the data, especially the fourth one. Authentication security. Security token. As you can use certificates. You can use tokens. Okay. So using that, we can definitely not secure our website item. React modern frameworks. And we need to consider a word dangerous self inner HTML. This is very high. Very important point. Okay when there is a necessary to use Dom. Okay, we can use purify or similar any other libraries which can San sanitize data before we render to any other webpages or to backend and validate. Prototypes are type scripting to enforce type safety and prevent unexpected data flow. Okay. Carefully manage the data flow between components. And validate the data at Bond raise, sir. Okay, so no GS back in security. Secure coding practice. There are lots of things here, so input, validation, whatever the value received from your request parameters or URLs you need to validate and especially parameters, queries. They can in query parameter, they can give some value ease admin through. Or they can give some account number, wrong account number. They can put some account number to deposit money or to withdraw or something like that. They can manipulate the SQL queries and then trace to execute at server side. So definitely we need to validate all the input data that we received. And proper exception handling especially without exposing whatever it comes to. Before exposing, we have to put proper exception handling, mess message and secure authentication authorization and on rate limiting and request throttling. So runtime production environment variable, securely. We can use different environment variables. So we have to use all those in a secure way. Okay. And principle of list, er. Okay. And if there is a need, then only give the roles and responsibilities roles in the sense. Okay. So secure dependency management and regular security areas with NPM Ator. So container security for JavaScript application, minimal base images use airplane or on images to reduce attack surfaces and eliminate unnecessary packages. Non user run node js process as non-privileged users within containers to limit potential damage. Integrate vulnerability scanning into CACD pipelines. To catch issues before deployment even. CICD pipelines is a major workflow management system, so definitely we can automate all the code to avoid any issues before the deployment and never break the secret symptom images. Use orchestration platform secret management instead. Okay, so automation throughout the development. Pre-committed in the sense before we commit the code into Git report or whatever it may be. Scan for secrets, you have to make sure that there are no credentials or PA passports related issue issues, vulnerability issues before code goes to repository. Okay. And pull the request. Automated dependency audits the security and test execution for every submission. And C-A-D-C-D pipelines integrated into build and deployment process, and then continuation monitoring, runtime, application build log analysis and deployment to production. So risk patch, risk-based patch management, mattresses. These are many things here. Okay, so critical zero day, immediate patching within 24 hours active. Two, exploration in the wild, which means if there are any instance or anything immediate, immediately we can apply patch so that it can come to normal position. How high severe. Severity, so patch within seven days. Non exploit, high severity score effects production, medium risk should within 30 days low prior, include a run term maintenance, minimal impact of the required local access, so types of scripts, role in security. Type safety prevents common vulnerabilities, which means static typing ca. Caches type country issues prevent prototype pollution through sticker objects handling and enforce interface contact atel time enhanced code quality. There are lots of sonar, for example, sonar, sonar cube. Okay. Sonar cube, it gives all the correlated issues before we commit the code. So if it passes, then only we have to put a condition in the pipeline stop deployment or stop proceeding to commit if it identifies any issues, vulnerability issues. Okay, not a silver bullet. Light TypeScript does not replace random validation, secure testing, or secure coding practices. It's one layer of the defense in depth strategy. Okay, so these are the points that we cover. Adopt a framework mindset. Okay. Secure is NAIA checkbox. It's a systematic approach spanning assessment, prevention, detection, and response. Automate everything possible. Yes. Avoid manual processor, for example. Do not use any manual created passwords. Automate it. For example, if you consider cloud it. Automatically creates the password. No knows it. It automatically creates, it automatically works. That's it. Nobody knows the password. Okay. And especially nowadays even that is go, that is also going away. There's no password just based on the user entitlements user roles. We can go for the website browsing. Prior that intelligently use risk-based patch management to focus efforts where they matter most without security. Think full stack JavaScripts security requests protecting both front end and backend. It's not know only front end, it's not like only background from end-to-end application. And contrast the each thing. Thank you very much.