Check out a free preview of the full Advanced Web Development Quiz course

The "Q20: Front-End Security" Lesson is part of the full, Advanced Web Development Quiz course featured in this preview video. Here's what you'd learn in this lesson:

Students are instructed to connect the security terms with the correct definitions. The terms include XSS (cross-site scripting), CSRF (cross-site request forgery), UI Redressing, and MITM (man in the middle).


Transcript from the "Q20: Front-End Security" Lesson

>> Connect the terms with their definitions. XSS or cross-site scripting, CSRF or, yeah, UI Redressing, man in the middle, and allows attackers to inject malicious scripts into web pages viewed by others, tricks users in interacting with disguised or hidden elements. Tricks users into executing unwanted actions by exploiting their authenticated session, or allows attackers to intercept and modify communication between two parties without their knowledge.

All right, so the answer is cross-site scripting allows attackers to inject malicious script into web pages viewed by others. Cross-site request forgery tricks users into executed unwanted actions by exploiting their authenticated session. UI Redressing, is also called clickjacking, tricks users in interacting with disguised or hidden elements, and man in the middle allows attackers to intercept and modify communication between two parties without their knowledge.

So first for cross-site scripting just to give a small example, for example you have a blog post editor and you wanna show people when they're writing you wanna show a live preview I don't know. But you're using the unsafe innerHTML for that now in this case it's fine but maybe if a user adds like this image, which isn't working, we're not pointing to any src.

But we also have an on error function, which fetches or makes a post request to this evil API. But because we're actually embedding this image into the HTML, it has access to the documents cookies. So now it can just make that request to this evil API with the cookie that was currently stored on a document.

Now there are pretty, you just have to sanitize your input always. You have to avoid using unsafe methods like innerHTML, document.write, eval, all the good things. Normally, when you're using a framework, they help you with that, if you're using React, they actually say dangerouslySetInnerHTML, all that stuff. Yeah, anyway, that's cross-site scripting, kind of.

And then there, we have the cross-site request forgery. So in this case, let's say that you're just logging into your bank, as always, but your bank doesn't really, I don't know, think about security too much. So it's setting a cookie on this, well not just on this website it just sets a cookie.

So now, I don't know if your friend's suddenly, hey, check out this site but it still has access to that cookie. And this site may be or, it has an onload function that basically submits a form as soon as the body is loaded. But this form makes a post request to your bank's API but because your cookie is still set and they didn't really set it securely that website also has access to that cookie.

So now it can just make a request to your website, pretending to be you. So one way to avoid that is by using a CSRF token, which can be kind of anything. But it should just be just that user has that token, and the server knows that token.

So it knows when a request comes in from that user, the server can decode that CSRF token to ensure that's actually the user making that request. So in this case, maybe we're setting a same site cookie, which is a cookie that will only be accessible on that same site so only has access to that cookie.

So in this case, we can just make a request but now when we actually go to that evil site, it won't have that CSRF token, it will just have the user token. So now when we do make a request to the website, it's, sorry my animations are all over the place, yeah, it's just returns a forbidden because the CSRF token is invalid.

So this is kind of a way to I don't know, avoid or prevents CSRF or the forgery. Yeah okay, so it does work when you do have that token I don't know why I added an animation for that. But anyway, and then we have UI Redressing or clickjacking.

So let's say, or like this happens by embedding an iframe so for example this bank iframe, that's kind of that blurred out one and then we have this evil site. But what they do is they kind of overlap the website with an iframe that you won't be able to see.

So they just make it opacity zero, this make it out, so now when you think you're winning a cool prize, you're actually clicking on the transfer money button, because that is an iframe on top of that. So now it makes a request to your bank and if you, initially when that's an iframe for, it has that cookie in that iframe because it's still it's still that origin so it's making that request.

We'll talk more about how browsers kind of prevent this later on, but yeah that is UI Redressing or clickjacking which can still happen when embedding iframes. And also, as a website owner, you can prevent other websites from embedding your iframe by setting the X-Frame-Options header. So that just ensures that evil websites cannot embed your website into their website, potentially causing clickjacking attacks.

And then there's man in the middle I mean this is kind of a different type of attack. It's just client and server and a man in the middle, I don't know why this is so aggressive, but it can kind of sit maybe in a Wi-Fi router or something.

And he just kind of sits in between the communication between you and the server. So it can just read it, it can alter it, it can do anything with it. Now, if you use HTTPS everything will be encrypted, right? So they just cannot really see, because HTTP normal is just plain text.

So they can read everything they can read your headers, your data. But if you're using HTTPS and he doesn't have access to that secure to your tokens or certificates, then it'll just be unreadable for them. So that's also a great way to avoid that and why you should use HTTPS.

I mean, there are still also vulnerabilities with man in the middle attacks, even with HTTPS, but it's definitely a lot harder for them to do so.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now