Hello, and welcome to secure JavaScript programming with Vladimir de Turkheim. In this video, we will talk about reflected or reflective XSS. Let's start with examples. I've got this website that you can use when you want people to subscribe to your newsletter. For instance, if you want to push your friend John to subscribe to it, you will just send them the link with John as a query parameter and it will say, "Hello John, do subscribe to our newsletter, enter your name, enter your email." John would say, "John Doe," and they would put their own email address here @example.com. Then, "Hello John Doe, we have just sent you a confirmation email at john.doe@example.com," and that's it. This website is vulnerable to reflective XSS, and we will see two ways of achieving reflective XSS attacks. In this case, we know that this part is dynamic. A hacker would first try to see if these things will be escaped. We will use some very old HTML tags. I don't know if anyone remembers using the b tag, which actually bolded text. You don't rush into throwing script when you look up for XSS, you start with that, so you are sure that you have a sync. Also, something I usually do is I might happen to escape these in a numeric component. Why is that? Because some frameworks will actually not accept the slash at the end as a valid thing. It will see that as something in the path maybe. Let's just do that. Once again, it's bold. If we inspect the element in the console, it has a bold tag around. Now we can go and do even further and have what everyone do when they want to do an XSS script alert hello and slash script. Let's hope I wrote that properly. We will put that in here, and we've got an alert that has been triggered. That means that we are able to run arbitrary JavaScript code on this domain. What would be an ideal scenario for such attack? As I told you, this is a social link. You would actually trick someone into clicking into a crafted link, maybe behind a URL shortener, so they don't see all the things. Maybe with actually the encoded part here, so they don't see that there is a blatant XSS in the URL they're clicking on. You could trick them into clicking, which is okay in general. But if that's on a website where they already have a cookie available because it's a wider application, and they might already have a cookie in it, you cannot arbitrarily run anything. Let's say you've got an invitation link for a banking stuff. You would craft a link and if the person already have an account in the bank and is connected with their browser, you can do pretty much what you want with their bank account that's why it's called reflected XSS also because you have to craft a request and actually trigger people, trick people into clicking on it. Here, we've got the call, and we've got the rendering on the page immediately. There is nothing coming from database, so that's what we will see in the next video of this course. You want to trick people into doing something, and the XSS attack will come directly inside the response. You want them to click on your link, or you want them to fill a form where you might have hidden some parts that are vulnerable to XSS. Here, I also have a vulnerable form. Let's go easy and do like that @script.com. Too bad. Let's use the encoded value. I'm not sure this one will work. Let's find out together. It isn't ours. Also our validation doesn't teach me to XSS in this part me@me.me. But here we have another XSS here at this point. If we inspect that, we exactly have the same one. That's another reflected XSS. That is one through a thumb. Page is rendered with things that comes from the request in the body. When you render a web page with something coming from the body, you want to make sure that everything is escaped. you have two ways of actually fighting XSS. You escape things that you pass to the renderer. For instance, you can use a module that does HTML escape, but this one is pretty old. But they let you check or they lead you on how to choose the right module or to find the right module to HTML escape. But the best way is actually to use is that templating engine. For instance, in EJS, there is a way to actually tell the templating engine that you want it to escape the values. If I go back here, if I reload, you can see that this is escaped. If we go to the EJS documentation, we see that it has multiple way of accepting something and so what I recommend is the space and equal. Whatever templating engine you use, you want to use the value that is HTML escaped. That's how you protect against a reflected XSS. Thanks so much for watching this video. I hope I helped you understand what are reflected XSS, see you soon in another video, maybe the next one, which is about stored XSS. Hello, and welcome to secure Javascript programming with Vladimir de Turkheim. In this video, we will talk about reflected or reflective XSS. Let's start with examples. I've got this website that you can use when you want people to subscribe to your newsletter. For instance, if you want to push your friend John to subscribe to it, it will just send them the link with John as a query parameters and it will say hello John, do subscribe to our newsletter; enter your name and tell your email. John would say, John Doe, and they would put their own email address here @example.com. Then Hello John Doe, we have just sent you a confirmation email at johndoe@example.com. That's it. Well, this website is vulnerable to reflective XSS. We will see two ways of achieving reflective XSS attacks. In this case, we know that this part is dynamic. A hacker would first try to see if these things will be escaped. We will use some very old HTML tags. I don't know if anyone remembers using some b tag, which actually bolded text. You don't rush into throwing script when you look at for a XSS, you start with that so you are sure that you have a sink. Also, something I usually do is I might happen to escape these in a numeric component. Why is that? Because some frameworks will actually not accept the slash at the end as a very thing. It will see that as something in the path maybe. Let's just do that. Once again, it's bold. If we inspect the element in the Console, it has a bold tag around. Now we can go and do even further, and have what everyone do when they want to do an XSS, script, alert. Hello and slash script. Let's hope I wrote that properly. We'll put that in here and voila, we've got an [inaudible] that has been triggered and that means that we are able to run arbitrary JavaScript code on this domain. What would be an ideal scenario for such attack? Well, as I told you, this is a social link. You would actually trick someone into clicking into a crafted link maybe behind a URL Shortener so they don't see all the things, maybe with actually the encoded part here so they don't see that there is a blatant XSS in the URL they're clicking on. You could trick them into clicking, which is okay in general. But if that's on a website where they already have a cookie available because it's a wider application and they might already have a cookie in it, you can not arbitrarily run anything. Let's say you've got an invitational link for a banking stuff. You would craft a link and if the person already have an account in the bank and is connected with their browser, you can do pretty much what you want with their bank account. That's why it's called reflected XSS also. Because you have to craft a request and actually trick people into clicking on it. Here, we've got the code and we've got the rendering and the page immediately. There is nothing coming from database. That's what we will see in the next video of this course. You want to trick people into doing something and the XSS attack will come directly inside the response. You want them to click on your link, or you want them to fill a form where you might have hidden some parts that have enabled trick XSS. Here I also have a vulnerable form. Let's go easy and do like that, @sript.com. Too bad. Let's use the encoded value. I'm not sure this one will work. Let's find out together. It doesn't allow us. The browser validation doesn't let me to access XSS part. Me@me.me. But here, we have another XSS here at this point. If we inspect that, we exactly have the same one. That's another reflected XSS, that is one through a form. The page is rendered with things that comes from the request in the body. So when you render a web page with something coming from the body, you want to make sure that everything is escaped. You have two ways of actually fighting XSS. You escape things that you pass to the renderer. For instance, you can use a module that does HTML escape, but this one is pretty old. But I'll let you check or maybe do on how to choose the right module, how to find the right module to HTML escape. But the best way is actually to use the templating engine. For instance, in EJS, there is a way to actually tell the templating engine that you want it to escape the values. If I go back here, if I reload, you can see that this is escaped. If we go to the EJS documentation, we see that it has multiple way of accepting something and the one I recommend is percent equal. Whatever templating engine you use, you want to use the value that is HTML escaped. That's how you protect against a reflected XSS. Thanks so much for watching this video, I hope I helped you understand what are reflected XSS. See you soon in another video maybe the next one, which is about stored XSS.
