WEBVTT 1 00:00:00.240 --> 00:00:01.500 In this lesson, 2 00:00:01.500 --> 00:00:05.370 we will learn about authorization vulnerabilities. 3 00:00:05.370 --> 00:00:08.040 Authorization vulnerabilities occur 4 00:00:08.040 --> 00:00:12.450 when a system improperly manages access controls, 5 00:00:12.450 --> 00:00:17.450 allowing unauthorized users or processes to perform actions 6 00:00:17.520 --> 00:00:20.310 beyond their intent permissions. 7 00:00:20.310 --> 00:00:24.840 Authorization vulnerabilities include a confused deputy, 8 00:00:24.840 --> 00:00:28.620 weak ciphers, and vulnerable third parties. 9 00:00:28.620 --> 00:00:33.030 The confused deputy vulnerability arises when a program 10 00:00:33.030 --> 00:00:37.320 with higher privileges is tricked into performing actions 11 00:00:37.320 --> 00:00:39.690 on behalf of an attacker. 12 00:00:39.690 --> 00:00:43.410 Next, weak ciphers in encryption can lead 13 00:00:43.410 --> 00:00:47.010 to ineffective protection of sensitive data, 14 00:00:47.010 --> 00:00:51.480 enabling attackers to intercept or manipulate information 15 00:00:51.480 --> 00:00:54.270 that should be securely transmitted. 16 00:00:54.270 --> 00:00:58.410 Finally, vulnerable third parties are external services 17 00:00:58.410 --> 00:01:02.310 or partner organizations that, if compromised, 18 00:01:02.310 --> 00:01:05.400 can be used to gain unauthorized access 19 00:01:05.400 --> 00:01:08.370 to a system's resources or data. 20 00:01:08.370 --> 00:01:12.570 Let's learn more about a confused deputy, weak ciphers, 21 00:01:12.570 --> 00:01:14.910 and vulnerable third parties. 22 00:01:14.910 --> 00:01:18.120 First, we have a confused deputy. 23 00:01:18.120 --> 00:01:21.390 The confused deputy vulnerability arises 24 00:01:21.390 --> 00:01:23.880 when an attacker exploits a program 25 00:01:23.880 --> 00:01:26.730 or service with higher privileges 26 00:01:26.730 --> 00:01:28.770 to perform actions the attacker 27 00:01:28.770 --> 00:01:31.770 could not typically carry out on their own. 28 00:01:31.770 --> 00:01:34.590 This vulnerability takes advantage 29 00:01:34.590 --> 00:01:38.040 of a privileged program known as the deputy, 30 00:01:38.040 --> 00:01:40.860 which has legitimate access to resources 31 00:01:40.860 --> 00:01:44.250 or data restricted from the attacker. 32 00:01:44.250 --> 00:01:47.820 When the attacker manipulates this privileged program, 33 00:01:47.820 --> 00:01:50.880 they can bypass authorization controls 34 00:01:50.880 --> 00:01:53.940 to access or modify resources 35 00:01:53.940 --> 00:01:58.470 by making requests that the deputy believes are legitimate. 36 00:01:58.470 --> 00:02:00.540 The deputy gets confused 37 00:02:00.540 --> 00:02:02.970 because it executes the request 38 00:02:02.970 --> 00:02:06.780 without sufficient validation of its origin, 39 00:02:06.780 --> 00:02:11.130 effectively becoming an unknown participant in the exploit. 40 00:02:11.130 --> 00:02:14.400 An example of a confused deputy attack 41 00:02:14.400 --> 00:02:18.510 involves a proxy server that performs privileged actions 42 00:02:18.510 --> 00:02:20.640 on behalf of users. 43 00:02:20.640 --> 00:02:24.480 So suppose a file server allows users 44 00:02:24.480 --> 00:02:26.700 to request specific files, 45 00:02:26.700 --> 00:02:29.940 but only through a separate proxy server. 46 00:02:29.940 --> 00:02:34.470 If an attacker were to craft a request to the proxy server 47 00:02:34.470 --> 00:02:36.600 to access a restricted file, 48 00:02:36.600 --> 00:02:40.920 the proxy server may inadvertently honor this request. 49 00:02:40.920 --> 00:02:43.980 And since the proxy server has high privileges, 50 00:02:43.980 --> 00:02:46.860 this would effectively bypass access checks 51 00:02:46.860 --> 00:02:49.680 of the attacker requesting the file. 52 00:02:49.680 --> 00:02:53.490 In this case, the proxy server is the deputy, 53 00:02:53.490 --> 00:02:57.210 trusting the maliciously crafted request as valid 54 00:02:57.210 --> 00:03:01.410 and providing unauthorized access to the attacker. 55 00:03:01.410 --> 00:03:02.670 This type of attack 56 00:03:02.670 --> 00:03:05.820 can be particularly damaging in environments 57 00:03:05.820 --> 00:03:08.340 where privileged services interact 58 00:03:08.340 --> 00:03:10.980 with unvalidated user input 59 00:03:10.980 --> 00:03:15.390 or when services are unaware of user permissions. 60 00:03:15.390 --> 00:03:19.290 So to prevent confused deputy vulnerabilities, 61 00:03:19.290 --> 00:03:23.790 applications should use robust access control mechanisms 62 00:03:23.790 --> 00:03:27.360 at each stage of the authorization process, 63 00:03:27.360 --> 00:03:30.150 ensuring that every request is checked 64 00:03:30.150 --> 00:03:33.330 against the user's original permission. 65 00:03:33.330 --> 00:03:37.470 Programs should also validate all permissions directly 66 00:03:37.470 --> 00:03:38.910 and on their own 67 00:03:38.910 --> 00:03:41.760 rather than relying on intermediaries. 68 00:03:41.760 --> 00:03:45.480 One effective method of doing this is to use tokens 69 00:03:45.480 --> 00:03:48.690 or certificates that verify the permissions 70 00:03:48.690 --> 00:03:51.570 of the user requesting the action. 71 00:03:51.570 --> 00:03:53.910 By checking permissions at each point 72 00:03:53.910 --> 00:03:56.730 and limiting intermediary permissions, 73 00:03:56.730 --> 00:04:00.630 the application can prevent unauthorized access 74 00:04:00.630 --> 00:04:03.000 through a confused deputy. 75 00:04:03.000 --> 00:04:06.120 Second, we have weak ciphers. 76 00:04:06.120 --> 00:04:09.270 Weak ciphers represent a vulnerability 77 00:04:09.270 --> 00:04:13.710 where outdated or insecure cryptographic algorithms fail 78 00:04:13.710 --> 00:04:17.010 to protect sensitive information effectively. 79 00:04:17.010 --> 00:04:22.010 This includes both weak hashing algorithms like MD5 and SHA1 80 00:04:22.740 --> 00:04:26.643 and outdated encryption ciphers such as DES and RC4. 81 00:04:28.336 --> 00:04:30.780 MD5 and SHA1 are weak 82 00:04:30.780 --> 00:04:34.260 because they are susceptible to collision attacks 83 00:04:34.260 --> 00:04:37.440 where attackers can produce identical hashes 84 00:04:37.440 --> 00:04:39.510 for different inputs. 85 00:04:39.510 --> 00:04:42.120 DES and RC4 are weak 86 00:04:42.120 --> 00:04:46.350 because DES has a short keeling that makes it vulnerable 87 00:04:46.350 --> 00:04:48.150 to brute force attacks, 88 00:04:48.150 --> 00:04:51.060 while RC4 has structural flaws 89 00:04:51.060 --> 00:04:53.490 that lead to predictable patterns, 90 00:04:53.490 --> 00:04:57.090 making it susceptible to cryptographic attacks. 91 00:04:57.090 --> 00:05:00.390 These weaknesses mean that sensitive information 92 00:05:00.390 --> 00:05:03.030 protected by these hashing algorithms 93 00:05:03.030 --> 00:05:05.940 and ciphers is at risk of exposure 94 00:05:05.940 --> 00:05:10.320 or tampering by attackers who leverage advanced techniques 95 00:05:10.320 --> 00:05:13.440 and the increased processing capabilities 96 00:05:13.440 --> 00:05:16.110 of today's hardware to break them. 97 00:05:16.110 --> 00:05:20.130 For example, imagine a legacy banking application 98 00:05:20.130 --> 00:05:23.010 that still relies on DES encryption 99 00:05:23.010 --> 00:05:25.680 to protect stored customer data, 100 00:05:25.680 --> 00:05:28.770 including passwords and account numbers. 101 00:05:28.770 --> 00:05:32.880 Although the data appears secure because it's encrypted, 102 00:05:32.880 --> 00:05:37.170 DES's short 56-bit key makes it vulnerable 103 00:05:37.170 --> 00:05:39.060 to brute force attacks. 104 00:05:39.060 --> 00:05:43.440 So an attacker who gains access to this encrypted data, 105 00:05:43.440 --> 00:05:45.420 perhaps through a data breach, 106 00:05:45.420 --> 00:05:48.960 could use the processing power of a cloud service 107 00:05:48.960 --> 00:05:53.010 and attacker tools such as Hashcat and John the Ripper 108 00:05:53.010 --> 00:05:57.720 to attempt every possible key combination within hours. 109 00:05:57.720 --> 00:06:02.340 Once decrypted, the attacker can access customer passwords, 110 00:06:02.340 --> 00:06:07.020 allowing them to log into banking accounts, transfer funds, 111 00:06:07.020 --> 00:06:09.510 or change account details. 112 00:06:09.510 --> 00:06:13.320 So to avoid weak cipher vulnerabilities, 113 00:06:13.320 --> 00:06:17.610 developers should regularly update encryption standards 114 00:06:17.610 --> 00:06:22.610 using strong algorithms like AES256 for encryption 115 00:06:22.830 --> 00:06:25.500 and SHA256 for hashing, 116 00:06:25.500 --> 00:06:29.370 both of which are resistant to common attacks. 117 00:06:29.370 --> 00:06:32.550 Next, implement secure transport layers 118 00:06:32.550 --> 00:06:35.160 such as transport layer security 119 00:06:35.160 --> 00:06:37.500 with up-to-date configurations 120 00:06:37.500 --> 00:06:39.570 to protect data in transit 121 00:06:39.570 --> 00:06:43.260 from interception or decryption by attackers. 122 00:06:43.260 --> 00:06:46.830 Finally, conduct regular security audits 123 00:06:46.830 --> 00:06:48.630 of encryption protocols 124 00:06:48.630 --> 00:06:51.930 to ensure that third party dependencies adhere 125 00:06:51.930 --> 00:06:54.360 to secure cipher standards. 126 00:06:54.360 --> 00:06:57.882 Third and last, we have third parties. 127 00:06:57.882 --> 00:07:02.280 Authorization vulnerabilities through third parties occur 128 00:07:02.280 --> 00:07:05.880 when an application relies on external services, 129 00:07:05.880 --> 00:07:08.490 application programming interfaces, 130 00:07:08.490 --> 00:07:12.630 or partner organizations to perform critical functions 131 00:07:12.630 --> 00:07:14.850 or handle sensitive data. 132 00:07:14.850 --> 00:07:17.730 This is because when a third-party service 133 00:07:17.730 --> 00:07:22.020 or partner organization integrates with an application, 134 00:07:22.020 --> 00:07:24.120 it often requires permissions 135 00:07:24.120 --> 00:07:27.990 to access specific resources or data. 136 00:07:27.990 --> 00:07:31.200 So if a third party is compromised, 137 00:07:31.200 --> 00:07:34.410 attackers can exploit the trust relationship 138 00:07:34.410 --> 00:07:37.920 between the application and the third party, 139 00:07:37.920 --> 00:07:42.210 using it as a backdoor to gain unauthorized access 140 00:07:42.210 --> 00:07:43.740 to sensitive data 141 00:07:43.740 --> 00:07:47.970 or critical functionality in the primary application. 142 00:07:47.970 --> 00:07:51.330 For instance, if a web application relies 143 00:07:51.330 --> 00:07:55.364 on a third-party payment processor to handle transactions 144 00:07:55.364 --> 00:07:58.620 and that processor becomes compromised, 145 00:07:58.620 --> 00:08:00.210 attackers could intercept 146 00:08:00.210 --> 00:08:04.560 and manipulate the data flowing through this integration. 147 00:08:04.560 --> 00:08:07.380 This could allow them to redirect payments, 148 00:08:07.380 --> 00:08:09.720 steal credit card information, 149 00:08:09.720 --> 00:08:12.150 or inject malicious code 150 00:08:12.150 --> 00:08:15.420 that affects other parts of the application. 151 00:08:15.420 --> 00:08:18.510 So to mitigate risks associated 152 00:08:18.510 --> 00:08:20.940 with third-party vulnerabilities, 153 00:08:20.940 --> 00:08:25.320 companies should rigorously evaluate the security practices 154 00:08:25.320 --> 00:08:28.830 of all external partners and services 155 00:08:28.830 --> 00:08:33.420 before integrating them into their systems and workflows. 156 00:08:33.420 --> 00:08:35.370 Regular security audits, 157 00:08:35.370 --> 00:08:38.190 due diligence during vendor selection. 158 00:08:38.190 --> 00:08:41.910 and limiting access permissions for third-party services 159 00:08:41.910 --> 00:08:45.180 can significantly reduce this risk. 160 00:08:45.180 --> 00:08:49.920 Additionally, using secure APIs with restricted permissions 161 00:08:49.920 --> 00:08:51.540 for each integration 162 00:08:51.540 --> 00:08:54.960 and continually monitoring third-party services 163 00:08:54.960 --> 00:08:58.260 for compliance with industry security standards 164 00:08:58.260 --> 00:09:02.310 can strengthen security around third-party dependencies. 165 00:09:02.310 --> 00:09:07.310 So remember, authorization vulnerabilities arise 166 00:09:07.440 --> 00:09:10.920 when a system fails to manage access controls, 167 00:09:10.920 --> 00:09:14.670 allowing unauthorized actions or access. 168 00:09:14.670 --> 00:09:17.460 Key vulnerabilities in this area 169 00:09:17.460 --> 00:09:21.150 include the confused deputy, weak ciphers, 170 00:09:21.150 --> 00:09:23.220 and third-party risks. 171 00:09:23.220 --> 00:09:27.120 A confused deputy occurs when a privileged program 172 00:09:27.120 --> 00:09:31.470 mistakenly performs actions on behalf of an attacker, 173 00:09:31.470 --> 00:09:34.590 bypassing regular authorization. 174 00:09:34.590 --> 00:09:37.440 Next, weak ciphers are outdated 175 00:09:37.440 --> 00:09:40.530 or insecure cryptographic algorithms, 176 00:09:40.530 --> 00:09:44.340 which lead sensitive data susceptible to interception 177 00:09:44.340 --> 00:09:46.170 or manipulation. 178 00:09:46.170 --> 00:09:49.620 Finally, third-party vulnerabilities occur 179 00:09:49.620 --> 00:09:52.170 when compromised external services 180 00:09:52.170 --> 00:09:56.640 or partner organizations give attackers a back door 181 00:09:56.640 --> 00:10:01.020 into sensitive resources within the primary application. 182 00:10:01.020 --> 00:10:05.130 Addressing these risks with careful security practices 183 00:10:05.130 --> 00:10:09.363 and regular audits can ensure a secure network.