CSRF

In the final video of this stage, 0:00 we're gonna look at cross-site request forgery, or CSRF. 0:01 CSRF was removed from the OWASP Top Ten in 2017, 0:06 falling out of the number eight spot from 2013. 0:09 Unfortunately, CSRF is still extremely common today, 0:12 with bug bounties claimed for CSRF on a daily basis. 0:16 For this reason, we will still cover CSRF in this course, but 0:19 don't be shocked when you don't see it on the OWASP Top Ten in 2017. 0:23 Without further ado, let's see what it's all about. 0:26 A CSRF attack forces a logged-on victim's browser to send a forged HTTP request. 0:29 Including the victim's session cookie, and any other automatically included 0:36 authentication information, to a vulnerable web application. 0:40 This allows the attacker to force the victim's browser to generate requests 0:44 that the vulnerable application processes as valid requests from the victim. 0:48 To carry it out, an attacker needs to get a user to visit a website or 0:53 app controlled by the attacker. 0:57 And then utilize the lack of CSRF protection on the target website to send 1:00 a request that'll perform some kind of state-changing action on the target site. 1:04 These kinds of actions can be things like sending money from the victim to 1:09 the attacker, or resetting the user's password. 1:12 Given this requirement, CSRF is as much a social engineering attack 1:16 as a traditional web application vulnerability. 1:20 And thus requires some amount of skill to set up. 1:22 Though this may sound hard, to trick a user today into clicking a button on 1:24 a site they may not find credible. 1:28 Attackers often set up sites that look exactly like the target site. 1:30 And then send a phishing email or 1:34 targeted advertising campaign to get unsuspecting users to fall for the trap. 1:35 To exploit CSRF, attackers leverage the fact that browsers 1:40 automatically send credentials, like session cookies, 1:44 with HTTP requests to the server from where those cookies were received. 1:47 Keep in mind, the victim must be logged-in to the vulnerable site, or 1:52 have a valid session token present in their browser. 1:56 As you might guess, our app is also vulnerable to CSRF. 1:59 Where an attacker can change the banking and 2:02 routing number in a user's profile, by getting the logged-in user to click on 2:04 a targeted link on a totally separate web site in their browser. 2:08 This attack consists of two parts. 2:12 First, we must set up a fake website in another domain where 2:15 we can send the forward request from. 2:18 To that end, we set up a site that advertises a banking 2:19 application with a sign-up for beta testing. 2:22 Let's log out and check out that site. 2:25 Within this site, 2:27 there's a form field which accepts an email, which we can see here. 2:28 However, if we dig into the source code, we see that this email is never submitted, 2:31 since there's no name attribute on the email input. 2:36 But there are two hidden fields. 2:39 When the form is submitted, 2:41 these hidden fields will be posted to the profile page of the target application. 2:43 This post will then update the banking and routing number of that user 2:47 to point to our attacker's banking and routing number, which is shown here. 2:51 We see that the action for 2:55 the form is the domain where the vulnerable app is running. 2:56 That's absolutely necessary to make this all work. 2:59 Well, if we simply post to the vulnerable site, and redirect the user there, they'll 3:02 probably think something is wrong, or they might even know they're being targeted. 3:06 To ensure this happens without fooling the victim user, 3:10 we've set up an empty iframe that'll ensure the attacker site 3:13 doesn't redirect to the target application when this form is submitted. 3:17 The iframe is also 0 width and 0 height, so the victim will never see it. 3:20 Okay, now onto the actual attack. 3:25 First, let's make sure that our victim user is logged into the vulnerable app. 3:27 Since the victim must have a valid session with the vulnerable site for this work. 3:31 Now, as the victim user, suppose we were sent an email, or 3:35 saw an ad for a revolutionary banking app, aptly named Revolution. 3:39 Little known to the victim, that's the site our attacker has set up. 3:42 And unfortunately, the victim is doing exactly what the attacker wants. 3:46 First, if we look at the profile page of the victim user, 3:50 we see that their banking and 3:53 routing numbers are 1234567, which right now is not the attacker's information. 3:57 Now, as the victim, we head to the Revolution banking app page, and 4:02 put in our email, and click Sign Up. 4:06 As the victim, nothing appears to have happened. 4:08 Except that we think we're now going to be on the shortlist for 4:11 getting our hands on the best banking tool since currency was invented. 4:13 However, if the CSRF attack was successful, we should now see that 4:17 the banking and routing numbers are updated to the attacker's information. 4:21 Specifically, a string of nines and eights, which came from the hidden fields 4:25 in the attacker's form on the Revolution site, let's look. 4:28 At this point, our attacker is free to transfer however much money out of 4:38 the victim's account as they want. 4:41 Or just continue to receive deposits that the victim thinks 4:43 are going to their account. 4:46 CSRF is bad news for your users, if you don't mitigate this issue. 4:48 Fortunately, effectively mitigating CSRF issues is one of the easiest fixes to 4:53 apply, compared to the other vulnerabilities we'll discuss. 4:57 Express's CSRF middleware provides a very effective way to deal with CSRF attacks. 5:01 By default, 5:06 this middleware generates a token that is added to requests that mutate state. 5:07 These are the put, post, and delete methods, or non-standard get methods. 5:11 The token can be added within a hidden form field, query string, or 5:15 a header field. 5:19 If you want to use other method of writing middleware, such as node csurf. 5:21 It's very important that the middleware providing CSRF protection is 5:25 initialized before any middleware that needs to know the method of the request. 5:28 Otherwise, an attacker can bypass that protection. 5:33 When the newly secured form is submitted, CSRF middleware will check for 5:37 the existence of the CSRF token. 5:41 It will validate that it matches the generated token for 5:43 the response-request pair. 5:45 If these tokens fail to match, the server will reject the request, 5:47 as it was likely forged. 5:50 By combating state-changing requests, and ensuring the requests are valid, 5:52 you can prevent CSRF. 5:57 In the context of our application, how do we prevent CSRF using this strategy? 5:58 Well, we can include the express CSRF middleware for 6:03 just this purpose in the main server file, server.js. 6:07 This is using the node csrf middleware, which generates new tokens for every new 6:41 request, and exposes the tokens to each state-changing request in the application. 6:46 Now this token can be included in a hidden form field, in the profile markup for 6:50 the profile page. 6:55 When someone tries to submit the form on the profile page, 7:10 if the request does not have the valid CSRF token. 7:13 Which would be the case if an attacker tried to submit a post to this form from 7:16 another website. 7:19 The request will then be dropped, and 7:20 no state changes will occur, preventing any sort of problems like we saw earlier. 7:21 Congratulations, you've now learned about, and 7:26 seen, command injection, cross-site scripting, and CSRF in action. 7:29 In the next stage, we're going to dive into application session-related 7:34 vulnerabilities like broken authentication. 7:38 And issues with access controls and sensitive data exposure. 7:40 See you soon. 7:43