1 00:00:01,020 --> 00:00:05,130 Now that we know how to discover and exploit Yes our vulnerabilities. 2 00:00:05,250 --> 00:00:09,760 Let's talk about how to protect web sites from them. 3 00:00:09,840 --> 00:00:18,900 So if we just go back now to GVW 8 and said the security too high you'll see that they have a very simple 4 00:00:19,110 --> 00:00:21,960 way to protect against it but this way actually works. 5 00:00:22,140 --> 00:00:25,410 And what they do is they ask you for the current password. 6 00:00:25,470 --> 00:00:31,110 So even if we get this form and we do all the forging and all the stuff that we were doing and then 7 00:00:31,440 --> 00:00:36,900 send it to the target person we can't actually hide this and get it to automatically submit because 8 00:00:36,900 --> 00:00:38,590 we don't know the current password. 9 00:00:38,730 --> 00:00:43,860 So it asks for the current password and then it allows you to add a new password. 10 00:00:43,860 --> 00:00:46,550 So this is a really good solution for this case. 11 00:00:46,680 --> 00:00:50,700 Though because what if the form actually doesn't change your password. 12 00:00:50,700 --> 00:00:54,890 What if we're just going to send messages pretending to be that person. 13 00:00:54,960 --> 00:00:58,000 What if we're going to post things to that person's wall. 14 00:00:58,020 --> 00:01:01,320 What if we're going to post things into that person's blog. 15 00:01:01,380 --> 00:01:04,880 So since Aref can be exploited to do many things. 16 00:01:04,890 --> 00:01:10,600 As I said in previous videos and this method will only protect against changing the password. 17 00:01:10,680 --> 00:01:15,750 You can't really ask the person for their password every time that they want to post something or to 18 00:01:15,750 --> 00:01:17,240 do something with their profile. 19 00:01:18,750 --> 00:01:24,570 Now newer versions of DVDs when you need that don't come with me test protocol to actually have a more 20 00:01:24,570 --> 00:01:28,410 secure option that will implement the method that I'm going to talk to you about it. 21 00:01:28,410 --> 00:01:33,270 Now it's actually called impossible instead of high but it doesn't matter it's not exploitable anyway 22 00:01:33,300 --> 00:01:35,670 so we don't really need to have it installed. 23 00:01:37,060 --> 00:01:42,190 So let's talk about how you could actually prevent these vulnerabilities from happen without asking 24 00:01:42,190 --> 00:01:46,740 the user to re-enter information or to re-enter the password. 25 00:01:46,740 --> 00:01:52,660 If you think of it the way we were able to exploit this is we were able to just copy the form that the 26 00:01:52,660 --> 00:01:59,890 website uses and send it to the target person and get that person to run it or automatically run on 27 00:01:59,890 --> 00:02:01,550 the target person's computer. 28 00:02:02,590 --> 00:02:08,650 So once the request is sent to the server or the server wasn't doing any type of validation to ensure 29 00:02:08,650 --> 00:02:12,720 that the user actually wants to change their password. 30 00:02:12,790 --> 00:02:20,260 So the best way to prevent s r f is to make sure that the user is submitting data through a page that 31 00:02:20,260 --> 00:02:26,020 was served to him by the web application and not by anyone else. 32 00:02:26,020 --> 00:02:31,290 A good way of implementing that is to use synchronizing tokens. 33 00:02:31,300 --> 00:02:35,800 Now I know the name sounds complicated but the idea is very simple. 34 00:02:35,800 --> 00:02:41,980 Basically we want to generate a unique and random token at the server side. 35 00:02:42,400 --> 00:02:48,400 Then when the page is loaded when the form is loaded We're going to embed this already generated token 36 00:02:48,790 --> 00:02:52,060 into that page as a hidden form. 37 00:02:52,120 --> 00:02:57,820 Then when the form is submitted we're going to make sure that the form was submitted with that token 38 00:02:58,030 --> 00:03:00,910 that we sent to that specific user. 39 00:03:00,910 --> 00:03:07,510 So basically we give the user a token and then we wait for him to submit the form with the token that 40 00:03:07,510 --> 00:03:08,450 we gave him. 41 00:03:08,560 --> 00:03:12,300 That way the token that the hacker gets will only work for him. 42 00:03:12,460 --> 00:03:18,190 So even if he generates a page and send it to the target and the target throws the page the form will 43 00:03:18,190 --> 00:03:24,570 be submitted but it will be refused by the server because it did not give that token to that user it 44 00:03:24,570 --> 00:03:31,800 gave that token to the hacker say for example we have this user here and here it costs Facebook dot 45 00:03:31,800 --> 00:03:34,230 com password BHB. 46 00:03:34,540 --> 00:03:35,990 It goes to the server. 47 00:03:35,990 --> 00:03:40,090 The server is going to generate a response for that request. 48 00:03:40,130 --> 00:03:46,610 So it's going to return the e-mail page that represents passwords ph be in that page. 49 00:03:46,700 --> 00:03:49,830 It's going to include a unique token. 50 00:03:49,910 --> 00:03:56,330 So when the page is loaded at the client side it's going to already have the form that the user is looking 51 00:03:56,330 --> 00:04:01,880 for plus a unique token that was generated by the server. 52 00:04:01,880 --> 00:04:08,480 Then when the user submits whatever they want to submit the server will only accept the form and will 53 00:04:08,480 --> 00:04:11,740 or will on the response to what the user is asking. 54 00:04:11,870 --> 00:04:14,940 If the user returns the same token. 55 00:04:15,040 --> 00:04:19,250 Now if this isn't implemented properly it can still be exploited. 56 00:04:19,250 --> 00:04:26,120 So if the token was predictable or if the same token was being used then the you the hacker can discover 57 00:04:26,120 --> 00:04:30,700 what the token is embedded in the HDMI code and send it to the user. 58 00:04:31,830 --> 00:04:36,140 So the token needs to have certain characteristics so that it's secure. 59 00:04:36,360 --> 00:04:41,850 And basically the main thing is that you want to keep in mind is that the token needs to be unpredictable 60 00:04:42,420 --> 00:04:47,460 and it cannot be used regardless of the way you're going to implement this. 61 00:04:47,460 --> 00:04:52,830 These are the two main things that you want to keep in mind because if it was predictable then the hacker 62 00:04:52,830 --> 00:04:58,710 will be able to create their own tokens and then embed them in the code and run the attack. 63 00:04:58,710 --> 00:05:00,920 Same token can be used. 64 00:05:01,020 --> 00:05:06,830 Then the hackers can just use their token or someone else's token to target their target. 65 00:05:07,350 --> 00:05:13,290 So in order to make the token unpredictable and make it so that it can be used then the token needs 66 00:05:13,290 --> 00:05:20,460 to be a large value so that the hacker can't do a brute force attack and discover what the token is 67 00:05:21,000 --> 00:05:27,420 the token is to be random so that the hacker will not be able to create their own tokens and it needs 68 00:05:27,420 --> 00:05:33,450 to be unique for each user because if users get the same token or similar tokens then they can pass 69 00:05:33,450 --> 00:05:37,490 them around and then the token that works for the hacker will work for other people. 70 00:05:37,500 --> 00:05:40,190 So that'll define the whole point. 71 00:05:40,800 --> 00:05:46,920 You can also increase the security of the token by include in other factors and the token generation 72 00:05:46,980 --> 00:05:48,000 algorithm. 73 00:05:48,000 --> 00:05:51,300 So you can include for example the date and time. 74 00:05:51,390 --> 00:05:56,170 Then combine it with secure random generator and then encrypt that. 75 00:05:56,280 --> 00:05:59,290 All of this is obviously happening at the server side. 76 00:05:59,340 --> 00:06:04,920 So the hacker will not be able to know what algorithm you're using because the code will be executed 77 00:06:05,010 --> 00:06:06,400 at the server side. 78 00:06:06,750 --> 00:06:12,650 You don't necessarily have to do this using a secure large and unique random number is enough. 79 00:06:12,780 --> 00:06:18,720 But if you want to increase the security then you can just add other factors and encrypt the token before 80 00:06:18,720 --> 00:06:20,250 you send it to the user. 81 00:06:20,250 --> 00:06:23,110 This is actually implemented in Matile day. 82 00:06:23,250 --> 00:06:25,200 So let me just show it to you in action. 83 00:06:25,960 --> 00:06:32,470 So I'm just going to go to Matile day in here. 84 00:06:32,510 --> 00:06:38,610 I'm going to go on a wasp then yes or as an add to blog. 85 00:06:38,690 --> 00:06:43,460 So this allows you to add a blog post so it doesn't allow you to change your password or anything it 86 00:06:43,460 --> 00:06:46,770 actually allows anonymous people to our blog posts as well. 87 00:06:46,790 --> 00:06:49,160 So you can't really ask people for a password. 88 00:06:49,190 --> 00:06:55,100 I'm actually going to go and toggle security so that it's the highest because it's at zero right now. 89 00:06:58,970 --> 00:07:00,720 So now it's the most secure. 90 00:07:01,160 --> 00:07:07,510 And if you right click this and go on is inspect element. 91 00:07:07,570 --> 00:07:15,680 Now I'm going to scroll up and as you can see we have the forum here and we have a hidden input with 92 00:07:15,680 --> 00:07:16,930 a very long value. 93 00:07:17,000 --> 00:07:18,660 And this is the token. 94 00:07:18,710 --> 00:07:24,560 So this has already been generated by the server and the server will refuse any requests that we send 95 00:07:24,560 --> 00:07:28,370 to it unless it has this specific token. 96 00:07:28,370 --> 00:07:31,260 And if I use this form and send it to someone else. 97 00:07:31,400 --> 00:07:37,660 Then again the requests that they will send will be refused because they'll get a different token this 98 00:07:37,730 --> 00:07:41,260 token was generated for me and for me only. 99 00:07:41,330 --> 00:07:47,120 So let me show you if I actually refresh right now I'm going to get a different token. 100 00:07:47,140 --> 00:07:53,740 And again if I refresh again I'll get a different token if I modify this. 101 00:07:54,050 --> 00:08:00,930 So let's say instead of the capital I at the end I'm going to put a small I if I submit this now 102 00:08:06,140 --> 00:08:08,210 it's giving me an error. 103 00:08:08,210 --> 00:08:14,360 But let me not change this so again I got a different token now and if I just submitted the way it is 104 00:08:18,860 --> 00:08:23,210 it's going to work and now we have a blog entry called test. 105 00:08:23,720 --> 00:08:24,830 So that's it. 106 00:08:24,830 --> 00:08:26,440 It's actually very very simple. 107 00:08:26,450 --> 00:08:33,110 I didn't want to go into too much details about how to create a random token and all that because that's 108 00:08:33,110 --> 00:08:36,350 going to be specific dependent on the programming language. 109 00:08:36,500 --> 00:08:38,890 That's the web application is programmed in. 110 00:08:39,110 --> 00:08:46,130 But I was I just wanted to show you the concept or the idea of how to secure web applications against 111 00:08:46,130 --> 00:08:47,820 this type of vulnerability. 112 00:08:47,840 --> 00:08:54,060 The whole idea is you want to make sure that the user submits their data through a page that you serve 113 00:08:54,290 --> 00:08:58,530 them and not by a page that was given to them by any other person. 114 00:08:58,550 --> 00:09:05,750 So in order to do that we generate a token at the server side this token needs to be long random and 115 00:09:05,750 --> 00:09:12,350 unique send that token with the page with the form and embedded as a hidden form. 116 00:09:12,350 --> 00:09:18,140 And then whenever a user submits the response make sure that they submit the same token that was given 117 00:09:18,140 --> 00:09:18,920 to them.