 Shakravarti introduced I am the Lavakumar and very happy to see so many people on a Saturday morning if I was to be honest if I wasn't speaking I wouldn't be here because Friday nights are usually very colorful I in fact saw one gentleman here sleeping I'm glad he woke up just in time okay so like I said I'm a WWE fan so I you know like to wrestle with web applications find security vulnerabilities in them develop tools to you know actually fix these vulnerabilities and also talk in conferences and other places so you know you can I can help spread awareness about security in general so this talk is titled everything you need to know about client-side code execution which is essentially cross-site scripting before I get started I would like to know how many of you are familiar with the concept of cross-site scripting pretty much everybody right which is expected because if you are into web application development and if you do not know cross-site scripting then you know you're doing something really really wrong or at least your employer has done a huge mistake hiring you so everybody does know what is cross-site scripting but the depth of understanding of cross-site scripting could be you know very different among different people so this talk will and with a lot of technology new features and new frameworks coming over there's a lot of you know changes in the XSS space as well both in terms of how XSS can happen as well as you know how XSS can be mitigated right so this talk is going to talk about all of that so this is the outline so first we'll entered you know like establish what is client-side code execution talk about its impact then we will talk about the different forms of different types of client-side code execution then we'll look at how to prevent client-side code execution because this is a developer conference and you know prevention or fixing these vulnerabilities of primary importance then we'll look at you know an online tool called as DOM Goat it's a it's a it's a well it's an application of created which can be used to learn DOM related security vulnerabilities primarily DOM DOM related XSS issues so I'll show some examples with that you know just to drive home the point okay to get started when we look at security of applications I mean there have been a few security talks yesterday as well so primarily when we look at security people think that security has to be first put on the server you know you have your server side of the application that has to be secured properly if you think of your server side as a very strong and you know a powerful vault or a safe right so what you do is you try and put it behind as many layers of protection as possible you know you have your ideas IPS firewall and you do all your security testing on the server side and you have different kinds of monitoring systems there so think of it like you know you put put like a really thick wall on your you know vault and you've put a really thick door but for an attacker to actually get access to what is on the server he doesn't necessarily have to break the vault what he has to do is he has to steal the key to the safe if he has the key then he can just open the safe and he can access the contents of the safe right and if you think about it in in web application terms your server side is like the safe and the client side is essentially the key to the safe right because all the data and functionality which is present on the server is essentially accessed through the client side so if you have a vulnerability on the client side then it is equivalent to you know your client side being your key being compromised to the safe so person can essentially steal all of this data or access all of this functionality without really having to do any hacking as in they do not have to break anything on your server side and again if you think about it 50% of your app is on the client side whereas almost all of your security practices are focused on the server side but on the client side you have a bunch of security problems and in this specific talk we'll be focusing on code execution client-side code execution which is cross-site scripting okay when we say client-side code execution primarily people think injecting JavaScript into the browser right XSS in the name itself you have cross-site scripting so the popular you know idea is that you would the attacker would inject the piece of JavaScript into my page and then he would do some bad things but it's not just JavaScript injection you can have HTML injection and CSS injection as well and these can lead to different kinds of problems which I'll just talk about so when a attacker is able to inject JavaScript into your page and he's able to execute JavaScript in the context of your site on a user's browser then they can pretty much do anything your user can do essentially they can take over the user session perform actions on their behalf and they can also try and steal the user's password by using social engineering techniques and you know you can consider that to be a full compromise of your client-side essentially and if the user is an administrative user if his session is being compromised then you know there are a lot of much more serious things that can happen because an admin user has access to a lot more functionality on the server-side let's say an attacker is not able to inject JavaScript but they're able to inject HTML on the page right so this is a limited form of an attack in this case an attacker is still able to do some bad things for example they can steal sensitive data from the page and if this sensitive data happens to be your CSRF token then the attacker can now impersonate you and they can actually perform actions on your behalf and depending on again what kind of functionality the application exposes this can be very serious and again if I'm able to inject HTML into your site then I can you know write on the trust and I can you know perform phishing attacks by which I can steal the passwords of your users and I can also convince your user into downloading malicious software for example if I'm flipkart.com hypothetically and if I'm able to inject HTML into the you know the website of flipkart.com then I can say hey this is a big billion day and we are giving you a new you know app you can download and you can run this app and if you do this you can actually you know book your products faster than you can do from a web interface and people are more likely to download that exe whatever is being offered for download and because they think it's coming from flipkart and it it could actually be from the attacker and it could be a malicious piece of software these are some examples of you know attacks you have a dangling markup attack so these are attacks where a person can inject HTML and they can actually steal sensitive data in this case they're stealing CSRF token there's another attack where they are actually changing the the URL to which a form is submitted so all the sensitive contents inside this form can get submitted to an attacker's website right and then what if an attacker is able to inject CSS into the page he can again steal sensitive datas like CSRF tokens and they can also perform a limited variation of clickjacking attacks how many of you are familiar with clickjacking attacks okay some of you so clickjacking attacks are essentially a form of you know making a user think that they're clicking on something when in reality they're clicking on some other part of the page so you essentially force trick the user into performing actions that you want them to perform and you know while they think they're doing something else and clickjacking attacks are performed by essentially playing around with CSS on your you know site and if I can inject CSS into your page then I can perform a limited variation of that and you know I can trick you into clicking on different sections of the site which you would normally not click on for example there might be a button which says delete my account maybe I'll trick you into clicking that account and deleting a single person's account is not a big deal but then let's say for example you have spent a lot of money and you know trying to convert visitors to your site into actual users of your application and then an attacker is able to inject CSS and he you know force he kind of tricks you know a few thousand people into deleting their accounts it's a lot of time and investment and money which has been lost right there's an attack called a CSS exfil attack this is a technique by which someone can actually steal sensitive data from the page by injecting CSS so I'm not going to do the details of these attacks I've put them on the slides you can refer to them but I'm just letting you know that these are you know well established and well known attack vectors against you know for CSS HTML and JavaScript okay so now I think that establishes what could possibly go wrong if a person is able to inject any of these three types of data into a page now let's actually see how this happens how does somebody inject this into your site in the first place now XSS has two variants one is server XSS I think server XSS is the most well known variant what happens here is the server will send HTML JavaScript or CSS to the to the browser and in this data which comes from the server is controlled by an attacker right now how does an attacker control the HTML JavaScript or CSS which comes from the server there are two places from which this can be done either whatever data goes in the request the server takes this data and then it puts it back in the response and then it serves it to the to the to the browser and if the server is adding this data in an insecure manner so for example if I send some data on the request and this data is taken and then it's added into the HTML of the page without any kind of sanitation or encoding then you know I can you can actually have attack or control the HTML in the response that comes back the other vector is server site storage for this is also called a store XSS where I you collect data from somewhere it could be from the request or it could be from other places you take this data you put it in a database and then when you're serving a page you take this untrusted data you put it in embedded inside a page in an insecure manner you send it and now you have you know attacker control HTML JavaScript or CSS being served to the browser now this is the most the more popular popularly widely known variant of XSS but then it is not the most common variant of XSS anymore in modern applications this is a talk from Christof Kotowicz he's an engineer security engineer at Google he has recently found or he's at least proposed a solution to prevent DOM based XSS vulnerabilities this slide is from there and as you know Google has a bug bounty program which is if you find discoverer security vulnerability in Google application a bunch of Google applications then they would actually reward you with you know a good amount of a fairly good amount of money in exchange for the knowledge of the vulnerability and then they'll go and fix this issue so he handles the bug bounty program so he has a knowledge about what kind of vulnerabilities are discovered in Google and what kind of vulnerabilities are reported by people on Google infrastructure and his observation is that inside Google DOM XSS is the most common variant of XSS vulnerability you know just because of how modern web applications are written and this is true for most other modern companies as well unless you are writing web applications like you know people used to write 10 years back if you're using modern you know design patterns then DOM XSS is the most common type of code execution issue you are likely to have but unfortunately DOM XSS is not a very well known variant of XSS and even those who know DOM XSS they do not know the depth of you know the different ways in which it can actually happen and in this talk we'll try and look at that okay so in a client XSS so when I say DOM XSS I'm essentially talking about or client XSS these are interchangeable terms so in client XSS what happens is you have your JavaScript engine which you know does a bunch of things and then based on what kind of you know instruction is being executed it will take data and it will either send it to the rendering engine if you say adding something to inner HTML or it will send it to the JavaScript engine again if for example you're doing a set time out or eval call or it will send it to the CSS engine if you're you know trying to manipulate the style now if attacker control data comes to the JavaScript engine right and the JavaScript engine will take this attacker control data and send it to any of these three places then you will have DOM XSS vulnerability is happening on the client side and depending on which engine it sends it to you will have a different kind of an impact you know whether if it's whether it's html injection script injection or CSS injection now how can DOM how can attacker control data actually end up on the JavaScript engine there are a bunch of different ways in which this can happen you have different kinds of DOM properties so these are common ways by which you can actually get interested data into your page that is you know your JavaScript engine can get this data and you have communication channels as well which is you have your Ajax calls you have your web socket messages you have your you know cross window cross window messaging which is your post message and you also have you know more lesser use but then again these are you know features available which is your service and events you have web RTC messages which is essentially your peer-to-peer communication in modern browsers so these are all places from where you can get untrusted data I'm sure because your developers you're already familiar with most of these different kinds of APIs so the application which I was talking about which is DOM code so this is actually available on online it's available at DOM go dot 80 I'll use a local version of that so this has a bunch of information about DOM accesses and it has a list of DOM accesses sources a source is essentially a place from where you can get untrusted data and the all the different DOM property based sources are listed here and their corresponding values are shown now these are called as DOM accesses sources because an attacker can actually control this value so for example if when this page is loaded and in this page if the developer is say for example he's reading location dot href then the value of this property can be controlled by an external attacker and the way somebody does it is they can construct a URL and they can send this URL as a link to you say on a chat or over an email and you click on this link and you open the site now at this point of time the location dot href is essentially the URL of the page and the URL was constricted by the attacker so there is attacker control data you know being returned for this particular DOM property right so similarly you have navigation based DOM property is window dot name I think most of you are familiar which is as you navigate between different tabs as long as I'm sorry different between different pages as long as you are in the same tab the window dot name property remains the same which is I can say if you visit my site I can set the window dot name property and then I can you know automatically redirect you to a different site and then the window dot name property will you know will be the same on when it's being read from the other side similarly document or reference again a navigation based source which is I can I can you know have put the whatever payload I want to put in my URL and then I can navigate the person to the to the you know next page and then in that page when they refer to document or refer you know it'll have a bunch it'll have the payload which you know I had the attacker had actually configured and communication based sources like I said Ajax responses now Ajax WebSocket window cross window messaging these do not necessarily have to be cross site communication which is to say if you're making so if you are say jsfood.in and then you make a call to let's say google.com and then you get an Ajax response so that that's cross site data which is this data is coming from an external source which is inherently you know untrusted data so that is something which an external party can control but even same site Ajax calls when you make a call to your own server and you get the response back even those cannot be considered trusted because you do not know where the server is getting its data from I'll just show an example of that so a lot of people think that they do not really have to worry about DOM security because they are an app only company and to be very I think honestly nobody is an app only company if you really think about it because when they say they are an app only company it means the product that they give to their customers is an app right but it doesn't mean that they do not use any web applications at all especially in companies like this I would say web security is even more important because think of a company like Ola you know hypothetically and Ola primarily is an app based company I don't think anybody uses the Ola portal to you know book anything you all use your apps and the apps are with the users which means the data that they send to the Ola server that is that can be controlled by the users right so let's say for example I'm trying to book a cab and whatever looking if I'm not able to find a cab then let's say this information gets stored in the Ola server so that people could find out in which areas they have hotspots in which areas you know people are not able to find caps so they can better redirect drivers to those places and let's say the Ola app sends the look you know name of the place to the Ola server saying hey in this place this user couldn't find a cab and if I'm an attacker what I'll do is I'll intercept this traffic and then instead of the name of the place I'll actually put a you know a piece of HTML and JavaScript and then I'll send it forward this data will get saved on the Google server I'm sorry the Ola server and then when an Ola engineer who's sitting inside the Ola network right and when they are looking at their portal to see which areas caps you know which in which areas people are not finding caps then that page it might make an Ajax call to you know get the list of these places the server will send a JSON which will have a list of these places and then the JavaScript on this page on this portal it might take this JSON and let's say it adds it to inner HTML of the page right now what will happen is whatever payload the attacker sent from his mobile app will essentially get executed on the portal of an Ola engineer who has a lot of privileges and he's sitting inside the firewall and I say it's even more important for an app only company because in a in a company where they have a public facing website they usually tend to have you know good web security practices because you know they're they're worried that people might attack them but in an app-based company their security usually tends to skew towards the mobile site so most of their security engineers might be mobile security engineers they might not have web security experts which means whatever internal portals they have they're more likely to be insecure and then you know someone come from outside they don't have to do any kind of firewall bypassing they can directly you know try and start stealing data from within your portal okay again Ola here is is just completely hypothetical right because it's just a famous app this has no bearing on the real life scenario in Ola okay now in client accesses there is an indirect form of accesses source as well where you have a attacker control data which comes to the JavaScript engine this information will get stored on the client side in the browser so you have different kinds of storing data on the client side and then in a different section of the site this data is read from this client side storage and then it is sent to these different you know engines so the different kinds of storage you have on the client side you have cookies you have local storage session storage and index db and then you also have html you know element attributes so for example data attributes so what can happen is you can get untrusted data you can then set it as a html elements attribute and then in a different part of your you know page this value could be read and then it could be you know used in an insecure manner so this is an example of an indirect accesses on twitter so here in the url after the hash part whatever data was sent it was actually taken by the page and it was stored it was on help.twitter it was saved in local storage and then if you visit help.twitter.com without the hash then that page was reading this content from local storage and then it was setting it to in a shmr right so which meant that you had untrusted data being stored in a storage mechanism on the client side and then this data was taken from there and then it was executed in a different part of the site so even if you have if you're reading data from your you know local storage or session storage then you should consider them as untrusted data because you do not know from where this data is coming originally okay so those are you know one way in which you can have code execution on the client side which is you have you have data from a untrusted source going into a sync there are other ways as well for example malicious libraries and components in modern applications you are you know using so many external code in fact I would it would be you know not incorrect to say that you know there is more third-party code in your application than code written by your own engineers there are so many libraries which you use for different functionalities and then you have your analytics you have your advertising you know from a bunch of different people and then in for the advertising in other places developers don't really have a whole lot of control for example these are not so much engineering decisions as they are business decisions for example your company might get do a tie-up with some other advertising company and this this is decision is taken by some business folks and then you know you'll have to embed their JavaScript code into your your browser so there are cases where either these companies are malicious or they are insecure which means they send untrusted data or they send malicious data which will essentially affect your site as well because that code is executed executing on your site and you might be embedding third-party content inside iframes and svg images now I'll talk about it in a little detail later images are you know usually something which you know you take from external places and embed them in your site and they can also lead to problems sometimes this is an example where in New York times they had you know imported JavaScript code from an external party and then that code turned out to be malicious and it was forcing people to you know download a virus by doing social engineering kind of an attack so and then they had to issue a public statement for that and with svg now usually images are considered to be harmless they're not executable code they're just meant to look pretty and which is usually the case apart from svg because svg can have a JavaScript embedded inside it and if you think about it if you're if you're you including a library from an external party then in more mature organizations you will have a certain process by which you will have to you know send this through an approval process for example there'll be security engineers who will have to look at this code and say that okay this library is is okay you're using the latest version of the library it is from a popular repository you can use this library or you cannot use this because it looks to be a little obscure but for images it usually doesn't go through this process well most of the time it's not even developers who are you know using images the images come from your designers and you know you just embed it into your site and svg images could have embedded javascript and if a person visits the image directly as if you put it inside as image tag it's all okay if you were to visit this svg image directly in your browser then the embedded javascript will get executed and it will have you know access to all the client-side functionality okay so I think with that I've quickly gone through the different ways in which you can have client-side code execution from you know what are the different places from where you can get interested data now let's look at how it can be prevented right how whatever we discuss can be secured against when we're looking at prevention there are four ways in which we can do this I'll go through this one by one the first one is content security policy how many of you are familiar with content security policy okay how many of you have actually applied content security policy on your you know domains okay a few of them that's good now content security policy you can think of it like a firewall for your browser would anybody host your app server or web server without a firewall is anybody brave enough to do that raise of hands without a firewall nobody does that right even if a company is hopelessly insecure they'd still put a firewall and uh hey uh does that mean I have less time you rang the bells I have 15 more minutes okay thank you okay so uh so everybody on the server side you would definitely put a you know put your uh server behind a firewall it's it's the it's the bad minimum you can actually do and uh content security policy you can think of it like a firewall on the client side which will protect you against uh you know code execution vulnerabilities so again it just makes common sense that you use content security policy on the client side now just uh putting content security policy doesn't just because you put a firewall doesn't mean you know you're good uh if you put a firewall and you open all the ports on the firewall it's as good as not having a firewall at all right so you put a firewall you will have to do a little bit of you know common sense based configuration to make sure that the firewall is actually doing something the same way in a content security policy you can configure it so that it at least gives you a certain level of protection you can configure it to make it really secure but then in practical cases at least you can have a configuration where it gives you some level of protection against you know these kind of issues and if you have to start by you know to protect against the client side then i would recommend you start from content security policy because it gives you the highest return on investment for the time you will actually put in because any other form of protection is a continuous process because you're continuously writing code so you will have to ensure that the code is securely written that it's free of vulnerabilities and so on so whatever process you have has to keep happening you know as you're writing a new code but content security policy is something you can put once let's say for example you spend a week or two and then you set it up once and as you're writing new code whatever you've already set up the firewall you've set up will continue to give you returns on you know all the new code that you've written let's say for example you write a code after three months that has a vulnerability this firewall will still give you you know a little bit of protection against that so if you have to start somewhere i'll say you start from here first set this up and then you go and do other things okay so again like i said with firewalls the configuration is the key it's about how you configure it not the very fact that you have put a firewall so the most secure way is in content security policy you can set a directive which is script src self so this means that when your page is being rendered by your browser your browser will essentially ignore all inline javascript so if you have put an event handler in a you know say an elements on click attribute you have embedded you have you know put some javascript hardcoded there or you have the script tag and you've written some javascript code inside it all of that is ignored by your browser the only javascript your browser will execute is script which is loaded with the script src you know directive and this javascript file must be served by your own server as in the domain name must match the domain from which the page was originally loaded right so this means that you have essentially in some ways you're whitelisted which javascript is considered to be you know considered to be legitimate so you're telling your browser hey you only execute this these javascript content so whatever javascript an attacker injects into your page will get ignored by your browser right so it does not execute at all and if for example your all your javascript files not if in most cases the javascript files are not hosted on your own domain you have you have javascript code being fetched from or referred from external sources like cds and so on in those cases what you can do is you can explicitly mention the name of the domain from where you are you know you are loading your javascript content and when you do that try and be as specific as possible for example if there's a cdn and all your javascript content is inside a specific directory of the cdn then don't just give the domain name of the cdn because there could be other people who control other directories so try and be very specific you know try and give the path to the exact directory from where you are loading this you know javascript file okay now the first option is probably the most secure if you put that in place then you know you are pretty much taken care of code execution javascript code execution at least but that's not practical in most cases so when you have a scenario where you do have to execute inline javascript code then there are ways to whitelist that as well you have the you know you have two approaches one is you can add a nonce so for this for the let's say for example you have an inline script tag you can add a nonce to that script tag or you can add a hash to that script tag and in the in the header that's being sent the content security policy header you will have to give the same nonce as well right so essentially this is a different way of whitelisting so in this case you tell the browser hey you can execute inline javascript as well only if the inline javascript is matching whatever signature i am specifying right so this means that an attacker who's able to inject javascript he doesn't have this information and so he cannot you know specify the nonce and which means his javascript will not be whitelisted and it will not get executed by the server so this way you can whitelist your inline javascript code as well okay but what if you have to load javascript dynamically which is you have a javascript already written and this will at runtime create a new script tag and then it'll start loading javascript files so in this case what you can do is you can use the script dynamic tag so what this does is it will you know you you initially whitelist whatever javascript is embedded hard coded into the app either through script files or through inline javascript and after that you say whatever other javascript which is loaded by this whitelister javascript i trust that also right so it's a transitive trust model it's kind of like a relay race which is you give the bet on to the first person and then they can give it to another person and you know that is trusted and they can then hand over the trust to you know somebody else so with this you can still protect against server side accesses but this doesn't you know protect against client side accesses but again if you have to choose between not using csp at all due to the way in which you load javascript versus using csp you can use this so that you have some level of you know protection still going on okay now csp is very simple and concert but then again when you're implementing it things can get out of hand for example you know you're not just loading external content from one or two domains for example there's a csp policy from twitter you might be loading it from a lot of different domains and then it just becomes you know too chaotic and whenever your configuration policy becomes very complicated then you tend to make mistakes in managing them and you know you might have untrusted domain slip into it as well so what you can do is you can have a csp policy but then have the assumption that someone's still going to bypass it and you know they will perform code execution so what you can do is you can try and use csp to also limit the level of damage a person can actually do like for example in a firewall you can put inbound filters so that a person cannot get into your network you can also put outbound filters so that if a person does get into your network and they have stolen a bunch of data then they'll have to get out of you know the network as well and if outbound traffic is blocked then an attacker is not actually able to take your data and run away so these are some ways you can actually with which you can actually do that here you can say a form action self means you are essentially telling the browser that html forms can only be submitted to the same domain they cannot be submitted cross domain and frames you cannot load iframes from different domains and connect src is essentially for all your communication apis so it says your ajax calls your web socket messages and all of that they can only be made to the same domain which means an attacker he's executing javascript he's able to access the contents of the page but you're making it difficult at the very least for the person to send this data you know outside from the page but say for example this was a vulnerability an attack I showed earlier by which a person can actually you know steal the contents of your html form but with csp this attack will not work anymore but then again like I said csp doesn't mean that your issues are taken away like completely taken care of this for example is a bypass for the same attack again these are on the slides you can refer to it later so the person did a slightly more complicated attack and he was able to bypass csp directive so even if you have csp you know people are still going to bypass it but then at least you make it relatively difficult for them to do okay and then the other thing to do is make sure that the vulnerability does not occur in the first place which is you manipulate the DOM in a more secure manner how many of you are familiar with SQL injection vulnerabilities here most of them right so what is the how do you prevent against SQL injection encoding okay anybody else parameterized queries right so parameterized queries is the you know is the is the right way to protect against SQL injection encoding you might do when your logic is such that you cannot write a parameterized query you know you'll have to construct the SQL query from a string only then maybe you can use encoding so when you're when you're controlling DOM the way in which this particular html element is created it's similar to you know constructing a SQL query with just adding strings together and user control data and then you send it to your SQL API which is a really insecure way to do that instead you can use the parameterized query way which is you can construct the DOM more securely which is you use the right APIs for doing that instead of just concatenating a string and setting a dinner html you can do you know like create element and then you can add the attribute separately and then whatever user control data you have to add you can add it to the inner text attribute so that it doesn't get treated as html and with this you probably have performance benefits as well i'm a security guy so don't quote me on that but i would assume you know that would be the case okay and like with SQL injection there are complicated scenarios where you cannot use parameterized queries and you will have to construct the SQL you know query from strings similarly in your DOM as well there could be scenarios where you cannot construct the DOM that way or you have a lot of legacy code where they're just you know adding strings strings together and they're setting it to another html you cannot just go back and re-architect everything i don't think your manager is going to approve that so in places like that what you can actually do is you can encode the data before you add it to the you know string so there are well tested libraries available for doing this you have isapi for js you have the jQuery encoder plugin these are libraries which have been written by the security communities and they've been extensively tested by the security community as well so you can you know you are you're in very good hands using these libraries so they have different kinds of methods now when you're doing encoding encoding is very you know context specific you can think of it like you know speaking to somebody like for example if you're from Tamil Nadu then I can speak to you in Tamil it'll make sense to you but if you're from Karnataka I speak to you in Tamil then you know you might it might just sound like gibberish to you so when you do encoding you will have to encode it for the proper context otherwise you're not really doing much in terms of security so depending on where you're putting this data for example if it's going to go into the place of a URL you can you can encode it for URL context if you're going to put it inside an HTML attribute you can encode it for HTML attribute context and so on now here even though you have the ability to encode for JavaScript and CSS I would still recommend against doing that try and see if you can design your application differently so that you never have to essentially you know put a user encoded data directly inside a script tag for example instead of putting something inside the script tag what you can do is maybe you can put it inside a data attribute and then from the script tag you can read this data attribute element so you can do a HTML attribute encoding put it in a data attribute in some other element and from the script tag you can read that value of the data attribute rather than you know embedding it directly inside the script island okay and for the malicious and vulnerable libraries what you can do is you can ensure that your libraries are up to date you're not using any outdated libraries these are very common you know best practices and if you are going to use an external library right let's say for example there is there's a certain functionality you need you found this in one library which was written by somebody some six years back and you know it has not been maintained after that you do not even know this person you know you don't know if this library can be trusted but the functionality is very is very unique and you actually need this functionality in your in your application let's say so what you can do is rather than include that library into your you know into your page using a script source what you can do is you can create an iframe and you can sandbox this iframe which means the iframe has very limited access it cannot access your DOM and you can load the script element inside this iframe okay and you can expose it like a library so you can have a cross window messaging where you can take the user you can take the data you can call and you know send a message to that iframe the iframe will call that library do whatever action it has to do the results can be sent back to you using you know a cross window message so this way you are using that external library as well at the same time you're not exposing the contents you know to that library so think of it like you know you have random people walking on the streets and you want to talk to them it doesn't mean you directly take them into your you know room and like house and give them full unrestricted access what you will do is you will probably take them to a coffee shop or something and you will do your discussion so you know this is similar to that you put them in an iframe and then you know you do your transaction through a cross window messaging and maybe once i finish this we can do that and sub-resource integrity which is if you're if you're loading external resources you can use sub-resource integrity by which you can give a signature for this resource and if that domain which is serving this resource gets compromised and then if an attacker is able to change the contents of that resource your you know browser will not load it because it fails the integrity check and finally for svg images serve them from a separate domain if possible so that you know the javascript doesn't have access to this domain's contents and set an csp header so that you disable all inline javascript and finally if you if both those things are not options the least preferred option is you can set the content disposition header to attachment so that if somebody visits this svg file then it downloads on to their site on to their laptop instead of you know rendering on the page and executing the javascript right so with that i have come to the end of the session i do not know if i have time for q and a i'll let there's a join q and a okay perfect okay thank you guys so that was that was all i had thank you