WEBVTT 1 00:00:00.000 --> 00:00:01.470 In this lesson, 2 00:00:01.470 --> 00:00:04.860 we will learn about injection vulnerabilities. 3 00:00:04.860 --> 00:00:08.160 Injection vulnerabilities occur when an attacker 4 00:00:08.160 --> 00:00:12.056 is able to inject malicious code into a system 5 00:00:12.056 --> 00:00:15.660 through an input field or other interface. 6 00:00:15.660 --> 00:00:18.210 Specific injection vulnerabilities 7 00:00:18.210 --> 00:00:21.717 include command injection, code injection, 8 00:00:21.717 --> 00:00:25.537 cross-site scripting, cross-site request forgery, 9 00:00:25.537 --> 00:00:30.330 server-side request forgery, and deserialization. 10 00:00:30.330 --> 00:00:32.910 Command injection occurs when an attacker 11 00:00:32.910 --> 00:00:36.469 exploits vulnerabilities in a system to execute 12 00:00:36.469 --> 00:00:40.920 arbitrary commands on the host operating system. 13 00:00:40.920 --> 00:00:44.211 Code injection involves inserting malicious code 14 00:00:44.211 --> 00:00:46.567 into a vulnerable application, 15 00:00:46.567 --> 00:00:50.420 which is then executed by that application. 16 00:00:50.420 --> 00:00:54.930 An SQL or SEQUEL injection attack occurs when an attacker 17 00:00:54.930 --> 00:00:59.600 inserts malicious SQL commands into a database query 18 00:00:59.600 --> 00:01:02.850 for the purpose of manipulating the database 19 00:01:02.850 --> 00:01:05.850 to execute unauthorized actions, 20 00:01:05.850 --> 00:01:07.950 altering or deleting records, 21 00:01:07.950 --> 00:01:12.510 or even gaining administrative control over the database. 22 00:01:12.510 --> 00:01:16.681 Cross-site scripting abbreviated as XSS occurs 23 00:01:16.681 --> 00:01:21.681 when an attacker injects malicious scripts into web pages. 24 00:01:21.780 --> 00:01:26.640 Next, cross-site request forgery or CSRF attacks 25 00:01:26.640 --> 00:01:30.230 involve manipulating a user into performing actions 26 00:01:30.230 --> 00:01:32.310 they did not intend, 27 00:01:32.310 --> 00:01:36.420 abusing the trust between a client and a server. 28 00:01:36.420 --> 00:01:41.040 Next, a server-side request forgery or SSRF 29 00:01:41.040 --> 00:01:44.220 allows an attacker to force a server 30 00:01:44.220 --> 00:01:46.410 to make unauthorized requests 31 00:01:46.410 --> 00:01:50.160 to internal systems or external resources, 32 00:01:50.160 --> 00:01:53.760 abusing the trust between a frontend server 33 00:01:53.760 --> 00:01:56.940 and a backend or internal resource. 34 00:01:56.940 --> 00:02:01.140 Finally, deserialization attacks occur when an attacker 35 00:02:01.140 --> 00:02:04.770 injects malicious data into an application 36 00:02:04.770 --> 00:02:07.710 that processes the data by converting it 37 00:02:07.710 --> 00:02:12.710 from a serialized format back into its original object form 38 00:02:12.930 --> 00:02:16.740 to execute harmful code embedded in the data, 39 00:02:16.740 --> 00:02:19.100 leading to remote code execution, 40 00:02:19.100 --> 00:02:23.010 privilege escalation, or data corruption. 41 00:02:23.010 --> 00:02:26.010 Let's learn more about commanded injection, 42 00:02:26.010 --> 00:02:28.800 code injection, cross-site scripting, 43 00:02:28.800 --> 00:02:30.930 cross-site request forgery, 44 00:02:30.930 --> 00:02:35.610 server-side request forgery, and deserialization. 45 00:02:35.610 --> 00:02:38.160 Then, we'll conduct a demonstration 46 00:02:38.160 --> 00:02:40.618 of stored cross-site scripting. 47 00:02:40.618 --> 00:02:44.100 First, we have command injection. 48 00:02:44.100 --> 00:02:46.468 Command injection is a vulnerability 49 00:02:46.468 --> 00:02:50.186 that allows an attacker to run arbitrary commands 50 00:02:50.186 --> 00:02:52.830 on the host operating system 51 00:02:52.830 --> 00:02:55.980 by exploiting flaws in an application. 52 00:02:55.980 --> 00:02:58.800 When an application takes user input 53 00:02:58.800 --> 00:03:01.470 and inserts it into a system command, 54 00:03:01.470 --> 00:03:04.740 it can unintentionally allow malicious commands 55 00:03:04.740 --> 00:03:07.485 to be executed if proper validation 56 00:03:07.485 --> 00:03:10.920 and sanitization are not in place. 57 00:03:10.920 --> 00:03:14.970 This can give attackers access to system level functions, 58 00:03:14.970 --> 00:03:18.480 enabling them to read or modify files, 59 00:03:18.480 --> 00:03:23.100 alter system settings, or compromise sensitive data. 60 00:03:23.100 --> 00:03:25.920 A successful command injection attack 61 00:03:25.920 --> 00:03:30.270 could even let an attacker gain unauthorized access 62 00:03:30.270 --> 00:03:32.640 to other parts of the network. 63 00:03:32.640 --> 00:03:35.490 Since command injection interacts 64 00:03:35.490 --> 00:03:37.890 with the host operating system, 65 00:03:37.890 --> 00:03:41.010 the potential impact is extensive. 66 00:03:41.010 --> 00:03:45.175 Attackers might use this vulnerability to open back doors, 67 00:03:45.175 --> 00:03:50.028 escalate privileges, or execute denial-of-service attacks, 68 00:03:50.028 --> 00:03:54.000 effectively disrupting normal operations. 69 00:03:54.000 --> 00:03:58.770 In the worst cases, command injection could allow attackers 70 00:03:58.770 --> 00:04:02.910 to fully take over the system, leading to data breaches 71 00:04:02.910 --> 00:04:06.960 and severe loss of control over the infrastructure. 72 00:04:06.960 --> 00:04:11.760 So, command injection underscores the need for applications 73 00:04:11.760 --> 00:04:15.840 to strictly validate and sanitize all inputs, 74 00:04:15.840 --> 00:04:18.052 particularly those that interact 75 00:04:18.052 --> 00:04:21.600 with underlying operating systems. 76 00:04:21.600 --> 00:04:24.750 Coming onto the screen now is an example 77 00:04:24.750 --> 00:04:29.340 of what a command injection might look like in a log. 78 00:04:29.340 --> 00:04:32.790 In this example, the application is intended 79 00:04:32.790 --> 00:04:37.350 to execute a simple ping command to diontraining.com 80 00:04:37.350 --> 00:04:39.210 based on the user's input. 81 00:04:39.210 --> 00:04:41.760 That's its design and function. 82 00:04:41.760 --> 00:04:45.420 However, an attacker has manipulated the input 83 00:04:45.420 --> 00:04:48.407 by injecting the semicolon rm -rf, 84 00:04:51.060 --> 00:04:54.480 and then a file path to important data. 85 00:04:54.480 --> 00:04:56.070 This has been inserted 86 00:04:56.070 --> 00:04:59.550 after the initial and legitimate command. 87 00:04:59.550 --> 00:05:04.550 The rm -rf command is used to forcefully delete files 88 00:05:04.740 --> 00:05:07.920 or directories on Unix-based systems, 89 00:05:07.920 --> 00:05:10.320 making it highly destructive. 90 00:05:10.320 --> 00:05:11.793 In another example, 91 00:05:11.793 --> 00:05:16.410 the following could be put into the ping application. 92 00:05:16.410 --> 00:05:18.597 This example on the screen now 93 00:05:18.597 --> 00:05:21.540 would ping diontraining.com 94 00:05:21.540 --> 00:05:24.360 and then execute a second command, 95 00:05:24.360 --> 00:05:29.360 which starts up a Bash shell with the /bin/sh 96 00:05:30.300 --> 00:05:34.007 and then redirects it via a pipe over to Netcat 97 00:05:34.007 --> 00:05:39.007 at a domain called hacked.diontraining.com through port 443, 98 00:05:40.740 --> 00:05:42.870 which would be set up to receive 99 00:05:42.870 --> 00:05:45.300 the shell Netcat is delivering. 100 00:05:45.300 --> 00:05:46.860 This would essentially give 101 00:05:46.860 --> 00:05:51.720 a full interactive command line access to the web server. 102 00:05:51.720 --> 00:05:55.560 As stated earlier, you can prevent command injection 103 00:05:55.560 --> 00:05:58.290 by conducting proper input validation 104 00:05:58.290 --> 00:06:01.620 on input received from any user. 105 00:06:01.620 --> 00:06:04.260 In the case of this web application, 106 00:06:04.260 --> 00:06:09.260 it should only accept IP addresses or domain names as input. 107 00:06:09.510 --> 00:06:13.170 Additionally, it should only allow IP addresses 108 00:06:13.170 --> 00:06:17.340 or domain names to be pinged using the application 109 00:06:17.340 --> 00:06:21.579 and anything after dotcom should be ignored or stripped 110 00:06:21.579 --> 00:06:26.220 before sending the user's input to the ping command. 111 00:06:26.220 --> 00:06:28.671 Second, we have code injection. 112 00:06:28.671 --> 00:06:31.620 Code injection involves the insertion 113 00:06:31.620 --> 00:06:34.566 of malicious code into an application, 114 00:06:34.566 --> 00:06:38.610 which is then executed by that application. 115 00:06:38.610 --> 00:06:41.640 Typically with the application's permissions. 116 00:06:41.640 --> 00:06:45.810 This type of injection can occur when an application 117 00:06:45.810 --> 00:06:48.273 dynamically includes user input 118 00:06:48.273 --> 00:06:51.390 as part of the code it executes. 119 00:06:51.390 --> 00:06:54.803 If proper input validation is not applied, 120 00:06:54.803 --> 00:06:59.075 attackers can insert their own code, potentially hijacking 121 00:06:59.075 --> 00:07:02.610 the application's intended functionality. 122 00:07:02.610 --> 00:07:06.157 So, code injection can compromise data security, 123 00:07:06.157 --> 00:07:09.390 expose confidential information, 124 00:07:09.390 --> 00:07:12.210 or lead to unauthorized actions, 125 00:07:12.210 --> 00:07:14.550 often allowing attackers access 126 00:07:14.550 --> 00:07:17.460 to sensitive application functions. 127 00:07:17.460 --> 00:07:19.686 In contrast, command injection 128 00:07:19.686 --> 00:07:24.060 directly executes system commands on a server, 129 00:07:24.060 --> 00:07:28.770 while code injection affects only the application behavior. 130 00:07:28.770 --> 00:07:32.346 Therefore, code injection typically needs to be conducted 131 00:07:32.346 --> 00:07:36.930 in the same programming language as the application. 132 00:07:36.930 --> 00:07:39.420 A successful code injection attack 133 00:07:39.420 --> 00:07:44.130 can disrupt normal operations, modify or delete records, 134 00:07:44.130 --> 00:07:46.740 and potentially grant attackers access 135 00:07:46.740 --> 00:07:50.118 to underlying resources or other applications 136 00:07:50.118 --> 00:07:52.260 connected to the system. 137 00:07:52.260 --> 00:07:54.338 But it does not offer direct access 138 00:07:54.338 --> 00:07:59.338 to the host operating system like command injection does. 139 00:07:59.340 --> 00:08:01.320 But because code injection 140 00:08:01.320 --> 00:08:05.190 often exploits weaknesses in the application layer, 141 00:08:05.190 --> 00:08:07.770 it can allow an attacker to bypass 142 00:08:07.770 --> 00:08:10.890 other security controls like firewalls. 143 00:08:10.890 --> 00:08:13.311 So again, sanitizing input 144 00:08:13.311 --> 00:08:16.620 and avoiding dynamically executed code 145 00:08:16.620 --> 00:08:21.620 that includes user input can mitigate code injection risks. 146 00:08:21.930 --> 00:08:23.610 Coming up on the screen now 147 00:08:23.610 --> 00:08:26.700 is a simple example of code injection. 148 00:08:26.700 --> 00:08:30.840 Imagine a web application that lets users enter their name 149 00:08:30.840 --> 00:08:33.450 to create a personalized greeting. 150 00:08:33.450 --> 00:08:35.324 We can see this in the code. 151 00:08:35.324 --> 00:08:39.122 If the application directly embeds the user input 152 00:08:39.122 --> 00:08:42.030 into the code without validation, 153 00:08:42.030 --> 00:08:44.100 an attacker could manipulate it. 154 00:08:44.100 --> 00:08:47.760 In this example, in the user input section, 155 00:08:47.760 --> 00:08:49.920 the first line of code attempts 156 00:08:49.920 --> 00:08:52.560 to list files in a server directory 157 00:08:52.560 --> 00:08:55.140 instead of just printing the greeting. 158 00:08:55.140 --> 00:08:57.390 It's done this way because the user 159 00:08:57.390 --> 00:09:01.552 has provided input to use the os.system command 160 00:09:01.552 --> 00:09:05.340 and the ls.command within a shell. 161 00:09:05.340 --> 00:09:08.280 This demonstrates how dangerous it can be 162 00:09:08.280 --> 00:09:11.640 to execute user input as code. 163 00:09:11.640 --> 00:09:16.080 Preventing these risks involves properly validating inputs 164 00:09:16.080 --> 00:09:20.580 and avoiding functions that evaluate raw user data directly, 165 00:09:20.580 --> 00:09:22.830 such as the EVAL function, 166 00:09:22.830 --> 00:09:25.830 which was used in the previous example. 167 00:09:25.830 --> 00:09:28.560 Third, we have cross-site scripting. 168 00:09:28.560 --> 00:09:32.190 Cross-site scripting comes in three main types. 169 00:09:32.190 --> 00:09:36.898 Reflected, stored, and DOM-based cross-site scripting. 170 00:09:36.898 --> 00:09:41.490 Each type has distinct characteristics and attack methods, 171 00:09:41.490 --> 00:09:45.360 but all rely on the failure of input validation, 172 00:09:45.360 --> 00:09:49.350 and have the potential to cause significant security issues 173 00:09:49.350 --> 00:09:51.510 by injecting malicious scripts 174 00:09:51.510 --> 00:09:54.090 into a vulnerable application. 175 00:09:54.090 --> 00:09:56.294 Reflected cross-site scripting occurs 176 00:09:56.294 --> 00:10:01.294 when an attacker injects a script into a URL or form, 177 00:10:01.680 --> 00:10:05.626 which is executed and then referenced back to the user 178 00:10:05.626 --> 00:10:09.660 without proper validation or sanitization. 179 00:10:09.660 --> 00:10:13.140 This attack is typically delivered through phishing links 180 00:10:13.140 --> 00:10:14.796 where an unsuspecting user 181 00:10:14.796 --> 00:10:18.780 clicks on a URL containing the injected script. 182 00:10:18.780 --> 00:10:22.320 The script then executes in the victim's browser, 183 00:10:22.320 --> 00:10:25.560 allowing the attacker to steal sensitive data 184 00:10:25.560 --> 00:10:29.520 such as session cookies or personal information. 185 00:10:29.520 --> 00:10:32.610 Since the attack is not stored on the server, 186 00:10:32.610 --> 00:10:34.680 it is only active for the user 187 00:10:34.680 --> 00:10:38.310 who interacts with the specially crafted link. 188 00:10:38.310 --> 00:10:40.410 The following is an example 189 00:10:40.410 --> 00:10:42.900 of reflected cross-site scripting 190 00:10:42.900 --> 00:10:45.420 in a vulnerable search functionality 191 00:10:45.420 --> 00:10:47.460 that displays the search query 192 00:10:47.460 --> 00:10:50.790 back to the user without validation. 193 00:10:50.790 --> 00:10:54.690 In this attack, which is partially displayed on the screen, 194 00:10:54.690 --> 00:10:59.018 the user will have clicked on a link that contains a query 195 00:10:59.018 --> 00:11:02.700 with a script alert, "You have been hacked!" 196 00:11:02.700 --> 00:11:05.280 and then close script tag. 197 00:11:05.280 --> 00:11:06.990 This would display an alert 198 00:11:06.990 --> 00:11:09.330 when the user clicks on the link. 199 00:11:09.330 --> 00:11:12.120 This is reflected cross-site scripting, 200 00:11:12.120 --> 00:11:16.466 executing a script by reflecting unsanitized input 201 00:11:16.466 --> 00:11:18.350 back to the user. 202 00:11:18.350 --> 00:11:22.500 Next, stored cross-site scripting injects a script 203 00:11:22.500 --> 00:11:25.500 saved on the server to any user 204 00:11:25.500 --> 00:11:27.655 who renders the infected page. 205 00:11:27.655 --> 00:11:30.990 In a stored cross-site scripting attack, 206 00:11:30.990 --> 00:11:35.910 attackers inject malicious code into fields like comments, 207 00:11:35.910 --> 00:11:39.210 forum posts, or a profile information, 208 00:11:39.210 --> 00:11:42.540 which is stored in the applications database 209 00:11:42.540 --> 00:11:46.533 and is executed by any user who visits the page. 210 00:11:46.533 --> 00:11:49.020 This type of cross-site scripting 211 00:11:49.020 --> 00:11:51.930 can reach a large number of users, 212 00:11:51.930 --> 00:11:55.800 and is often more to detect and fix 213 00:11:55.800 --> 00:11:59.250 as the payload persists across sessions. 214 00:11:59.250 --> 00:12:02.640 For example, if a social media platform 215 00:12:02.640 --> 00:12:07.020 fails to validate or sanitize user-generated content, 216 00:12:07.020 --> 00:12:08.852 an attacker could post a comment 217 00:12:08.852 --> 00:12:11.850 containing a malicious script. 218 00:12:11.850 --> 00:12:16.290 Each time users view the page the malicious script is on? 219 00:12:16.290 --> 00:12:19.350 The script executes in their browsers, 220 00:12:19.350 --> 00:12:21.090 stealing session tokens, 221 00:12:21.090 --> 00:12:24.150 or redirecting them to phishing sites. 222 00:12:24.150 --> 00:12:27.300 Finally, DOM or document-object 223 00:12:27.300 --> 00:12:29.670 model-based cross-site scripting 224 00:12:29.670 --> 00:12:34.440 occurs when the malicious script is executed as a result 225 00:12:34.440 --> 00:12:39.270 of modifying the document object model on the client side. 226 00:12:39.270 --> 00:12:43.683 This attack relies on vulnerable client-side JavaScript code 227 00:12:43.683 --> 00:12:48.683 that dynamically generates content based on user input. 228 00:12:48.960 --> 00:12:52.500 In a DOM-based cross-site scripting attack, 229 00:12:52.500 --> 00:12:55.200 no data is sent to the server. 230 00:12:55.200 --> 00:12:58.230 Instead, the attack manipulates the structure 231 00:12:58.230 --> 00:13:02.550 or content of the webpage within the client's browser 232 00:13:02.550 --> 00:13:06.051 affecting that client and that client only. 233 00:13:06.051 --> 00:13:10.306 DOM-based cross-site scripting is more challenging to detect 234 00:13:10.306 --> 00:13:14.040 because it resides entirely on the client's side 235 00:13:14.040 --> 00:13:18.270 and doesn't leave traces in server logs or databases. 236 00:13:18.270 --> 00:13:22.424 For instance, a DOM-based cross-site scripting vulnerability 237 00:13:22.424 --> 00:13:26.902 might arise if a JavaScript function reads from the URL 238 00:13:26.902 --> 00:13:30.905 and inserts it directly into the webpage. 239 00:13:30.905 --> 00:13:34.830 In this scenario, an attacker could craft a link 240 00:13:34.830 --> 00:13:38.700 with a script injected into the URL parameters, 241 00:13:38.700 --> 00:13:40.208 causing the victim's browser 242 00:13:40.208 --> 00:13:43.872 to execute the script upon loading the page. 243 00:13:43.872 --> 00:13:47.700 To prevent DOM-based cross-site scripting, 244 00:13:47.700 --> 00:13:49.950 developers should avoid using 245 00:13:49.950 --> 00:13:53.663 potentially dangerous functions like innerHTML 246 00:13:53.663 --> 00:13:58.200 or document.write with user-supplied data. 247 00:13:58.200 --> 00:14:01.770 So, each of these cross-site scripting types 248 00:14:01.770 --> 00:14:03.180 highlight the importance 249 00:14:03.180 --> 00:14:07.500 of thoroughly sanitizing user input, encoding output, 250 00:14:07.500 --> 00:14:10.710 and utilizing content security policies 251 00:14:10.710 --> 00:14:15.710 to limit the execution of untrusted scripts on web pages. 252 00:14:15.990 --> 00:14:19.890 Now for the exam, if you encounter a log snippet 253 00:14:19.890 --> 00:14:24.630 or captured URL with script tags or any kind of JavaScript, 254 00:14:24.630 --> 00:14:28.290 it likely indicates a cross-site scripting attack. 255 00:14:28.290 --> 00:14:32.880 Next, if you see something with documentdot something, 256 00:14:32.880 --> 00:14:36.653 like document.cookie or document.write, 257 00:14:36.653 --> 00:14:40.170 this likely indicates a DOM-based 258 00:14:40.170 --> 00:14:42.810 cross-site scripting attack as it affects 259 00:14:42.810 --> 00:14:45.660 the browser's document object model. 260 00:14:45.660 --> 00:14:48.068 Keeping these tips in mind will help you identify 261 00:14:48.068 --> 00:14:52.680 cross-site scripting attacks accurately on the exam. 262 00:14:52.680 --> 00:14:56.310 Fourth, we have cross-site request forgery. 263 00:14:56.310 --> 00:15:00.510 Cross-site request forgery or CSRF is an attack 264 00:15:00.510 --> 00:15:04.168 that tricks authenticated users into performing actions 265 00:15:04.168 --> 00:15:07.184 they did not intend on a web application 266 00:15:07.184 --> 00:15:09.810 where they've already logged in. 267 00:15:09.810 --> 00:15:12.090 By exploiting the trust a server 268 00:15:12.090 --> 00:15:15.480 has for a client or authenticated user, 269 00:15:15.480 --> 00:15:19.080 CSRF sends unauthorized requests 270 00:15:19.080 --> 00:15:22.470 that appear legitimate on the client's behalf, 271 00:15:22.470 --> 00:15:25.050 effectively using the user's session 272 00:15:25.050 --> 00:15:28.230 to carry out actions without their consent. 273 00:15:28.230 --> 00:15:31.430 For example, in an online banking application, 274 00:15:31.430 --> 00:15:35.990 a CSRF attack could initiate a fund transfer 275 00:15:35.990 --> 00:15:38.545 or perform other critical actions 276 00:15:38.545 --> 00:15:41.040 without the user's knowledge. 277 00:15:41.040 --> 00:15:44.160 Since the request originates from a client 278 00:15:44.160 --> 00:15:45.750 in an active session, 279 00:15:45.750 --> 00:15:49.560 the server has no reason to question the request. 280 00:15:49.560 --> 00:15:54.390 So, it's processed, potentially compromising data integrity, 281 00:15:54.390 --> 00:15:57.382 user privacy, and overall security. 282 00:15:57.382 --> 00:16:00.780 So, effective session management is crucial 283 00:16:00.780 --> 00:16:03.750 for preventing cross-site request forgery 284 00:16:03.750 --> 00:16:07.650 as it allows applications to track user actions 285 00:16:07.650 --> 00:16:09.840 securely across sessions, 286 00:16:09.840 --> 00:16:12.660 often relying on cookies or tokens. 287 00:16:12.660 --> 00:16:16.440 However, predictable or insecure session tokens 288 00:16:16.440 --> 00:16:20.160 can make these attacks easier for attackers to exploit. 289 00:16:20.160 --> 00:16:24.150 This is because if an application generates tokens 290 00:16:24.150 --> 00:16:25.920 in a predictable manner, 291 00:16:25.920 --> 00:16:30.180 attackers can analyze patterns to guess a valid token, 292 00:16:30.180 --> 00:16:34.110 allowing them to forge requests that appear legitimate. 293 00:16:34.110 --> 00:16:36.029 Similarly, if a session token 294 00:16:36.029 --> 00:16:38.730 is transmitted without encryption, 295 00:16:38.730 --> 00:16:41.850 attackers can intercept it over the network 296 00:16:41.850 --> 00:16:46.500 and use it to send requests as an authenticated user. 297 00:16:46.500 --> 00:16:50.730 So, to mitigate cross-site request forgery risks, 298 00:16:50.730 --> 00:16:55.230 applications commonly implement anti-CSRF tokens 299 00:16:55.230 --> 00:16:57.450 that are unique to each session 300 00:16:57.450 --> 00:17:00.000 and validate each request to ensure 301 00:17:00.000 --> 00:17:03.780 it was initiated by the authenticated user. 302 00:17:03.780 --> 00:17:06.810 Additional measures like re-authentication 303 00:17:06.810 --> 00:17:08.280 for critical actions 304 00:17:08.280 --> 00:17:11.640 further limit cross-site request forgery attempts 305 00:17:11.640 --> 00:17:15.420 by requiring confirmation from the genuine user. 306 00:17:15.420 --> 00:17:18.960 Fifth, we have server-side request forgery. 307 00:17:18.960 --> 00:17:22.128 Server-side request forgery or SSRF 308 00:17:22.128 --> 00:17:26.040 exploits a server's ability to make requests 309 00:17:26.040 --> 00:17:28.860 to external or internal resources 310 00:17:28.860 --> 00:17:31.080 on behalf of the application 311 00:17:31.080 --> 00:17:33.780 running on the application server. 312 00:17:33.780 --> 00:17:38.271 In a server-side request forgery or SSRF attack, 313 00:17:38.271 --> 00:17:41.310 attackers trick the application server 314 00:17:41.310 --> 00:17:45.529 into fetching data from unauthorized backend locations, 315 00:17:45.529 --> 00:17:48.436 potentially accessing internal systems 316 00:17:48.436 --> 00:17:51.180 or restricted network segments. 317 00:17:51.180 --> 00:17:53.670 For example, by abusing trust 318 00:17:53.670 --> 00:17:57.600 from a frontend application to a backend resource, 319 00:17:57.600 --> 00:17:59.919 attackers can gather sensitive information 320 00:17:59.919 --> 00:18:03.180 about the internal structure of a network, 321 00:18:03.180 --> 00:18:07.620 which could serve as a foothold for more extensive attacks. 322 00:18:07.620 --> 00:18:12.030 So, the implications of server-side request forgery attacks 323 00:18:12.030 --> 00:18:16.080 can be significant, especially in cloud environments 324 00:18:16.080 --> 00:18:19.160 where services are closely interconnected. 325 00:18:19.160 --> 00:18:21.435 An attacker in a cloud infrastructure 326 00:18:21.435 --> 00:18:24.570 could exploit server-side request forgery 327 00:18:24.570 --> 00:18:27.600 to retrieve metadata from cloud servers, 328 00:18:27.600 --> 00:18:30.110 accessing internal management interfaces, 329 00:18:30.110 --> 00:18:32.730 or even to manipulate a server 330 00:18:32.730 --> 00:18:35.549 into executing unauthorized actions 331 00:18:35.549 --> 00:18:38.550 on sensitive backend systems. 332 00:18:38.550 --> 00:18:40.710 Proper input validation. 333 00:18:40.710 --> 00:18:43.710 Limiting allowable destination addresses 334 00:18:43.710 --> 00:18:47.790 and enforcing strict access control on server requests 335 00:18:47.790 --> 00:18:52.260 are good defenses against server-side request forgery. 336 00:18:52.260 --> 00:18:56.010 Sixth and last, we have a deserialization. 337 00:18:56.010 --> 00:18:58.860 Deserialization attacks take advantage 338 00:18:58.860 --> 00:19:03.150 of the deserialization process where data has been converted 339 00:19:03.150 --> 00:19:07.590 into a structured format for storage or transmission, 340 00:19:07.590 --> 00:19:11.400 and is transformed back from deserialized format 341 00:19:11.400 --> 00:19:15.515 to its original object form within an application. 342 00:19:15.515 --> 00:19:19.382 When an application deserializes untrusted data 343 00:19:19.382 --> 00:19:21.690 without proper validation, 344 00:19:21.690 --> 00:19:24.136 an attacker can inject malicious content 345 00:19:24.136 --> 00:19:27.030 into the serialized data. 346 00:19:27.030 --> 00:19:29.477 During deserialization, the application 347 00:19:29.477 --> 00:19:32.700 may inadvertently execute harmful code 348 00:19:32.700 --> 00:19:34.680 embedded in this data, 349 00:19:34.680 --> 00:19:37.706 allowing the attacker to execute remote code, 350 00:19:37.706 --> 00:19:42.025 escalate privileges, or corrupt application data. 351 00:19:42.025 --> 00:19:45.180 A successful deserialization attack 352 00:19:45.180 --> 00:19:48.181 can severely compromise an application security, 353 00:19:48.181 --> 00:19:52.528 potentially granting attackers access to sensitive data 354 00:19:52.528 --> 00:19:56.695 or control over core application functionalities. 355 00:19:56.695 --> 00:19:58.860 In severe cases, 356 00:19:58.860 --> 00:20:02.670 attackers may use deserialization vulnerabilities 357 00:20:02.670 --> 00:20:06.390 to install persistent threats, open back doors, 358 00:20:06.390 --> 00:20:10.128 or even take control of the application server. 359 00:20:10.128 --> 00:20:12.270 To mitigate this risk, 360 00:20:12.270 --> 00:20:16.830 applications should avoid deserializing untrusted data, 361 00:20:16.830 --> 00:20:21.330 use serialization formats with built-in security controls, 362 00:20:21.330 --> 00:20:23.640 enforce strict input validation, 363 00:20:23.640 --> 00:20:26.790 and implement secure coding practices, 364 00:20:26.790 --> 00:20:29.940 such as restricting the types of objects allowed 365 00:20:29.940 --> 00:20:32.247 during deserialization. 366 00:20:32.247 --> 00:20:34.950 Okay, I know this is a long lesson, 367 00:20:34.950 --> 00:20:37.440 but I would like to take the time to show you 368 00:20:37.440 --> 00:20:40.260 what stored cross-site scripting looks like. 369 00:20:40.260 --> 00:20:42.448 So, let's do a demonstration. 370 00:20:42.448 --> 00:20:44.490 In this demonstration, 371 00:20:44.490 --> 00:20:48.630 I'm going to use a Google cross-site scripting game. 372 00:20:48.630 --> 00:20:51.780 I've already completed the first stage of this game, 373 00:20:51.780 --> 00:20:54.056 so you can see that I'm on Level 2 374 00:20:54.056 --> 00:20:56.700 called Persistence is the Key. 375 00:20:56.700 --> 00:21:00.300 We have a mission description and a mission objective. 376 00:21:00.300 --> 00:21:03.000 My objective in this application 377 00:21:03.000 --> 00:21:06.240 will be to use stored cross-site scripting 378 00:21:06.240 --> 00:21:10.968 to pop up an alert every time someone reloads this page, 379 00:21:10.968 --> 00:21:14.640 simulating every time the page is rendered 380 00:21:14.640 --> 00:21:18.030 by somebody coming to this application. 381 00:21:18.030 --> 00:21:20.400 Right below this, we have the application 382 00:21:20.400 --> 00:21:22.170 that we will be manipulating. 383 00:21:22.170 --> 00:21:24.692 This looks just like a message board 384 00:21:24.692 --> 00:21:27.993 and it has a place for me to share some status. 385 00:21:28.947 --> 00:21:32.047 So, I'm going to go ahead and share some status. 386 00:21:32.047 --> 00:21:35.730 "Hello, this is great!" 387 00:21:35.730 --> 00:21:37.620 Let me go ahead and share it. 388 00:21:37.620 --> 00:21:39.690 And you can see that my comment 389 00:21:39.690 --> 00:21:42.300 now exists on this message board. 390 00:21:42.300 --> 00:21:45.960 If somebody else were to come and visit this message board, 391 00:21:45.960 --> 00:21:48.960 simulated by me refreshing the page, 392 00:21:48.960 --> 00:21:52.729 you can see that my comment still exists here on this page. 393 00:21:52.729 --> 00:21:56.580 So, if there is no input validation, 394 00:21:56.580 --> 00:22:01.580 an attacker could enter code using this same message process 395 00:22:01.590 --> 00:22:06.540 and have it executed every time someone visits this page. 396 00:22:06.540 --> 00:22:11.129 So, we're going to enter in the following code. 397 00:22:11.129 --> 00:22:16.129 This code will attempt to load an image with image source. 398 00:22:16.170 --> 00:22:19.440 Then it expects to get a path 399 00:22:19.440 --> 00:22:22.470 for the file location of that image. 400 00:22:22.470 --> 00:22:25.320 In this case, I'm just writing the word FAKE. 401 00:22:25.320 --> 00:22:28.020 There is no image that I'm trying to load, 402 00:22:28.020 --> 00:22:31.290 so I know there's going to be an error. 403 00:22:31.290 --> 00:22:34.667 When that error occurs, I'm telling it what to do. 404 00:22:34.667 --> 00:22:38.640 I'm telling it to use that JavaScript alert function 405 00:22:38.640 --> 00:22:42.040 to pop up an alert box on my screen. 406 00:22:42.040 --> 00:22:44.310 This is going to demonstrate 407 00:22:44.310 --> 00:22:47.310 stored or persistent cross-site scripting. 408 00:22:47.310 --> 00:22:50.767 Meaning that every time someone visits this page, 409 00:22:50.767 --> 00:22:55.767 this malicious code right here is going to be executed. 410 00:22:55.860 --> 00:22:57.753 So, let's give it a shot. 411 00:22:58.710 --> 00:23:00.930 I've shared the status. There it is right there. 412 00:23:00.930 --> 00:23:05.670 You can see the alert box that popped up on my screen. 413 00:23:05.670 --> 00:23:09.120 And when we look at the message board itself, 414 00:23:09.120 --> 00:23:11.100 it just looks like a broken image. 415 00:23:11.100 --> 00:23:12.090 Of course it does. 416 00:23:12.090 --> 00:23:14.160 I told it to load up an image 417 00:23:14.160 --> 00:23:16.680 and then gave it a fake file path. 418 00:23:16.680 --> 00:23:18.300 Now, let's see what happens 419 00:23:18.300 --> 00:23:21.120 when someone else comes to this message board. 420 00:23:21.120 --> 00:23:25.020 We'll simulate that by clicking the Refresh button. 421 00:23:25.020 --> 00:23:27.794 Sure enough, every time someone visits 422 00:23:27.794 --> 00:23:30.030 and renders this page, 423 00:23:30.030 --> 00:23:32.910 that script executes on the background, 424 00:23:32.910 --> 00:23:36.030 So, that script is stored on the server, 425 00:23:36.030 --> 00:23:40.830 making this stored or persistent cross-site scripting. 426 00:23:40.830 --> 00:23:43.659 This is the end of our demonstration. 427 00:23:43.659 --> 00:23:48.659 So remember, injection vulnerabilities allow attackers 428 00:23:49.230 --> 00:23:52.455 to insert malicious code into an application 429 00:23:52.455 --> 00:23:56.010 through input fields or interfaces, 430 00:23:56.010 --> 00:23:59.730 compromising system integrity and security. 431 00:23:59.730 --> 00:24:02.130 Command injection enables attackers 432 00:24:02.130 --> 00:24:06.690 to execute commands directly on the host operating system 433 00:24:06.690 --> 00:24:09.150 while code injection inserts code 434 00:24:09.150 --> 00:24:11.670 into the application itself, 435 00:24:11.670 --> 00:24:14.670 often hijacking its functionality. 436 00:24:14.670 --> 00:24:18.503 Next, cross-site scripting exploits vulnerable webpages 437 00:24:18.503 --> 00:24:23.130 by embedding scripts that run in user's browsers. 438 00:24:23.130 --> 00:24:26.700 Whereas cross-site request forgery tricks users 439 00:24:26.700 --> 00:24:29.550 into unknowingly performing actions 440 00:24:29.550 --> 00:24:31.560 while logged into a server, 441 00:24:31.560 --> 00:24:35.483 exploiting the trust between the server and the client. 442 00:24:35.483 --> 00:24:39.330 Next, server-side request forgery takes advantage 443 00:24:39.330 --> 00:24:43.621 of a server's ability to make requests to a backend resource 444 00:24:43.621 --> 00:24:47.946 that trusts them, potentially exposing internal systems. 445 00:24:47.946 --> 00:24:51.210 Finally, deserialization attacks and manipulate 446 00:24:51.210 --> 00:24:55.530 the process of reconstructing data from its storage 447 00:24:55.530 --> 00:24:59.580 or transmission format to execute harmful code, 448 00:24:59.580 --> 00:25:03.243 risking remote control and data corruption.