Hello and welcome to secure JavaScript programming with Vladimir [inaudible] In this video, we talk about clickjacking. It's the first of the three process security element in this learning path. Clickjacking happens when someone creates a malicious page and embed a legitimate page in it and trick a user into clicking on certain elements of the legitimate page. This relies on poor configuration of these web servers having the legitimate page and very malicious intent from another user. As my high school math teacher used to say, a demo is always better than a speech, so let's go for a quick demo right now. Here I've got a banking website which is very super secure. It is called super secure bank, must be secure. You can see your balance in dollar and the last transaction, and you spent $10 for lunch. There's also a weak link that says transfer money to a hacker and they're not sure whether it's there. It's especially there for the sake of the demo in my case because there are countless ways to hack around it, but that's actually the link we want to trigger the user to click on. If I click on it, I can see that now the balance has been reduced by $1 million as if it was in those Tim Powell Bad Guy and if we re-click on it, we lose one more million, and each time we click on this link, we lose $1 million. This is terrible. It's not that bad because the bank is so secure that each time they restart the servers, they forget about all the money being sent to the hacker, and you get back to having a lot of money on your bank accounts and only spent $10 for lunch. Lucky you, you just need the server to restart once a day, so all the money you spent is forgotten. Jokes apart, the goal here is to trick someone into clicking on this. I designed a fake web page that could happen in any case, that could be loaded in any situation, that could be a popup, that could be a website, a trick to you to click on. I could have paid ads on Google or Twitter, or Reddit to have you click this page. The question is not that much how I got you there. I might have pawned a server and put that page here. The question is, how can I get you to click on this button. That's my goal here. Here the text goes, "Congrats, you won a prize. There is a mobile phone of your dreams." Dreams, not dreamt, sorry about that. You dreamt of. No, it's okay. A mobile phone you dreamt of. The game console that is out of stock for some reasons. That can give you hints on when this video was recorded. Don't read the small line, click here to claim your prize. When you click nothing happens, so you click again, again, again, again, again, again, again, and nothing happens. You are mad, you just go back to something else. You were that close to get a new mobile phone or a new gaming system, and you're so mad. Couple of days later, you go to your bank account, and you check your balance, and boom, you have actually sent $10 million to a hacker. How did that happen? You did not notice anything. That doesn't make any sense. How did this money leave your bank account? You are terrified. Let's go in detail about what happened. In this page, there's actually an invisible A-Frame here that redirects to the page of your bank. Let me change the style so it will be more visible here. If you see it, we've got the webpage for super secure bank embedded in an A-Frame but because of the CSS of the style of this page. Well, this is fully transparent. Where did I choose? I use position absolute, I fixed position depending on where I want it to. Conveniently speaking, the link to click on was at the top of the attacked page. Otherwise, they would have to play with some offset magic. I'm terrible at HTML and CSS and very good at JavaScript, but not very good at designing, you probably have noticed that by now. I just place it conveniently where I want and put opacity to zero, then I build the rest of the page, which means that here is actually the link to transfer a lot of money to a hacker. This is this link that is actually embedded in this page. Let me put back the opacity at a good level. Up here, we see that the link just falls on the bottom. That's how we tricked people into clicking on that, and that's why you may get message from backbone to this people. We tend to use it as a click checking or that's why there are so many weird websites with iFrames. Historically, this happened a lot to make people click on Like buttons or Subscribe buttons on Facebook. Because since this is an iFrame, it's actually running in the domain of the original website in your browser. Meaning that this iFrame has access to your cookies from secure bank. It has access to the application parts. The local storage of secure bank here, localhost 4000. Here localhost, you've got a cookie from secure bank. All of these iFrame, actually, you can even see my previous graphical stuff and algorithm stuff. All of these has access to the store of the domain that is attacked. Who do you protect against that? It seems very complicated. Well, the first thing you must do is to use the same site cookie. You must make sure that your cookies cannot be accessible in another website, so you must use same site that will prevent the cookie to be valid in the iFrame. Then if I go to the web server here, I've got one first solution. Let's start with the historical one. Historically, there's a header named X-Frame-Option that can have the value deny or domain if I'm not mistaken. Anyways, the one we want to put here is deny. Now when I reload the malicious page, I see that I have empty iFrame because localhost refused to connect. If I go to inspect, then I will have refused to display localhost 4000 because it's in an iFrame with X-Frame-Option deny. If I go back to the opacity being at zero here, well, we just see void here. We don't get the feedback but is not being loaded, and the iFrame is just transparent. That does not exist. If we check it at network level, we can see here that it has still been loaded that as a request to happen but could not be loaded. If we check the elements on the page, we see that actually there's a page, but it's a default page integrated by my browser directly. If we check the style, for instance, there will be some chromium copyright claims, that's actually the page we've seen here. Let me put it back. That's the HTML4 localhost refused to connect. That's the first way of doing that. The second that gives the same result is actually using a content security policy. You know me and you know that I love content security policy, because they are so powerful. Well, with content security policy, you can define frame ancestor to none, so you will get the same result because it violates content security policy. Under network, you will see the same thing. The main difference is that with the content security policy, you can also choose specific domains where you allowing to be embedded. If for some reason you need to allow people to put your website in an iFrame, well, you can do that through a content security policy. Also, content security policy have a report URL. Let's just put stash reports, it's not important. They are the report share, right? Meaning that when this happen, you will actually get a report sent to your monitoring tool, and you know that some people try to attack you and you know who is trying to attack you because it will be coming from this domain. That's why content security policy is the most powerful way to block embedding in an IFrame. Sadly, it's not supported by all browsers yet, or at least not by all historical browsers. Most modern browsers support it. I let you refer to the MDN documentation, so I don't show you outdated data whenever you watch this video. That's it for click tracking. Thanks so much for watching this video. Please check the rest of this course about browser security. The next one will be about cross-origin resource sharing. We also have a video about resource integrity coming your way. Thanks so much. Have a great day, and see you soon.
