1 00:00:00,360 --> 00:00:06,220 So cross site request forgery or SRF is another session management problem. 2 00:00:06,960 --> 00:00:13,500 So this vulnerability hits the all the applications that set their authentication and session management 3 00:00:13,500 --> 00:00:16,760 mechanisms solely on the use of cookies. 4 00:00:17,010 --> 00:00:25,050 And yeah, I said earlier that Web applications use cookies for differentiating users, but I certainly 5 00:00:25,050 --> 00:00:27,810 did not say that this is 100 percent secure. 6 00:00:28,840 --> 00:00:30,720 So allow me to explain. 7 00:00:32,070 --> 00:00:38,460 Think of what you need to put into an HDP request when you perform an action on an application. 8 00:00:39,450 --> 00:00:43,740 You need to submit both the data and the session and to the Web server. 9 00:00:43,780 --> 00:00:50,400 Now, that way the server will understand it as your legitimate request and then it processes it. 10 00:00:51,370 --> 00:00:54,530 So the server can differentiate you by your session ID. 11 00:00:55,710 --> 00:01:00,510 And if somehow someone uses your session ID instead of you, what can happen? 12 00:01:01,750 --> 00:01:04,090 Well, here's where the problem arises. 13 00:01:05,070 --> 00:01:06,600 So let's see what we have. 14 00:01:07,630 --> 00:01:10,720 Open carry, as always, and log in to be web. 15 00:01:11,660 --> 00:01:17,180 Now, open cross site request forgery with the change password option from the menu. 16 00:01:18,450 --> 00:01:21,570 And here are several CSR scenarios here. 17 00:01:22,730 --> 00:01:28,100 And we're going to look at how they work, so the first one is a password change form. 18 00:01:29,330 --> 00:01:32,570 So also open burb and enable foxy piroxicam. 19 00:01:33,750 --> 00:01:36,810 And let's type something to change a password. 20 00:01:38,020 --> 00:01:39,730 And we have a request in berp. 21 00:01:40,860 --> 00:01:43,200 And this is the password change request. 22 00:01:44,680 --> 00:01:48,000 And this is a legitimate request, right? 23 00:01:49,120 --> 00:01:51,040 So I'm going to send it to the compare tool. 24 00:01:52,120 --> 00:01:53,110 And forward it. 25 00:01:55,000 --> 00:02:03,130 And looky here, the password has been changed, so now, right, click and view the page source. 26 00:02:04,350 --> 00:02:05,700 Here's a source of the form. 27 00:02:06,810 --> 00:02:09,780 This form produces the previous request. 28 00:02:10,750 --> 00:02:17,920 So don't you wonder if you use the same form in your application, so now send the request to be Web? 29 00:02:18,850 --> 00:02:21,430 How would be to behave in a situation like this? 30 00:02:22,430 --> 00:02:23,360 Why don't we have a look? 31 00:02:24,210 --> 00:02:25,470 So open up your terminal. 32 00:02:26,410 --> 00:02:32,140 Now, I quoted this page, which produces this same request as a password change form, you can download 33 00:02:32,140 --> 00:02:32,740 it from here. 34 00:02:34,610 --> 00:02:39,680 So here's an iFrame, which requests a password change from Web. 35 00:02:40,830 --> 00:02:42,600 And we also have a second option. 36 00:02:43,960 --> 00:02:46,870 And this one's almost the same as the actual form. 37 00:02:48,010 --> 00:02:55,360 So let's look at the values, so these are the values that we want to set as password. 38 00:02:57,600 --> 00:03:02,580 And the form submitted by a JavaScript code when the page opens. 39 00:03:04,000 --> 00:03:10,840 OK, now I'm going to clear all the information in Firefox and I'm going to open one of these pages 40 00:03:10,840 --> 00:03:12,250 from County directly. 41 00:03:14,100 --> 00:03:15,390 Remember to enable berp. 42 00:03:16,900 --> 00:03:23,320 Now, double click this one, and it will immediately open in a browser and Birbal capture it. 43 00:03:24,990 --> 00:03:26,770 So it's similar to the previous one, right? 44 00:03:28,070 --> 00:03:29,950 So send it to compare as well. 45 00:03:31,680 --> 00:03:32,490 You can drop it. 46 00:03:34,280 --> 00:03:36,230 And here's a source of the page. 47 00:03:39,140 --> 00:03:40,820 OK, so go to compare her. 48 00:03:42,140 --> 00:03:45,650 So Compar is yet another valuable tool in burb sweet. 49 00:03:47,350 --> 00:03:49,810 And both requests are here. 50 00:03:51,360 --> 00:03:55,020 And now click on words in order to compare them word for word. 51 00:03:56,360 --> 00:03:58,070 And here is a result. 52 00:03:59,320 --> 00:04:02,680 So the request on the right is our fake request. 53 00:04:03,760 --> 00:04:06,130 Is almost the same to the actual one. 54 00:04:07,380 --> 00:04:08,310 Can you see the difference? 55 00:04:09,190 --> 00:04:10,660 There's an important small header. 56 00:04:12,190 --> 00:04:14,530 So it's not the same, it's the cookie cutter. 57 00:04:15,740 --> 00:04:19,430 The request on the left is a legitimate and authenticated request. 58 00:04:20,860 --> 00:04:25,930 The other is not so the browser adds the cookie to the original request. 59 00:04:27,120 --> 00:04:30,570 Because the actual user triggers a password change form. 60 00:04:31,680 --> 00:04:38,130 So anyway, we can create such a fake request, but we cannot send it to the server on behalf of the 61 00:04:38,130 --> 00:04:42,300 actual user because we need the users session ID. 62 00:04:43,590 --> 00:04:49,200 So we need to force the user to open our page while he is displaying the same page. 63 00:04:50,090 --> 00:04:51,560 OK, so close it up and clear. 64 00:04:53,180 --> 00:05:01,760 So I'm going to go back to burb here again and I will open that page and remember to enable berp. 65 00:05:03,330 --> 00:05:05,130 So I'm going to change the password again. 66 00:05:08,680 --> 00:05:10,540 Send it to compare as well. 67 00:05:12,360 --> 00:05:17,640 OK, so as a victim, I'm displaying the page that contains an insecure form. 68 00:05:18,790 --> 00:05:24,250 Now, at the same time, I'll open a suspicious application in another tab in the same browser. 69 00:05:25,520 --> 00:05:30,910 And again, you need to use some social engineering techniques in order to deceive the victim. 70 00:05:32,580 --> 00:05:34,350 I almost forgot to enable berp again. 71 00:05:35,170 --> 00:05:38,460 OK, so refresh the suspicious page. 72 00:05:39,670 --> 00:05:41,560 And this is a fake request. 73 00:05:43,350 --> 00:05:45,570 Send it to compare as well. 74 00:05:46,720 --> 00:05:47,710 And just leave it. 75 00:05:49,270 --> 00:05:50,390 Now, go to compare. 76 00:05:52,190 --> 00:05:54,140 And click to see the difference between them. 77 00:05:55,520 --> 00:06:03,200 So this time, there is no important difference because the browser tries to request a server that is 78 00:06:03,230 --> 00:06:06,230 the server of the application that's open in another tab. 79 00:06:08,440 --> 00:06:12,400 So our fake request will go to the B Web server. 80 00:06:13,290 --> 00:06:17,520 And naturally, the browser adds a cookie header to the request. 81 00:06:18,730 --> 00:06:24,400 So now there is the user session ID in our FAQ request. 82 00:06:25,870 --> 00:06:28,030 So that way we can change the user's password. 83 00:06:29,480 --> 00:06:34,700 It's also an example of insecure resat or the change function in applications. 84 00:06:35,880 --> 00:06:37,260 All right, so go ahead and close it. 85 00:06:38,150 --> 00:06:39,740 And on this show, the result. 86 00:06:40,620 --> 00:06:44,250 So go to my admin interface, a B box. 87 00:06:45,880 --> 00:06:47,650 And then browse the user's table. 88 00:06:49,050 --> 00:06:52,020 And this is the changed password. 89 00:06:53,820 --> 00:06:55,830 So search it on Google. 90 00:06:57,220 --> 00:06:58,180 Go to the first one. 91 00:07:00,060 --> 00:07:04,440 And here is a result, we're able to change the victim's password.