Hello and welcome to secure JavaScript programming with Vladimir [inaudible]. This is the last video on the XSSs and remote coding diction course and I have to admit it's my favorite one. In this video, we will be talking about trusted types. Before you watch this video, make sure that you have watched the content security policy video because we will use that and we will use also the syncs discovered in the SCE video remote coding diction under that syncs video. Make sure to have watched the role XSS course before coming here. Trusted type is the cutting edge technology to fight XSS and remote coding diction in the browser. This won't apply to NodeJS yet. Here I've got a simple page. If I check how it has been loaded, I can see that it has a specific content security policy that contains require trustee type for script, but also a value with trusted types logPolicy. We will focus on the second one, trusted type logPolicy. What could that mean? Well, I have created a trusted type policy and I named it logPolicy. It will make sense in a few minutes. Just hold on until that. What does that mean? That means that if I tried to do eval and then counsel.log hello from eval, I actually get an error that tells me uncaught eval error refused to evaluate a screen as JavaScript because it's documentary requires trusted type assignment. That's weird. Document that gets ElementByID. Of course I don't have any element with an ID here, so let me create one pretty quick. Target and let's comeback. Target equals enter I get.inner HTML equals, and now we fail again and we have, failed to set inner HTML property and elements. This document requires trusted HTML assignment. Let's try one last thing. Script equals document to create element script. Script that src equals. Well, once again, this failed, We see failed to set the src property on HTML script elements or document requires trusted script assignment. That means that three of the main syncs for XSS and remote code execution right now have been somehow disabled. Let's go in depth to understand what I did. Here, you can see that I am also loading the script named policies.js. If we check this script, I create a policy with a trusted type API. As you can see it, so cutting edge, that WebStorm does not yet know about these methods. I call trusted types.create policy, and the first argument I pass is a string that will be the name of our policy. We can have multiple policies in the same document, and in that case, we would need to tell trusted types here that we allow another policy and both of them will become available. Let's allow only logPolicy and let's also create a new policy together. We'll create a new policy, so to recall, all other policy. For create HTML, actually, we'll just allow STR. CreateHTML is a method that we can define. It will be called with the strings that needs to be put as a value for innerHTML or outerHTML. We can have other arguments, but I won't go into details about them right now. It can either return a string that will be the actual string used for innerHTML thing, or it can throw an exception to prevent. It's to createHTML, and it will return str.replace. Now we want to replace this character. Let me quickly check my regex because I don't have my regex mind ready right now,.replace. That's right. Replace all of these ones by an empty string. We'll prevent loading tags. Same thing for the closing ones. That must be a regex. I don't know why I put too many string managements today. Put an empty string. This one will actually replace HTML tags by something else. In the real life, I would recommend you use a library such as DOMPurify, if you want to do that. CreateScript. Well, I want to prevent all script creation, so throw new error, don't create scripts. Now for createScriptURLs, we will do the same thing. Don't load more. Here we are. Now we've got this other policy. What it will do is that, when asked about sanitizing HTML, it will just replace the tags by things that are not HTML code. When asked to create a script it will refuse, and when asked about creating a remote script, it will refuse. How do you use that? Well, you've noticed that I have actually add that to the global scope, so we can get them. I get an error. Remember, I said I would only allow the first policy, the load policy. Here, we tried to create the author policy. It's not in the list of load policy. It refused to create it, and we got an error. That what was expected. Now, let's allow this. Restart, and now it's happy. Let's try to get our target, document, getElementById , target. I get it. Here it is. Now, let's do, again, target. Oh, Vlad, why are you here? Sorry, I'm going in the right-hand side, so I don't block this view. Target.innerHTML equals b, hello/b. This fails, again, because it violates the policy. How do we use that? Well, at this point, we need to get the policy. On this policy, remember, we created three methods; createHTML, createScript, and createScriptURL. Because we want to create some things that will go in an HTML things, there are three kind of things; HTML things, script things, and scriptURL things. We will do createHTML. Then we will place our string. Let's put that in a new variable. If we look at this value, we see that it's a trusted HTML object that has a value. Now we realize that my RegEx was poorly made because it's terrible at sanitizing stuff. That's why you should use [inaudible] and not the code I give you here. If we were in target, inner HTML and put new hello there. It will actually work. Each will be accepted because this thing is going through a valid purifier function, a very trusted type, cleaning up policy function. We are able now to make sure that in case of XSS, you have the control. It's not possible to change the value of a policy once it has been created and it's not possible to use a policy that has not been defined in the content security policy. Let's say that you want to create a custom script to decide the URL of a target you can load. Let me use my other policy, creates scripturl, which builds something here. It actually throw an exception because we wrote that we want to throw an exception. However, we can do new URL, strURL. Let me try that user browser first. Yeah, new URL, then we get the protocol and host. We could do something if URL that host is not equal to local host, sorry about that, sticky fingers, throw new Error invalid host. Here we can do return strURL. Let's start that and I will do document.otherPolicy., I always need to copy paste them because I can't remember the name of this function for the life of me, /cdn.O. Here it actually fails because it's an invalid host and we get the value we put. If I put localhost, it will work. Now I can use that to dynamically load new scripts in my page. Let's sum up a bit. You can define custom policies only once and you can't overwrite them. In all policies, you can define something for custom HTML nodes, custom scripts to evaluate, and custom scripts to load. Then when a policy is enabled through a content security policy with an entry named trusted types. When this is enabled, well, it becomes impossible to use inner HTML [inaudible] or script data SSE from JavaScript without first of all going through a call to the policy. This means that even if someone managed to run arbitrary code on your page, so you won't be able to load untrusted thing or to inject new nodes dynamically. This is the real way to prevent [inaudible]. This is still cutting edge technology and pending a lot of pros or adoptions. It's a technology developed by some of my very good friends at Google and I really recommend you take a look at the specification, it's not that bad. Thanks so much for watching this video. I hope it was clear enough once again, this is very cutting edge technology in web security and you will be able to say that you learned it on Infosec Skills first. Thanks a lot for watching it, have a great day and see you soon.
