Hello and welcome to secure JavaScript programming with Vladimir the to camp. In this video where we talk about done based excesses. So you remember about stored excesses which excesses that are stored in the database service side or something like that. You remember about reflective excesses, that excess is rendered by the back end by the server on service side based on the incoming request. Well how do you call an excess is when the world vulnerability can lie in the front end in the web application in the browser, what it's called the dumb based excesses. So here we've got a simple html page that loads script says hello you and when you click on the button named, click me to open the Pandora's box. That's definitely not suspicious, each will called a script that fetch user. So here in that case it's here to simulate a call to the back end application to the back end. Api that could be in point get me that could be any endpoint, that return data. That is actually a variable from the back end that could be reflective or stored from the front and websites from the front end application point of view. The source of the data does not really matter, so it could be a reflective done based excesses for the, for the case when you fetch it from actually the back end. So when we get item here it's just a promise that resolves and john do we change the value inner html of the element hello. That's actually well the vulnerability lies but let's not spoil too much, so if I creek an opens up on the rubber eggs, it writes hello John Doe let's try to put an excesses payload here. Reload the page we click and nothing happens, okay, that's weird. If we check the dumb with inspect, we can easily see that there is a rendered script tag but it's not executed. That's because the browser does not execute script tags that are added with inner html. So even demonstrated yet at inner html is vulnerable, okay, let's try something else. Let's do AMG S S C, he quills and now slash image, okay, let's just do a closing thing, I did. I started doing each game in the early 2000 but now an error, we'll do Elliot. Hello and if this fails, I actually have a plan B okay, so now, okay, let's read out the page and when we do that we'll get an excesses. That's because the brother is now trying to render the image, so these elements is a broken image because it's broken because it's suze it's your l doesn't walk. If we check the network tab, you see that there is a for a for call that has happened and that that that triggers recall to the error method on the image tag. So the nearer element the earlier of part is actually an excesses, images are really poor fool for that because they have low fewer browser limitations and scripts. Okay, so let's recapitulate when we use the inner html property and element we might be vulnerable to dumb based excesses because we are able to inject new nodes in the web page. And we have seen that it is possible to make them to make them executable, so now the question is, where does fetch user come from? Where does the user come from? It can come from the back end from an API, he in the case you are in a jam stack for instance, in that case well you would probably want to not trust what comes from your own back it, but it can be worse. Let's go to the bruiser and imagine that we've got local storage that set eight yeah. Let's do, it's even better local storage that set. First name and here we would put over excesses period and now actually the excesses payload will not be coming from the back end but from the local storage, what does it mean? We've got the attack and if we check the application tab, we can see in the local strange that the excesses payload is here. That means that even the stray age of the application in bruiser might contain that made containing excesses payload in that case. Well, on a shared computer, that's extremely problematic because as a hacker, I just need to go on a shared computer. And make sure that I have produced id the local storage of multiple websites, including banking websites with excesses, pay roads. And if the base code the application could is vulnerable to rendering that things coming from the local storage. Well, the next user is doomed and I am actually stealing data from people. So even data that you stored yourself in the local storage is not to be trusted. Never use inner h china or other method that can be excesses vulnerable, europe and eating too much of a big think even cookies can be rendered in a way page. Okay, so that's a bit scary because as we saw, even attributes on some elements can be used to inject excesses because in the previous videos they just show injecting new script items. But let's say you've got an image field where the value is dynamic, where the excesses would sit here. I think you would have hear something like rare l coming from the user where the user could use a payload that inject the figural and the honourable thing. So if you have a service that except Rugby Treasury, URL, you're doomed. If you use the local state to check the query string or the URL parameters what you're doomed. Anything that your framework provides you as a string value even in the front and web page should not be trusted. So here I've showed a low level stuff and nowadays less and less people do their own rendering, they use libraries or frameworks in react by default. The only vulnerable parts each channel four and dangerously set inner html and there is a very good documentation of that. So basically as a rule of thumb, never used dangerously set in a rich html. It has a rightfully defined name, however, it's worth noticing then in some versions of reacts and not sure which ones service side rendering reacts. I mean in all versions actually service side rendering reacts by default is vulnerable to excesses. So you need to make sure as if you were building back in the application, in that case that you have escaped things huge. Es is less explicit of course the method is named V, html and there's a warning telling you to use that in a frame. And additionally allowing user to write their own future and plates bring similar dangerous as a rule of goods. Heijn cutting edge in don't render html, you did not right, I understand that you need to do a fancy rendering things in that case. Use metal languages like fancy pants editor, stuff like that, but never put you yourself in a situation where a user car can render html in the bruiser that will be polluted and exploited. So let's recapitulate never use in our html, don't trust input whether they're coming from the network, yeah. Where is it complaining? Yes, sorry about that, it's a security measure from a 80, never trust anything even if that's coming from your own backhand. If that's coming from your local storage that's that's not to be trusted because your local storage can actually be polluted whether it's local storage, session, store the databases or even the cookies last. But not least if you're using your higher level framework, make sure you checked which part of the framework of vulnerable to excesses easily enough. Just cougar react excesses protecting excesses in react applications, christian scripting in react web apps, all of that. When you use a high level framework you need to check the documentation by default, you are safe but make sure you are. I hope I didn't scare you to merchant this video, thanks so much for watching it. Excesses are still very present, despite a lot of recent claims react view, Angola did not remove excess. Is removing excess is for real happens, who is using all the things such as CSP headers or trusted types. And that's why you probably want to check the next videos of that course. Thanks so much for watching this video, have a great day.
