Hello and welcome to secure JavaScript programming with Vladimir de Turckheim, I am Vladimir de Turckheim and you can follow me on twitter at poledesfetes. In this course, in this set of videos, we will talk about XSS across its scripting attacks and other ways of injecting JavaScript code in JavaScript in time. We will also see in depth the ways to protect against XSS attacks. So this first video is mostly a set of refreshers, but at the same time generic principles about XSS attacks and basically what any JavaScript developers should know about that. I have to warn you. It's not only for the people who only do frontend there's a lot of things related to XSS that happen in the backend and anywhere developers should probably live it up in this particular case. But let's start with a bit of history and most of all, Samy is my hero. That probably doesn't ring a bell, but if you've been around the security internet on MySpace in the late 2000, you might remember that it was one of the most world famous XSS attack and probably one of the biggest and one of the first. So it's a self-replicating worm that contained XSS payload that was executed each time it was printed on someone's MySpace feed. So if you were friends with someone who shared this pillow on my own MySpace, then this will execute with your sets of rights on MySpace. So it would do two things, add Samy as your friend of on MySpace and print on your feed. Sorry about that. Print on your feed the XSS payload and write, but most of all, Samy is my hero. And it actually took only 20 hours to infect one million accounts. It's replicated at a huge speed. It was definitely the first automated pyramid scheme on social media. So how did this happen? Well, it happened through an XSS attack. A XSS happens when a malicious attacker manages to run arbitrary JavaScript code in a given web browser through a webpage. Basically when you can do that, you have access to the world set of environment of privileges of the area you're running JavaScript in. So let's say you are running JavaScript arbitrarily on the website of any bank. Well, if there are no frames or ways to limit your reach through the stored state of the application, well, you can act as if you were the legitimate user and just do API calls and be able for instance to withdraw any of their money and send that to your own bank account. Basically it can be very bad because you can impersonate anything and nothing can be trusted anymore. So there are multiple kinds of XSS attacks and the first one we will see today is Reflected XSS. So a Reflected XSS happens when the payload of the attack is present in an HTTP request to which a response is issued, containing the exploited webpage. So you will need to trick, if you want to exploit one, you will need to trick the user to click on a certain link on a certain button to submit a form and that will actually send the XSS payload to the backend. That will respond the surrendered page that would contain the XSS payload on an executable part of the page. They are not persistent, meaning that if you refresh the page where if that's on the URL is with to be available. But if you come back to this page later with the payload not being said, well the vulnerability won't be exploited anymore. So Reflected XSS are not persistent. They are one of the attacks. Stored XSS on the other hand are permanent. So a stored XSS happens when the XSS payload is injected into the storage of the web server, might be a database and sent in the HTTP responses. So let's say I want to send you a private message through any social media. I could put some XSS code, some JavaScript code there. And maybe the web server will wrap responders around the web page that will contain the payload. And stored XSS are persistent. Where you can come later to the page and it will still be there. Also there is a special case of stored XSS which is called blind XSS, we'll deal with that later. DOM-based XSS. So if you build single page applications, you probably think that seller side rendered XSS don't affect you. Well that's not fully true because now with more and more single page applications still using service side rendering technologies such as Next.js or using ppetr to pre-render stuff, well rendering things and safely on the salaries back on the table. However, if you only do things in the browser you might be vulnerable to DOM-based XSS. So this is the kind of XSS that happens when the vulnerability sits in a frontend only code base. So let's say you've got to a website and you use the inner HTML property and an object to put something that has been user defined, you are vulnerable to a DOM-based XSS. Also the content the payload of the DOM-based XSS can come from the seller through arrest or actual request and in that case where it can be installed or reflected thing, it doesn't matter. The vulnerability lies in the frontend code so it can be stirred back inside. It can be reflected back inside that it cannot become reflected frontend side, if I pass parameters. If I trick you to click on a link with parameters that will only be handled by the frontend application, well I can do a frontend DOM-based reflected XSS. But also it's worth noticing that now where browsers have storage capabilities, whether that's in memory databases, that may be workers, that may have a state or just stored thing on DOM locally and cookie in a local storage. So all of that means that it's actually possible to do stored XSS in a browser, meaning that it's really tricky because the way browsers store things, they can actually store things on a domain or on a session. And if you store thing on a domain, even logging enough, looking off might not clean that storage as a domain. So let's say I go to my bank website. I put something malicious by cutting, by going to the developer tools in the storage of the domain of my bank. And then I log out and someone uses the same machine with the same browser with the same OS user to access their bank account and they are the same bank as I do. Well, my XSS payload might be exploited, maybe trigger them and I'm probably able to access everything they do, that can happen with mailboxes, YouTube accounts or anything. That's why it's extremely important as a personal safety measure that you don't share the same browser as anyone else. At least not the same browser parameters. So use different sessions for different people. [SOUND] Use public machines in private mode. So this one be stored in private browsing. So this kind of XSS is actually the newest and there's little literature on that. Hopefully through the cause of these XSS part we will go through all of that and much more. Now one of my favorite XSS. This one is probably the one developers have the hardest time fighting for and they probably showed it's called Self-XSS. A Self-XSS happens when the victim is tricked into running the XSS payload themselves. So if you have a Facebook account just opened that they have tools on Facebook and you will see warnings about Self-XSS. That happens through social engineering. And it can really work on certain people were not really familiar with the internet and you tell them, hey, when that and the code of your Facebook account to each end, run that and you will have access to secret google whatever that means. And it's actually extremely easy to trick people into opening the console and copy paste to JavaScript cache chunk they have no idea about. So it only happens through social engineering. And the best you can do as a developer is to put runnings in the console of your website saying never copy paste anything here. And facebook is actually a great example for that. Watch the next videos to learn more, we'll go in depth into most of that and much more, because right now this intro was only about XSS, but there are other ways of executing arbitrary JavaScript environment, hints evil. Also, the methods to protect against XSS in the browser are actually extremely more and more complex. So if you don't know about course, about content security policy. However, the new protection on the block that's named trusted types that were extremely exciting Google project. You really, really, really want to check the next videos of that course. Thanks so much for my attention. See you soon and take care of yourself until we meet again.
