WEBVTT 00:00.000 --> 00:04.230 >> Let's talk about cross-site request forgery. 00:04.230 --> 00:06.720 Where cross-site scripting takes 00:06.720 --> 00:09.150 advantage of a user's trust in a website, 00:09.150 --> 00:11.820 cross-site request forgery is the opposite 00:11.820 --> 00:15.315 because it takes advantage of a website's trust in you. 00:15.315 --> 00:17.430 For example, you login to 00:17.430 --> 00:19.590 your bank's website and you get a token 00:19.590 --> 00:22.155 that says you've authenticated and you're good to go. 00:22.155 --> 00:24.540 But let's say that while you're logged in you 00:24.540 --> 00:27.135 also get an email that appears to be from your bank, 00:27.135 --> 00:29.690 and the message entices you to click on a link to 00:29.690 --> 00:32.525 learn about something or get some assistance. 00:32.525 --> 00:34.400 But what clicking on the link actually 00:34.400 --> 00:36.080 does is it sends a request to 00:36.080 --> 00:38.420 the bank website to do something like transfer 00:38.420 --> 00:41.165 some money or something along those lines, 00:41.165 --> 00:42.740 and it exploits the fact that you're 00:42.740 --> 00:44.330 logged into the site so 00:44.330 --> 00:45.620 the bank site trusts you and 00:45.620 --> 00:48.420 believes you have authorized the money transfer. 00:49.060 --> 00:51.350 This requires us to use 00:51.350 --> 00:54.065 some good common sense and watch for things like this. 00:54.065 --> 00:56.885 Generally speaking, when you're logged into your bank, 00:56.885 --> 00:58.760 you don't want to have any other windows open 00:58.760 --> 01:00.560 or other sessions open. 01:00.560 --> 01:01.925 You just want to log in the site, 01:01.925 --> 01:04.340 do what you need to do, and then logout. 01:04.340 --> 01:06.740 That's why these sites also log you out if there's 01:06.740 --> 01:09.305 no activity after a certain point of time. 01:09.305 --> 01:11.030 You want to keep this communication 01:11.030 --> 01:12.110 with your bank very time 01:12.110 --> 01:14.975 restricted because the longer that connection is open, 01:14.975 --> 01:17.250 the more vulnerable you are. 01:18.400 --> 01:21.710 Race conditions are all about timing. 01:21.710 --> 01:22.760 If I'm able to manipulate 01:22.760 --> 01:24.815 a system so that I throw off the timing, 01:24.815 --> 01:26.585 I can take advantage of that. 01:26.585 --> 01:28.280 There are a lot of processes that 01:28.280 --> 01:30.185 need that to happen in order. 01:30.185 --> 01:32.570 For example, I go to a website to 01:32.570 --> 01:35.315 login and I identify myself with my username, 01:35.315 --> 01:38.270 then I authenticate by providing a password, 01:38.270 --> 01:41.495 then I'm authorized to access services. 01:41.495 --> 01:43.700 But if an attacker can slow down 01:43.700 --> 01:46.295 the authentication and speed-up authorization, 01:46.295 --> 01:48.800 then the attacker can get authorized to access 01:48.800 --> 01:51.770 services without even having to prove his identity. 01:51.770 --> 01:54.145 That's a race condition. 01:54.145 --> 01:56.120 Or as another example, 01:56.120 --> 01:59.180 let's say I go to withdraw some money from an ATM. 01:59.180 --> 02:01.940 I make on my request and it checks my balance to see 02:01.940 --> 02:02.960 if I have enough money in 02:02.960 --> 02:04.985 my account to give me the funds, 02:04.985 --> 02:06.785 but what if I make a request? 02:06.785 --> 02:07.970 It gives me the funds, 02:07.970 --> 02:10.430 and then it checks my account status. 02:10.430 --> 02:12.830 That is not how it's supposed to work, 02:12.830 --> 02:14.690 and that could be a race condition 02:14.690 --> 02:17.100 which has to do with timing. 02:17.650 --> 02:20.180 There's a certain type of race condition 02:20.180 --> 02:24.390 called time-of-check/time-of-use or TOC/TOU. 02:24.390 --> 02:26.810 When a process needs access to 02:26.810 --> 02:29.105 a configuration file for instance, 02:29.105 --> 02:31.910 that process is going to validate that the configuration 02:31.910 --> 02:35.285 files there it contains the information that it needs, 02:35.285 --> 02:38.150 but what should happen is that the process should verify 02:38.150 --> 02:40.985 the files there and then immediately use it. 02:40.985 --> 02:43.340 But if the process verifies that the file is 02:43.340 --> 02:45.470 there and then 10 other things happen, 02:45.470 --> 02:48.560 well, an attacker could go in there and modify the file. 02:48.560 --> 02:51.455 Then by the time the process comes around to use it, 02:51.455 --> 02:54.800 it is no longer accurate and no longer has integrity. 02:54.800 --> 02:57.800 That's a time-of-check/time-of-use attack. 02:57.800 --> 03:00.395 Those are attacks on the system architecture, 03:00.395 --> 03:02.165 and it's all about timing. 03:02.165 --> 03:04.100 Now, we have a number of 03:04.100 --> 03:06.110 memory issues that can be attacks. 03:06.110 --> 03:08.435 They include: integer overflows, 03:08.435 --> 03:11.270 memory leaks, and buffer overflows. 03:11.270 --> 03:13.310 With an integer overflow, 03:13.310 --> 03:14.930 what happens is that they're values 03:14.930 --> 03:17.935 calculated that are outside of the expected range. 03:17.935 --> 03:21.500 For example, I asked for a number between one and five, 03:21.500 --> 03:23.555 and you give me the number 6. 03:23.555 --> 03:26.450 It's similar to a buffer overflow where I 03:26.450 --> 03:29.390 asked you for five characters and you give me seven. 03:29.390 --> 03:32.180 Both of these cause memory issues and 03:32.180 --> 03:34.355 input validation and sanitization 03:34.355 --> 03:35.975 should fix both of those, 03:35.975 --> 03:39.830 but if they don't then we have a problem on the back-end. 03:39.830 --> 03:42.500 Then other issues with memory can occur 03:42.500 --> 03:44.840 when applications just aren't well-written. 03:44.840 --> 03:46.730 They don't have their stack of memory that 03:46.730 --> 03:48.590 is allocated to the application, 03:48.590 --> 03:50.405 but when the application closes 03:50.405 --> 03:52.895 it doesn't properly release its memory. 03:52.895 --> 03:55.220 That could cause other applications to have 03:55.220 --> 03:58.650 conflicts and that could cause the system lock up. 03:59.200 --> 04:01.250 This chapter had lots of 04:01.250 --> 04:03.740 information and a lot of this is on the test, 04:03.740 --> 04:05.390 so you'll want to review it. 04:05.390 --> 04:07.415 We talked about types of attackers 04:07.415 --> 04:09.050 like hackers: white hat, 04:09.050 --> 04:10.655 black hat, and gray hat. 04:10.655 --> 04:13.395 We said that white hats are ethical hackers, 04:13.395 --> 04:15.060 but black and gray skirt 04:15.060 --> 04:17.865 the law or skirt ethical standards. 04:17.865 --> 04:20.180 We talked about a tax-like malware 04:20.180 --> 04:21.460 and how it can be distributed in 04:21.460 --> 04:24.695 a lot of different ways;through attachments in email, 04:24.695 --> 04:27.410 through backdoor software intrusions. 04:27.410 --> 04:30.335 We talked about viruses versus worms, 04:30.335 --> 04:32.735 then we talked about network-based attacks 04:32.735 --> 04:35.095 like Smurf and fragile attacks. 04:35.095 --> 04:38.210 We said those are all about spoofing a source address. 04:38.210 --> 04:40.640 We looked at Wi-Fi attacks and attacks on 04:40.640 --> 04:43.625 passwords with brute force and dictionary attacks. 04:43.625 --> 04:45.530 Later, we will fill that discussion 04:45.530 --> 04:47.360 out by talking about remote attacks, 04:47.360 --> 04:49.625 and pass-the-hash, and so forth. 04:49.625 --> 04:51.620 Then we wrap things up by talking 04:51.620 --> 04:53.465 about application attacks. 04:53.465 --> 04:55.010 We really want to know these for 04:55.010 --> 04:57.140 the exam especially things like 04:57.140 --> 04:59.180 cross-site scripting and the importance 04:59.180 --> 05:02.060 of input validation and sanitization. 05:02.060 --> 05:04.280 This is definitely a chapter to go back 05:04.280 --> 05:06.900 through with a fine toothcomb.