So we've run our JavaScript on this page, even though the page is looking for script tags and disabling them. So this page is vulnerable to cross-site scripting. This means that a malicious user, who has access to modifying these pages, can inject their own JavaScript into the site, run it, and then attack your other users and do whatever they want, essentially. So how do we fix this? Well, let's jump over into php artisan tinker, because it'll be much easier to demonstrate the problem and look at the ways of fixing it, than if we're trying to do it through the browser and refreshing the pages all the time.

the problem and look at the ways of fixing it, than if we're trying to do it through the browser and refreshing the pages all the time. Let's jump over to Tinker. Okay, so here we are in Laravel Tinker. Now let's run our original test and see what happened with our script tags. So go to String, Markdown, Script, Alert, Boom, oops, I'm going to run that, and see we have the script tag here, but we can see that the angle brackets have been escaped, they've been replaced by the HTML entities, which is why it was displaying the text of the script tag rather than executing the script. But we already knew this already.

So what do we do about this? How do we solve this problem? Well, this is where it is useful to know your tools and know what you're using. So frameworks like Laravel provide a whole bunch of different tools out of the box for you, but internally, they use other tools, and the Markdown in Laravel is no different. It actually uses the PHP League's Common Mark. So let's jump over to their website, and there is a security page on there we're going to have a look at. Okay, so this is the PHP League Common Mark security page, and this tells us about the security features of the Common Mark Markdown compiler that they provided, the Markdown

Okay, so this is the PHP League CommonMark security page, and this tells us about the security features of the CommonMark Markdown compiler that they provided, the Markdown package they provided. And as we can see here, it gives us three different options that we can provide. So if we're allowing untrusted users to provide Markdown content, provide any content that goes into Markdown, then we can use these to manage what happens and secure the output. The first one is the HTML input, let's scroll down a little bit, and we can see here there are two different options for it. So we can either provide escape or strip, and we can look at their example here, we've got the Markdown converter, we've got the HTML output escape option here, and then

server. So that's quite important too. So let's jump back to our command line and then look at our markdown command and add in the two main ones we've got up here, the unsafe links and the HTML input, and we'll see how it behaves on the app when we get out of here. Okay, so we're back in tinker. Now what we're going to do is we're going to use the line we just used there, but we're going to add in our options. But you might be asking, how do we get those options in there? Do we really need to set up our own instance of the common mark converter and then run

But you might be asking, how do we get those options in there? Do we really need to set up our own instance of the commonmark converter and then run that? Well, no, we don't. Laravel makes it easy as it does with a lot of things, and we can throw the options in here. So what we can do here is we can put in the htmlInput option, then we can go escape. And then what this should do is fully escape any of the HTML that is in the input. And as we can see there, it's come out. Now we have both the angle brackets are now being turned into HTML entities.

Now the other option you've got here is strip. And strip removes the HTML entirely, and as you can see there, we now have an empty string, because the whole thing was HTML. If I went back in here and I added in, like, hello at the end, we will now just have hello, because that wasn't an HTML tag. So strip is useful if, say, you're displaying information to the public and you don't want random characters to be displayed if someone is trying to attack something. It really depends on your situation and your application as to which of these two options you want to use. I personally would go for escape rather than strip, because then you can see what's going

you want to use. I personally would go for escape rather than strip, because then you can see what's going on. Especially if you have inputs that come from a user, but say administrators are seeing, or more privileged users are seeing, then you want to see if the user is trying to inject something, is doing something dodgy, so that you can talk to them or figure out what's going on. But it's entirely up to you as to how you want to do it in your app. So that's HTML Input, which has got the escape and the strip options there. And the other options that we have are, we've got the allow unsafe links, which we can set

and the allow unsafe links, false. There's also the max nesting level as well, which you can add, and it's a good idea to add for resource limiting purposes. It's not as important from a security point of view, I mean granted someone could use it to take down your site if they wanted to be malicious, but in terms of blocking cross-site scripting, then these are the two that you need to worry about. So let's take these and implement these in our page, so that we can protect this user input from displaying cross-site scripting and protect our users. Okay, so here we are in our escape description attribute, and as we can see, rather than doing the markdown static function on the string class, we're actually doing the string

Okay, so here we are in our escape description attribute, and as we can see, rather than doing the markdown static function on the String class, we're actually doing the string of the markdown in the chain. But the method is exactly the same, regardless of which one you're calling, we can just pass the options into the method here. So we're going to paste our safe options in here, so we've got HTMLInput, escape, allowUnsafeLinks to false, and then maxNestingLevel to 5, which should lock down the output to prevent any cross-site scripting, as well as resource abuse, essentially. So we'll jump back over to our code, sorry, to the browser. Okay, so we're in the browser, we're at the page we had before, where we had our broken