WEBVTT 00:00.410 --> 00:05.900 Our focus for this session is the cross-site request forgery. 00:06.020 --> 00:15.800 This is a kind of malicious attack that the malicious user can perform to trick you into sending a form, 00:15.800 --> 00:18.680 and you might not even be aware of that. 00:18.710 --> 00:25.520 Now, I think that a real example can explain it much better than words. 00:25.520 --> 00:34.910 So I've made a malicious website that is not really looking like anything malicious at all, and I'm 00:34.910 --> 00:36.020 just going to show it to you. 00:36.050 --> 00:43.430 I also included under this video code, so you can just download it and run it yourself and see how 00:43.430 --> 00:44.210 it works. 00:44.240 --> 00:45.950 Now let's get to it. 00:46.310 --> 00:49.460 So this is this file CSRF attack. 00:49.490 --> 00:53.450 Also make sure that you have our current app running. 00:53.630 --> 00:55.070 Let me open it. 00:55.430 --> 00:58.730 Is there anything suspicious at all here? 00:59.840 --> 01:03.350 Does it look like beautiful kitten, though. 01:03.350 --> 01:03.710 It is. 01:03.740 --> 01:04.790 What happened? 01:05.990 --> 01:11.930 This is our page and form was submitted and suddenly it says that hacked user. 01:11.930 --> 01:13.430 Thanks for your message. 01:13.730 --> 01:16.880 And that's the message that was sent. 01:17.330 --> 01:20.900 This message was submitted via CSRF attack. 01:21.230 --> 01:24.170 So this is a real thing. 01:24.170 --> 01:29.780 If your forms are not protected from the CSRF attacks, this can happen. 01:29.810 --> 01:37.580 Now to put it in perspective, if someone adds a message to our guestbook, maybe that's not the end 01:37.580 --> 01:45.710 of the world, but users can be easily tricked to send forms that might be much more dangerous. 01:45.740 --> 01:55.820 So if you imagine someone is signed in and maybe makes a bank transfer or needs to change a password 01:55.850 --> 02:05.180 if those forms are not protected from the CSRF attack, the malicious user can do much more damage than 02:05.180 --> 02:08.360 just adding an entry to a guestbook. 02:08.390 --> 02:13.640 That's why we need to protect our applications from the CSRF attack. 02:13.640 --> 02:16.160 And we're going to learn how. 02:16.340 --> 02:21.680 So let's increase the coding space and let me jump to the contact post route. 02:21.710 --> 02:27.980 As you see we've got a placeholder for the CSRF token validation here. 02:28.400 --> 02:34.010 So let's begin by adding some logic for the CSF validation. 02:34.220 --> 02:36.230 We're going to do it step by step. 02:36.230 --> 02:43.040 And the first thing that we are going to do is to block of the form sending. 02:43.040 --> 02:48.620 If we don't have a valid token which might disable the form for a bit. 02:48.650 --> 02:50.870 At least we would be protected. 02:50.900 --> 02:57.740 Let me create the CSV file inside includes and start with a PHP tag. 02:58.010 --> 03:00.860 Then not to forget to do it later. 03:00.860 --> 03:02.120 In the bootstrap. 03:02.120 --> 03:03.890 Let's include this file. 03:04.490 --> 03:10.040 Okay, we can close the bootstrap file and let me add a function. 03:10.040 --> 03:14.390 This would be validate CSRF token. 03:15.140 --> 03:23.930 And it accepts a string which can be null because by default the token would be null unless we generate 03:23.930 --> 03:24.440 it. 03:24.440 --> 03:29.960 And for now let's just return false from it. 03:29.990 --> 03:32.900 We're going to implement this obviously later on. 03:32.900 --> 03:35.360 For now it returns false. 03:35.570 --> 03:39.560 Now inside our router let's remove this comment. 03:39.560 --> 03:44.720 And the first thing I'd like to do here is to validate the token. 03:44.990 --> 03:54.950 So we're going to check if the validate CSRF token that is coming from the post data. 03:54.950 --> 03:57.980 So it will be sent together with the form. 03:57.980 --> 04:01.600 And if the CSRF token field. 04:02.020 --> 04:05.380 Let's also provide a default if it doesn't exist. 04:05.560 --> 04:12.910 So if we can't validate it, we're just going to add a flash message saying that's an error. 04:12.910 --> 04:16.180 And we're going to say sorry. 04:16.390 --> 04:22.570 Please send the form again without any specific details. 04:22.570 --> 04:29.350 And we're just going to redirect to the contact form again. 04:31.570 --> 04:37.030 So we begin with the CSRF protection. 04:37.180 --> 04:50.020 And if I now jump to the contact form and I'm actually sending it from our website and providing some 04:50.020 --> 04:52.990 valid data, the form is logged. 04:53.020 --> 05:00.100 Also this malicious user from this kitten website Can't send the phone. 05:00.730 --> 05:07.630 Now our job is to first generate this token, store it someplace, and we're going to store it in a 05:07.630 --> 05:10.720 session because this is a per user thing. 05:10.750 --> 05:17.080 Every user would have the token automatically generated unique to that user. 05:17.080 --> 05:20.740 That's why it is stored in the user's session. 05:20.830 --> 05:26.740 And then this token will have some lifetime let's say 30 minutes. 05:26.740 --> 05:30.910 And that's the time that users have to submit this form. 05:30.910 --> 05:37.930 If they wouldn't do it in 30 minutes, well basically the form submission will fail. 05:40.570 --> 05:46.780 So now I'd like to dissect this topic of CSRF protection step by step. 05:46.780 --> 05:55.000 I think we will conclude by now, and in the next video we are actually going to generate those tokens. 05:55.000 --> 05:57.580 So we have something to validate.