PG - Securing and Trusting Third-Party Javascripts in Your Web App

hey everybody it's guy mcdoodfellow co-chair of the b-sides las vegas proving ground track our next talk is securing and trusting third-party javascript in your web app by krishna mamila who was mentored by gabriel ryan okay hello everyone thanks for joining this talk about securing and trusting third-party javascripts um so in this talk we are going to talk about the security of third-party javascripts uh the risks and mitigations on of these third-party javascripts and um also when as a security team when you are reviewing these javascripts how to think about securing how to think about keeping all the stakeholders happy and also making sure that these third-party javascripts are secure here's a quick look at the agenda we are

going to look at the third-party javascripts um and how they are used we are also going to discuss the risks of third-party javascripts uh then discuss how to secure them we're also going to look at how tag managers are hard to secure uh finally we are going to conclude with key takeaways uh we'll start with intro and the definition of third-party javascripts uh first a little bit about myself um i'm working as a security researcher in product security team at adobe i've been in apsec for the last five plus years uh also i'm a new dad my newborn is using up all my energies so it's definitely um hectic right now uh outside of security uh i love three

hour plus hikes uh recently i've also started investing time in understanding business models of different companies and also started learning about how cryptocurrencies and blockchains work um i also sometimes go out for a run if it's really nice outside if not just spend some time doing yoga uh this is a little bit about myself uh uh diving into the topic of this talk uh what is a third party javascript right uh most websites today include content from other sources often called third parties as shown in this figure um third parties might provide anything from article content to avatar images to embedded videos these are fetched on to the webpage with the help of a javascript

and the owner of the web page has not written this javascript so the definition here is that a third party javascript is a code that is being served from third party servers and is not under the control of webpage either as mentioned before these scripts are used not only for fetching content like images or videos but also for analytics ads or even for some helper libraries uh one good example is the social sharing buttons from facebook and twitter facebook or twitter provides you with a javascript that you can embed into your website and then when you run the website you'll see the buttons on your site so that is um the definition about third party

javascript now let's look at how third-party javascripts are included in a in a web app so how do you include these scripts there are three popular methods uh the first one is the script tag source attribute it's a html uh script tag uh and then uh the second method is using a tag manager like google tag manager or adobe dtm uh the third one um is also is to include the third party javascript in a script tag so this is like the most straightforward method uh let's now look into each of these methods in a detailed manner uh the first method is the script tag source attribute um using the script tag source attribute um

is very easy you just use the link provided by the third party and during runtime the browser will send a request to the third party server and will load the script for the app to use its functionality and here's the sample code this is how it's embedded as you can see the script source attribute has the vendor.com script.js so during runtime the browser will send a request to the third party server vendor.com to get the script.js it's as simple as that and here's an example from adobe.com as you can see adobe is using iperceptions.js here and then it's also using some javascript for google ad services and also it's using tiktok javascript which is interesting

and all these are included with the script tag source attribute um and that is why i have shown here uh the next method is the tag manager method but before going into this method uh let me just spend some time um discussing about tag manager and what is a tag manager right uh just like your content management system manages the content of your website a tag management system uh manages the tags um which will allow you to insert bits of javascript such as like the google analytics tracking code and all that um typically tag managers offer a web based interface to choose edit and manage those tags when they are included in your web pages

um so like for example if there's a uh non tech savvy uh marketing folks in your in your company who are like uh trying to embed uh like javascript into their into your apps web pages uh that's when they can use uh something like google tag manager uh and with like a click of a button they could just um like they could just embed um whatever javascript they want to embed into your app uh for example if they want to track how where the users are clicking uh on your app that's when they can just add that with the click of a button and then your app need not be deployed again and all that so there are so many

advantages for this and here's a script from google tag manager uh we let google tag manager know that we want to load some scripts like google analytics facebook like button and a youtube video and google tag manager generates a script for us to use in our app uh this script can be embedded into your app and it takes care of running all the scripts during runtime so as you can see here in this code you don't see any of those scripts right so you just see that you just see that um the code is trying to include like script uh element d dot create element is uh it's creating a script element and then it's creating uh it's it's

adding the source attribute to that element and then the source attribute is talking to google tag manager.com server and it's pulling the gtm.js script and this script will have all the other scripts that your marketing folks or even developers wanted to include in your app so it's as simple as that and javascript always changes because whenever someone like tries to add more javascript or remove the existing javascript that's when the javascript changes but this script won't change much um and this is the most popular method um as i said among marketing folks and also developers because uh they don't have to redeploy app every time and there are many advantages to this method um as i briefly touched upon before uh

let's look at them in more detail so the the tag management tools as i have mentioned before uh they separate the process of adding and updating um like the tags from the process of altering your site's code so really we don't have to make any changes to the code to add a new javascript tag um and can do this with the click of a button from the ui um so this is like a really great advantage and tag management tools also help keep track of all the added tags uh this ensures that the tags are properly organized and the same tag is not added twice so that reduces mistakes during development so for example um you have already added a tag and um

you you forgot about it and then you add and one more time the same time that's when the mistakes happen so these mistakes can be uh definitely avoided with the tag manager and tag manager tools also offer built-in debugging testing and preview tools um for when a javascript is added or removed or edited on a web page so that is also another advantage and additionally these tools also offer version control uh to keep track of changes and finally like all good tools uh these tools allow admins uh to specify who can view edit and publish tags so any user who who has access to these tags only can um change or view them so which is also

great so yeah these are some of the advantages of why people use tag manager and why they are becoming more popular these days um and moving on to the uh next method of including third party javascripts uh this is the most straightforward method you just get the script from the third party and embed it into your page in between script tags um as you can probably guess your app won't be loading the most up-to-date version of the script so you'll have to update and deploy your app whenever you want to update the update to the latest version of the script and the code is pretty straightforward you have a script tag instead of using the source attribute you just

copy the code from the vendor um or any third party and then paste it in in between the script tags and then the code will do what it's supposed to do um this is also the most secure method because um you know what you're including in the page uh and this third party won't have control over um over the code but again as i mentioned there's a disadvantage also you'll not be loading the most up-to-date version of the script and up until now we have seen what's a third-party javascript and how it can be used now let's look at some of the real-world hacks examples uh that happened because of per third part third party javascript

security uh the first one happened like this it looks like uh the vulnerable vulnerable website included a javascript library um in a webpage and this library was pulling javascript from a hacked server uh the javascript fetch from hack server is malicious and is prompting the users or victims to install malware um easily they could do more to the uh users like stealing of credit cards or personally identifiable information etc uh but in this case they were just prompting the users to install malware um and really all the sites that are possible with um all the issues that are possible with cross-site scripting um are also possible with this sort of vulnerability another attack that is in the news is

the mage card attack this is a very popular attack and shows how thousands of apps can be attacked at once uh the attackers target third party scripts being used in checkout pages and by targeting and compromising these scripts attackers collect credit card numbers of the users since many checkout pages use the same script uh compromising one third party script is enough for attackers to collect credit card numbers from thousands of victims um here's the flow from the image so first uh vulnerable web apps fetch the manual javascript from a hack server that is the first step and then the malicious javascript sends the credit card info to the attacker whenever the users are using this

a vulnerable website so um all this all this happens without the users no noticing any issue and it's not just users who won't be able to notice an issue even the web app owners won't be able to notice an issue with the app um and um unless they go into the browser console and see where the uh requests are being made so so that is why this is like a really dangerous attack um and up until now we've seen what a third party javascript is how they are used in a web app and some real world hacks that happened due to poor javascript security uh now before looking into risks of third-party javascripts um and their mitigations let's understand

what a dom is typically html elements in a page can be nested allowing us to consider a web page as a tree of elements the tree of elements is called document object model dom for short and as shown in this image html element is the root node and it has two child nodes head element and body element and the hierarchy continues like for example the body node again has like two children that is nav node and section node and so on and so on um and one major advantage of arranging all the html elements in a tree format is that it allows uh javascript to programmatically access and manipulate the tree of elements and this is what um

what makes a web page more interactive javascript accessing and manipulating the html elements so um so really if you think about it javascript is the one that decides or javascript that is running on the page is the one that decides uh what the user sees and what domains it can interact with and all that so whenever user enters something uh the javascript can decide uh it can take that um information that the user entered and then it can ship that information to a third party or even to the owner of the web app so that's how the dom works and that's why the um that's why the html elements are arranged in a dom format or a tree

format um so yeah like um let's take just showing you where we are in the in the talk so up until now we have seen all the uh real world attacks now um we're going to discuss a little bit about the risks of these third party javascripts in your apps um all these risks are on the client side because a third party javascript is executed on the client side the first risk is that a third-party javascript gets full access to dom if embedded in an unsafe manner a full access to dom means arbitrary code execution privileges on the client side as i mentioned um we have discussed a little bit about dom so if if the third party javascript has access

to the dom that means it can execute whatever it wants to the second risk is that we also have the risk of leaking sensitive information to third parties uh like in the mage card attack third parties or um attackers could get sensitive information like credit card numbers uh personally identifiable information etc um and the final risk is that the third party controls changes to the script that means they can change what they are executing on your client side and what they are collecting from your users so initially you might have reviewed the code and you might be like okay this is this is um not harmful but this is not doing anything um dangerous on my web app so i'm gonna

include this javascript but then once you include the javascript um then it can the owner of the javascript can change the um content of the javascript um and what it does on your web page so so yeah these are the main risks with the third party javascripts um and now that we have seen risks let's talk about how to mitigate these risks uh and before discussing the mitigation techniques uh let's talk about content security policy for a bit um and content security policy is an additional layer of security that helps to mitigate attacks like cross-site scripting information leakage etc and this is more of a browser security feature but server has to tell the browser what

to secure and a popular way is that a server sends a content security policy um directive in a content security policy header uh as i'm showing here there's this content security policy uh header and then there's this directive default source um and then there's a domain which is example.com um and just uh to talk a little bit about this default source directive this directive tells the browser from which origin all the content of the webpage should come from so here the browser the server is telling the browser like hey only load the content that is coming from example.com or execute the content that is coming from example.com um and based on this if the browser sees

a request to fetch um a javascript file from malicious.com um the browser won't send the request because uh the content security policy didn't say so um so it's as simple as that and there are more directives like this for example there is a script source directive which tells the browser to um from which origin the uh javascript files are to be loaded and there's also another directive which instructs the browser uh to which domains it should make a request to um so there's so many browsers uh so many directives which you can look into and learn more about content security policy and content security policy is uh important for our first mitigation technique and um uh so now that we got

content security policy definition out of the way let's look at the first mitigation method so the first mitigation method is to use content security policy with the nonce um and nonce is a pseudonym for a number used once so the nonce changes every time and script source directive of a content security policy tells the browser to load scripts from a specific domain or if a certain condition is met as i have just mentioned before uh there's also where in the directory you can also specify only load the javascript if a certain condition is met not just from a certain domain and whenever you have a nonce in a script script source directive of a content

security policy all javascripts on the page must have the nonce attribute with the same nodes for these javascripts to be executed um so for example um as you can see here um like this script source directive um has like nonce random value um and in the page if you see like script tag if the browser sees script tag and if it sees nonce random value then it executes the function which is kittens in this case but if it says if it sees the script tag with the non other value then it will not execute the function evil so this is great because all the third-party javascripts will have this nonce random which is only known to you and if the attacker

tries to have like a different knox value or i mean attacker won't be able to guess the bounce value in the first place and if the attacker has some other nas value uh nonce value then that will not work um that will not execute the script the browser will not execute the script um this is a good first step towards the third party javascript security uh but it doesn't validate what the javascript is doing um but it's more like telling the browser that we trust this javascript and it can be executed if the third party who is the owner of the javascript decides to change the javascript we won't know that and script still gets

executed the third party server is hacked and the javascript is changed to do something malicious on the websites it is executed the javascript still gets executed as i said this is more of like a initial check on the say telling the browser that okay we trust this javascript but it still exposes us to uh risk um moving on to the next mitigation technique putting a third party javascript in an iframe um is a better solution than the than the one that we discussed before and it won't give access to our page dom um if you think about it um accessing the dom is the biggest risk and so it will definitely eliminate that risk um because um iframe will be given a

different dom uh even if it's in the same page and so that that is that definitely is um secure so mostly mostly as a security team we are comfortable with this uh solution but um modern javascripts especially those that do analytics or tag management they need access to the dom and solution to put this javascript in an iframe won't go well with the development teams um and the final mitigation uh we are going to look at um is the sub resource integrity uh the javascript is put through a hashing algorithm and the resulting hash value is used in the integrity uh attribute of the script tag uh so as you can see we have the script tag here

um the source attribute um is telling the browser to load um javascript from cloudflare cdn and um there's the integrity attribute the integrity attribute um is where the developer puts the javascript that he that he or she knows um and the the the javascript is taken and put through a hashing algorithm and then the hash value is hash value is added to this integrity attribute and the hash algorithm being used here is sha 256 which is fine and during the run time the browser fetches the hash value fetches the javascript and then it puts the javascript through the same hashing algorithm and then calculates the hash value if the hash value matches that's when um the the script is

executed if the hash value is not matched the script will not be executed um so if you uh and and also the browser will throw this error in um you know in its console so if you think about it this is like a great mitigation um it ensures that only scripts that we have reviewed or executed um ideally you would have reviewed the script before using it in your app so so yeah that this is a great mitigation technique and but still um do you think this is like an ideal solution in an ideal world yes this is this is an ideal solution um but let's look at why it's sub resource integrity might not be a good

solution uh especially when it comes to dynamic javascripts like the ones uh that we get from tag management solutions uh subresource integrity works great for static third-party javascripts and modern tag managers dynamically change the script this is something we have already looked at so the javascript the container script is same but the javascript can be changed at the click of a button so it changes um very dynamically um so tag managers hello like as i mentioned before tag manage managers allow even non-tech savvy folks to add different scripts with the click of a button um and this means that um scripts are changed dynamically right so when the scripts are changed dynamically we can't use subresource integrity and

this is the point that i'm trying to get it because using sub resource integrity means that whenever a script is changed the integrity attribute also has to be changed that means the app has to be deployed again um deploying the whole app for minor code changes is what we are trying to prevent with tag managers and but with sri we are back to where we started so so so the development team says um we don't want to use sub resource integrity and iframing the javascript also uh doesn't work for us um so what do we as a security team do in such scenarios in such scenarios we ask the team to use content security policy nonce as a good

first step additionally we should understand where the script is being used if the script is being used on a sensitive page with password change functionality or checkout functionality then we usually recommend them to not include the script in those pages but if it's being used in other places where future script changes or sensitive information collection is not a big deal and we trust the third party uh then we should be good and by trusting the third party i mean if we entered into a contract with them and reviewed their security practices and security posture then that's okay uh this is where your vendor security team and legal team comes into play and reviews the vendor

it also helps to educate um folks who are using um the ui of the tag management systems uh mainly because um they could be adding any javascript into the into the web page right so uh it's definitely um it definitely helps to educate them about the risks of this and then make sure that for most of the changes um they review that with them with someone with a security knowledge okay uh concluding the talk with key takeaways um the key takeaways are third party javascripts are risky as evidenced by the recent hacks and the risks i have outlined but these risks can be mitigated with the mitigation techniques we have discussed and sometimes it's not

possible to mitigate these risks especially in the cases where the script needs access to the dom and is dynamic uh in such cases we assess the risk trust the third party and accept the risk um and yeah thanks everyone for joining this talk i would like to thank take this time to thank a brian who helped me with this talk if you have any questions happy to answer them thank you