1 00:00:00,090 --> 00:00:01,043 In this lesson, we're going to discuss 2 00:00:01,043 --> 00:00:04,350 SQL and XML injection attacks. 3 00:00:04,350 --> 00:00:05,820 Now, an injection attack occurs 4 00:00:05,820 --> 00:00:08,189 when an attacker sends malicious data to a system, 5 00:00:08,189 --> 00:00:10,920 which is then processed as part of a command or query, 6 00:00:10,920 --> 00:00:13,290 which can lead to unintended consequences. 7 00:00:13,290 --> 00:00:14,910 Now, regardless of whether the attacker is trying 8 00:00:14,910 --> 00:00:17,850 to conduct an SQL injection or an XML injection, 9 00:00:17,850 --> 00:00:20,280 the concept and the goal of the attack is similar, 10 00:00:20,280 --> 00:00:22,380 to send some kind of code into our systems 11 00:00:22,380 --> 00:00:23,910 so that, that attacker can perform 12 00:00:23,910 --> 00:00:25,860 some kind of malicious action. 13 00:00:25,860 --> 00:00:28,890 So let's go ahead and cover an SQL injection first, 14 00:00:28,890 --> 00:00:31,260 and we'll talk a little bit about the background of SQL 15 00:00:31,260 --> 00:00:33,000 so you can understand how it works. 16 00:00:33,000 --> 00:00:34,680 Now, when you're dealing with a database, 17 00:00:34,680 --> 00:00:36,690 you have to have a way to talk to that database 18 00:00:36,690 --> 00:00:40,200 in order to read, write, or search for data inside of it. 19 00:00:40,200 --> 00:00:42,900 Now, this is done by using statements in a language known 20 00:00:42,900 --> 00:00:45,840 as the Structured Query Language, or SQL. 21 00:00:45,840 --> 00:00:48,270 Now, there are four main actions inside of SQL 22 00:00:48,270 --> 00:00:49,380 that you can use to manipulate 23 00:00:49,380 --> 00:00:51,630 the data held inside of a database. 24 00:00:51,630 --> 00:00:55,110 These are select, insert, delete, and update. 25 00:00:55,110 --> 00:00:57,240 Now, to select something means that we want to read 26 00:00:57,240 --> 00:00:58,890 that data from the database. 27 00:00:58,890 --> 00:01:00,030 To insert something means 28 00:01:00,030 --> 00:01:02,160 that we want to write data into the database. 29 00:01:02,160 --> 00:01:03,810 To delete something means we want to remove 30 00:01:03,810 --> 00:01:05,190 that data from the database 31 00:01:05,190 --> 00:01:07,590 And to update something means I want to overwrite that data 32 00:01:07,590 --> 00:01:09,840 in the database with a newer version. 33 00:01:09,840 --> 00:01:11,531 Now let's take a quick look at how SQL works 34 00:01:11,531 --> 00:01:13,440 in the real world. 35 00:01:13,440 --> 00:01:15,930 When you try to log into a website, you may encounter 36 00:01:15,930 --> 00:01:19,350 a basic login form asking for your username and password. 37 00:01:19,350 --> 00:01:21,480 Let's pretend I enter Jason as my username 38 00:01:21,480 --> 00:01:25,440 and Pass123 as my password, and then I click login. 39 00:01:25,440 --> 00:01:27,822 Next, the website is going to send my username and password 40 00:01:27,822 --> 00:01:30,660 over to the database and make a query to determine 41 00:01:30,660 --> 00:01:33,330 if my username and password match what is being stored 42 00:01:33,330 --> 00:01:34,770 inside of the database. 43 00:01:34,770 --> 00:01:37,590 To do this, it's going to use an SQL statement. 44 00:01:37,590 --> 00:01:39,420 For example, I might have the statement 45 00:01:39,420 --> 00:01:44,130 of Select * from Users where user_id = 'Jason' 46 00:01:44,130 --> 00:01:47,130 and password = 'Pass123'. 47 00:01:47,130 --> 00:01:49,350 Now, this information goes into the database, 48 00:01:49,350 --> 00:01:51,810 and then will determine if there is a perfect match. 49 00:01:51,810 --> 00:01:54,300 If there is a match, we're going to have access granted, 50 00:01:54,300 --> 00:01:56,100 and everything is going to be wonderful. 51 00:01:56,100 --> 00:01:58,861 That is a very basic and major oversimplification 52 00:01:58,861 --> 00:02:02,280 of how SQL works, but at least it gives you a good idea. 53 00:02:02,280 --> 00:02:03,720 Now, if you're a database engineer, 54 00:02:03,720 --> 00:02:06,660 I know I really made that much simpler than it really is, 55 00:02:06,660 --> 00:02:08,009 but this is the baseline knowledge 56 00:02:08,009 --> 00:02:10,229 that everybody watching this video needs to have 57 00:02:10,229 --> 00:02:11,340 before we can move forward 58 00:02:11,340 --> 00:02:13,200 and talk about an SQL injection. 59 00:02:13,200 --> 00:02:14,790 So please don't send me a bunch of hate mail 60 00:02:14,790 --> 00:02:16,260 over my oversimplification. 61 00:02:16,260 --> 00:02:17,250 I'm just trying to make it easier 62 00:02:17,250 --> 00:02:18,750 for everyone to understand. 63 00:02:18,750 --> 00:02:19,770 All right, now let's go ahead 64 00:02:19,770 --> 00:02:21,750 and move into the code injection portion. 65 00:02:21,750 --> 00:02:23,370 Now, a code injection is the insertion 66 00:02:23,370 --> 00:02:25,230 of additional information or code 67 00:02:25,230 --> 00:02:28,770 through a data input form from a client to an application. 68 00:02:28,770 --> 00:02:30,630 Code injection is a generic form, 69 00:02:30,630 --> 00:02:33,240 but what we're going to be focused on specifically right now is 70 00:02:33,240 --> 00:02:34,650 an SQL injection, 71 00:02:34,650 --> 00:02:37,110 which is a specific type of code injection. 72 00:02:37,110 --> 00:02:39,060 This is how a lot of attackers are going to insert 73 00:02:39,060 --> 00:02:41,580 malicious SQL statements into our applications 74 00:02:41,580 --> 00:02:44,760 and cause havoc for us, so it's important to understand. 75 00:02:44,760 --> 00:02:47,040 Now, an SQL injection attack is going to consist 76 00:02:47,040 --> 00:02:50,040 of an injection of an SQL query through the input form 77 00:02:50,040 --> 00:02:51,750 that a client is going to use to send data 78 00:02:51,750 --> 00:02:53,550 over to a web application. 79 00:02:53,550 --> 00:02:56,640 When conducting an SQL injection, the attacker is going to try 80 00:02:56,640 --> 00:02:59,670 to insert parameters or code into the SQL statement 81 00:02:59,670 --> 00:03:01,980 that's going to be used to query that database. 82 00:03:01,980 --> 00:03:04,140 To do this, the attacker can either inject their input 83 00:03:04,140 --> 00:03:07,290 as a URL parameter by entering the data into a form field, 84 00:03:07,290 --> 00:03:09,750 by modifying cookies, by changing post data, 85 00:03:09,750 --> 00:03:11,610 or by using an HTTP header 86 00:03:11,610 --> 00:03:13,980 to find an SQL injection vulnerability. 87 00:03:13,980 --> 00:03:15,540 Now, while this sounds like a lot of work, 88 00:03:15,540 --> 00:03:17,670 it's actually pretty easy to automate this process 89 00:03:17,670 --> 00:03:19,890 as an attacker, because there's a lot of great tools 90 00:03:19,890 --> 00:03:23,130 out there that focus on SQL injections and exploits. 91 00:03:23,130 --> 00:03:25,500 So as a defender, it's going to be our job 92 00:03:25,500 --> 00:03:28,410 to protect our databases from these SQL injections, 93 00:03:28,410 --> 00:03:30,000 and to do that, we have to understand 94 00:03:30,000 --> 00:03:32,910 how these SQL injections are actually going to work. 95 00:03:32,910 --> 00:03:35,460 Now let's go back to our example of logging into a website, 96 00:03:35,460 --> 00:03:38,460 and see how the SQL injection could exploit our site. 97 00:03:38,460 --> 00:03:41,070 First, we have the login form that's used by the clients 98 00:03:41,070 --> 00:03:43,110 to enter their username and password. 99 00:03:43,110 --> 00:03:45,750 As an attacker, I'm going to put that in as my username 100 00:03:45,750 --> 00:03:48,750 that I want to log in as, and in this case, that's Jason. 101 00:03:48,750 --> 00:03:51,960 Then I'm going to insert the password, but as an attacker, 102 00:03:51,960 --> 00:03:53,880 they don't know what Jason's password is. 103 00:03:53,880 --> 00:03:56,940 Now, you all do, because I already told you it was Pass123, 104 00:03:56,940 --> 00:03:59,101 but as the attacker, what I'm going to do is I'm going to add 105 00:03:59,101 --> 00:04:02,883 an apostrophe and type 'OR 1 = 1; 106 00:04:03,840 --> 00:04:05,520 Now, that looks pretty weird, right? 107 00:04:05,520 --> 00:04:07,920 Well, it does, but the reason that I'm doing this is 108 00:04:07,920 --> 00:04:10,530 because when I put that in and I click the login button, 109 00:04:10,530 --> 00:04:13,110 that data from the form is going to be inserted back 110 00:04:13,110 --> 00:04:15,210 into the SQL statement on the backend 111 00:04:15,210 --> 00:04:17,190 and then query to the database. 112 00:04:17,190 --> 00:04:19,380 Now, what we have just done is we are going to use 113 00:04:19,380 --> 00:04:21,839 that command Select * from Users 114 00:04:21,839 --> 00:04:25,260 where user_id equals the user we entered, which was 'Jason' 115 00:04:25,260 --> 00:04:27,720 and password equals, and then what we entered 116 00:04:27,720 --> 00:04:31,533 for our password, which in this case, was 'OR1 = 1; 117 00:04:33,390 --> 00:04:35,340 Now, notice when I sent that to the system, 118 00:04:35,340 --> 00:04:37,920 what I'm seeing there is that access is granted. 119 00:04:37,920 --> 00:04:39,000 Now, why is that? 120 00:04:39,000 --> 00:04:40,740 It's not because I got the right password. 121 00:04:40,740 --> 00:04:44,280 The reason is because I just performed an SQL injection. 122 00:04:44,280 --> 00:04:46,050 What ends up happening when you have something 123 00:04:46,050 --> 00:04:48,000 like this apostrophe is that it serves 124 00:04:48,000 --> 00:04:49,350 as an escape character. 125 00:04:49,350 --> 00:04:52,290 So what I really was injecting into the SQL statement was 126 00:04:52,290 --> 00:04:54,720 for the system to evaluate whether what I entered 127 00:04:54,720 --> 00:04:57,600 as the password was a match for the password for Jason, 128 00:04:57,600 --> 00:04:59,610 or does one equal one? 129 00:04:59,610 --> 00:05:01,470 Now let me ask you a quick question here. 130 00:05:01,470 --> 00:05:02,820 Does one equal one? 131 00:05:02,820 --> 00:05:04,290 Well yes, one equals one. 132 00:05:04,290 --> 00:05:06,330 Every single day, one is going to equal one. 133 00:05:06,330 --> 00:05:09,030 It's a true statement, so anytime we run this command, 134 00:05:09,030 --> 00:05:10,470 we're going to get a true statement, 135 00:05:10,470 --> 00:05:12,270 because we're checking if password 136 00:05:12,270 --> 00:05:14,760 or one equals one is true, and in this case, 137 00:05:14,760 --> 00:05:16,980 one equals one is always going to be true, 138 00:05:16,980 --> 00:05:19,230 so based on simple Boolean logic, 139 00:05:19,230 --> 00:05:21,690 even if the password was wrong because I put it blank 140 00:05:21,690 --> 00:05:24,630 in this case, I'm still going to be able to get into the system 141 00:05:24,630 --> 00:05:27,840 because I have one equals one as a true condition, 142 00:05:27,840 --> 00:05:29,700 and anytime you're using Boolean logic, if one 143 00:05:29,700 --> 00:05:32,280 of the conditions is true, the entire statement is true 144 00:05:32,280 --> 00:05:34,050 when you're using an OR statement. 145 00:05:34,050 --> 00:05:36,120 This is why I'm going to get an access granted. 146 00:05:36,120 --> 00:05:38,370 I'm going to be able to log into the system as Jason, 147 00:05:38,370 --> 00:05:40,260 even though I didn't have his password. 148 00:05:40,260 --> 00:05:41,940 This is why SQL injections work 149 00:05:41,940 --> 00:05:43,710 when people are trying to break into a database, 150 00:05:43,710 --> 00:05:46,500 because they are forcing a true condition to occur. 151 00:05:46,500 --> 00:05:48,390 Now, this is why preventing an SQL injection 152 00:05:48,390 --> 00:05:50,640 from being able to occur is really important, 153 00:05:50,640 --> 00:05:52,860 and the best way to prevent an SQL injection is 154 00:05:52,860 --> 00:05:54,930 to use something known as input validation, 155 00:05:54,930 --> 00:05:57,900 and to sanitize any data you receive from your users. 156 00:05:57,900 --> 00:06:00,060 Now, for the exam, anytime you see something 157 00:06:00,060 --> 00:06:02,880 with an apostrophe and something that equals something, 158 00:06:02,880 --> 00:06:04,290 I want you to automatically think 159 00:06:04,290 --> 00:06:06,720 this is probably an SQL injection attempt. 160 00:06:06,720 --> 00:06:09,090 Almost every single time, that's going to be the right answer. 161 00:06:09,090 --> 00:06:11,430 Now, be aware anytime you see in the log, 162 00:06:11,430 --> 00:06:13,410 something that is something equals something, 163 00:06:13,410 --> 00:06:14,970 it doesn't always have to be one equals one. 164 00:06:14,970 --> 00:06:18,660 It can be seven equals seven, or 15 equals 15, or whatever. 165 00:06:18,660 --> 00:06:21,270 As long as that statement will always evaluate to true, 166 00:06:21,270 --> 00:06:23,340 it is a form of SQL injection. 167 00:06:23,340 --> 00:06:25,590 I guarantee on the exam you're going to get at least one 168 00:06:25,590 --> 00:06:27,810 or two questions about SQL injections, 169 00:06:27,810 --> 00:06:29,940 and they'll either be focused on you being able to identify 170 00:06:29,940 --> 00:06:33,000 that it was an SQL injection by seeing that one equals one 171 00:06:33,000 --> 00:06:34,560 or something similar like that, 172 00:06:34,560 --> 00:06:36,902 or they're going to ask you how to prevent an SQL injection, 173 00:06:36,902 --> 00:06:39,090 and if you're asked to prevent an SQL injection, 174 00:06:39,090 --> 00:06:40,380 what is the right answer? 175 00:06:40,380 --> 00:06:42,900 It is input validation, so remember that. 176 00:06:42,900 --> 00:06:45,090 If you can validate or sanitize the input, 177 00:06:45,090 --> 00:06:47,010 you're going to be able to prevent an SQL injection 178 00:06:47,010 --> 00:06:49,339 from occurring because you can filter out those apostrophes 179 00:06:49,339 --> 00:06:51,060 or something equals something, 180 00:06:51,060 --> 00:06:53,010 and not send that to the database. 181 00:06:53,010 --> 00:06:55,320 Now, another great way to prevent an SQL injection is 182 00:06:55,320 --> 00:06:57,570 to simply use a web application firewall, 183 00:06:57,570 --> 00:07:00,240 and placing it between the client and the web server, 184 00:07:00,240 --> 00:07:02,760 because the web application firewall will be able to perform 185 00:07:02,760 --> 00:07:05,251 that input sanitization and input validation for you 186 00:07:05,251 --> 00:07:08,880 even if you can't rewrite the application's code itself. 187 00:07:08,880 --> 00:07:10,620 Now, on the exam, if you have a question 188 00:07:10,620 --> 00:07:11,850 that's asking about attacks 189 00:07:11,850 --> 00:07:13,770 against a database, almost always, 190 00:07:13,770 --> 00:07:16,500 the answer is going to be an SQL injection, why? 191 00:07:16,500 --> 00:07:19,050 Because databases use SQL as the way to read 192 00:07:19,050 --> 00:07:20,730 and write information from a database. 193 00:07:20,730 --> 00:07:23,010 So again, keep these tricks in mind for exam day, 194 00:07:23,010 --> 00:07:24,960 and I'm sure they're going to come in handy for you. 195 00:07:24,960 --> 00:07:27,180 All right, now that we've covered SQL injections, 196 00:07:27,180 --> 00:07:30,240 let's move into our coverage of XML injections next. 197 00:07:30,240 --> 00:07:32,880 Now, XML stands for the Extensible Markup Language, 198 00:07:32,880 --> 00:07:34,290 and it's used by web applications 199 00:07:34,290 --> 00:07:36,180 for authentication, authorization, 200 00:07:36,180 --> 00:07:38,190 or other types of data exchange. 201 00:07:38,190 --> 00:07:40,860 XML data is submitted from the client to the server, 202 00:07:40,860 --> 00:07:42,780 or from one server to another. 203 00:07:42,780 --> 00:07:45,600 To protect XML data in transit, it should always be sent 204 00:07:45,600 --> 00:07:47,220 inside of an encrypted tunnel 205 00:07:47,220 --> 00:07:49,590 such as by using a TLS tunnel. 206 00:07:49,590 --> 00:07:52,080 To protect your server when it receives XML data, 207 00:07:52,080 --> 00:07:53,970 you should always conduct input validation 208 00:07:53,970 --> 00:07:57,330 and input sanitization of the data before you process it. 209 00:07:57,330 --> 00:07:58,890 This will protect the server from any kind 210 00:07:58,890 --> 00:08:01,050 of XML exploitation or injection attack 211 00:08:01,050 --> 00:08:03,060 that the attacker is trying to perform. 212 00:08:03,060 --> 00:08:05,310 If you submit XML data without encryption 213 00:08:05,310 --> 00:08:07,770 or without input validation, it's going to be vulnerable 214 00:08:07,770 --> 00:08:10,320 to snooping, spoofing, request forgery, 215 00:08:10,320 --> 00:08:13,080 and injection of arbitrary code, so you want to make sure 216 00:08:13,080 --> 00:08:15,420 you're doing encryption and input validation 217 00:08:15,420 --> 00:08:18,090 anytime you're sending data in XML format. 218 00:08:18,090 --> 00:08:19,770 Now, when you look at XML data, 219 00:08:19,770 --> 00:08:22,110 it's going to appear to be in a human readable format 220 00:08:22,110 --> 00:08:24,060 as a series of tagged fields. 221 00:08:24,060 --> 00:08:25,500 Now, here's a short XML file 222 00:08:25,500 --> 00:08:28,050 that I created containing a practice exam question. 223 00:08:28,050 --> 00:08:31,230 The first line defines the text file as an XML file, 224 00:08:31,230 --> 00:08:32,667 and defines what version of XML 225 00:08:32,667 --> 00:08:35,039 and the type of encoding I want to use. 226 00:08:35,039 --> 00:08:36,600 The second line is going to define 227 00:08:36,600 --> 00:08:39,179 the type of data I'm using in this XML file. 228 00:08:39,179 --> 00:08:41,669 In this case, I'm defining the information contained 229 00:08:41,669 --> 00:08:43,919 as a question for a web application quiz program 230 00:08:43,919 --> 00:08:45,090 that I'm writing. 231 00:08:45,090 --> 00:08:47,160 Next, you're going to see there are four more fields 232 00:08:47,160 --> 00:08:48,690 inside this question type. 233 00:08:48,690 --> 00:08:50,580 The first field is the ID field, 234 00:08:50,580 --> 00:08:52,530 and you'll see here it contains a unique identifier 235 00:08:52,530 --> 00:08:56,103 for this sample question with a label of SECURITY-002-0001. 236 00:08:58,740 --> 00:09:00,360 Next, I have a title field, 237 00:09:00,360 --> 00:09:04,440 and I titled this question as is this an XML vulnerability? 238 00:09:04,440 --> 00:09:07,590 Next, I have choice one and choice two as fields. 239 00:09:07,590 --> 00:09:09,810 Now, the great thing about XML is that it can be configured 240 00:09:09,810 --> 00:09:11,160 with whatever fields you want, 241 00:09:11,160 --> 00:09:13,860 based on your specific application that you're building. 242 00:09:13,860 --> 00:09:16,680 In my case, I'm showing you how I would define my questions 243 00:09:16,680 --> 00:09:18,300 for this quiz application. 244 00:09:18,300 --> 00:09:20,730 Finally, you'll see we have the slash question 245 00:09:20,730 --> 00:09:23,670 and the slash XML tags to close out this data, 246 00:09:23,670 --> 00:09:26,940 just like closing out an HTML tag in a website's code. 247 00:09:26,940 --> 00:09:29,040 Now, if you see something like this on test day, 248 00:09:29,040 --> 00:09:31,650 you should be able to identify it as XML data. 249 00:09:31,650 --> 00:09:33,630 In this example, there is nothing malicious, 250 00:09:33,630 --> 00:09:36,000 it's just regular XML data that's being used 251 00:09:36,000 --> 00:09:37,110 to contain information 252 00:09:37,110 --> 00:09:39,480 and send it to or from a given application. 253 00:09:39,480 --> 00:09:42,360 In this case, it's a quiz application that I'm building. 254 00:09:42,360 --> 00:09:44,430 Now, there are some exploits that you're going to come across 255 00:09:44,430 --> 00:09:47,430 with XML, and so let's talk about a couple of those. 256 00:09:47,430 --> 00:09:49,650 First, we have an XML bomb. 257 00:09:49,650 --> 00:09:53,100 Now, an XML bomb is also known as a billion laughs attack. 258 00:09:53,100 --> 00:09:55,416 Now, an XML bomb takes an XML file 259 00:09:55,416 --> 00:09:57,870 and then uses encoding to encode entities 260 00:09:57,870 --> 00:10:00,180 and expand them into exponential sizes, 261 00:10:00,180 --> 00:10:01,710 which will consume memory on the host, 262 00:10:01,710 --> 00:10:03,300 and potentially crash it. 263 00:10:03,300 --> 00:10:05,223 The reason this is called a billion laughs attack is 264 00:10:05,223 --> 00:10:08,310 that the XML entities referenced in this file are written 265 00:10:08,310 --> 00:10:10,950 as lol one through lol nine. 266 00:10:10,950 --> 00:10:12,930 Each of these references the line before it, 267 00:10:12,930 --> 00:10:15,630 so starting at the bottom with lol nine, 268 00:10:15,630 --> 00:10:17,970 you can see we have 10 lol eights, 269 00:10:17,970 --> 00:10:21,210 and in lol eight, there are 10 lol sevens, 270 00:10:21,210 --> 00:10:22,980 and this pattern continues all the way up, 271 00:10:22,980 --> 00:10:25,740 and essentially it creates a billion lols 272 00:10:25,740 --> 00:10:27,090 because of this factorial nature 273 00:10:27,090 --> 00:10:29,400 of the entity references that's being used. 274 00:10:29,400 --> 00:10:31,290 Now, this simple code can actually consume 275 00:10:31,290 --> 00:10:32,969 up to three gigabytes of memory 276 00:10:32,969 --> 00:10:34,620 due to the repetitive references 277 00:10:34,620 --> 00:10:36,900 that are being made inside this XML file. 278 00:10:36,900 --> 00:10:39,150 So if an attacker is able to get to your server 279 00:10:39,150 --> 00:10:41,220 and have it process this XML file, 280 00:10:41,220 --> 00:10:42,360 it can then start consuming 281 00:10:42,360 --> 00:10:44,370 all of these resources on your web server, 282 00:10:44,370 --> 00:10:46,500 and this is why we call it an XML bomb, 283 00:10:46,500 --> 00:10:49,139 because it acts like a bomb or denial of service attack. 284 00:10:49,139 --> 00:10:51,300 Now, the second type we have is what's known 285 00:10:51,300 --> 00:10:54,960 as an XML external entity, or XXE attack. 286 00:10:54,960 --> 00:10:56,788 This type of attack attempts to embed a request 287 00:10:56,788 --> 00:10:58,650 for a local resource. 288 00:10:58,650 --> 00:10:59,550 Now, this sounds a lot 289 00:10:59,550 --> 00:11:01,500 like a local file inclusion, doesn't it? 290 00:11:01,500 --> 00:11:04,470 And here's an example of an XML external entity attack. 291 00:11:04,470 --> 00:11:06,810 Again notice we have the XML version 292 00:11:06,810 --> 00:11:08,610 and the encoding in the first line. 293 00:11:08,610 --> 00:11:11,280 Next, we have a document type listed as foo, 294 00:11:11,280 --> 00:11:12,540 which is just code or speak 295 00:11:12,540 --> 00:11:14,490 for some kind of a junk variable. 296 00:11:14,490 --> 00:11:16,620 Then we have an element foo ANY, 297 00:11:16,620 --> 00:11:18,750 and we have the entity xxe SYSTEM, 298 00:11:18,750 --> 00:11:23,250 and then the file, "file:///etc/shadow," 299 00:11:23,250 --> 00:11:25,380 and then we end this out with some kind of data 300 00:11:25,380 --> 00:11:26,760 inside of XML format. 301 00:11:26,760 --> 00:11:29,220 In this case, we're calling that foo as well. 302 00:11:29,220 --> 00:11:31,530 Now, most of this doesn't look too bad or malicious, 303 00:11:31,530 --> 00:11:33,180 but that fourth line that contains 304 00:11:33,180 --> 00:11:35,760 the /etc/shadow file is, 305 00:11:35,760 --> 00:11:38,730 because this XML entity is trying to read the shadow file 306 00:11:38,730 --> 00:11:41,250 of a Linux machine, which contains the password hashes 307 00:11:41,250 --> 00:11:42,960 for that system's accounts. 308 00:11:42,960 --> 00:11:45,450 Now, to prevent XML vulnerabilities from being exploited, 309 00:11:45,450 --> 00:11:48,450 remember, you need to use proper input validation. 310 00:11:48,450 --> 00:11:51,540 Input validation, input validation, input validation, 311 00:11:51,540 --> 00:11:53,760 I keep mentioning it for our different web applications 312 00:11:53,760 --> 00:11:56,430 and exploits because it really is that important. 313 00:11:56,430 --> 00:11:58,290 Anytime you're getting input from a user, 314 00:11:58,290 --> 00:12:01,350 whether it's a URL being inputted, a file being inputted, 315 00:12:01,350 --> 00:12:02,940 a field being entered on a website, 316 00:12:02,940 --> 00:12:05,100 or some kind of XML data being sent over, 317 00:12:05,100 --> 00:12:06,960 we can prevent a lot of security issues 318 00:12:06,960 --> 00:12:09,270 if we just use input validation. 319 00:12:09,270 --> 00:12:10,980 Now, for the exam, if you see something 320 00:12:10,980 --> 00:12:14,910 with XML written in it and it is clearly XML, guess what? 321 00:12:14,910 --> 00:12:17,190 That's most likely going to be an XML vulnerability 322 00:12:17,190 --> 00:12:18,450 that's being exploited. 323 00:12:18,450 --> 00:12:20,370 They might call this an XML vulnerability, 324 00:12:20,370 --> 00:12:23,130 an XML exploitation, or an XML injection. 325 00:12:23,130 --> 00:12:25,230 Whatever term they use, it really doesn't matter. 326 00:12:25,230 --> 00:12:27,630 It really is just XML being exploited 327 00:12:27,630 --> 00:12:31,200 when you see XML format data in a question on the exam. 328 00:12:31,200 --> 00:12:33,603 Now, the only real tricky part with an XML code is 329 00:12:33,603 --> 00:12:36,960 that it often can look like HTML code or JavaScript. 330 00:12:36,960 --> 00:12:39,120 To tell the difference, remember that HTML 331 00:12:39,120 --> 00:12:41,460 or JavaScript uses defined keywords 332 00:12:41,460 --> 00:12:43,350 for each of those bracketed entries, 333 00:12:43,350 --> 00:12:45,990 but with XML, you can make those say whatever you want, 334 00:12:45,990 --> 00:12:48,570 depending on how you configure your XML file. 335 00:12:48,570 --> 00:12:50,550 So on the exam, I want you to take a moment 336 00:12:50,550 --> 00:12:52,890 anytime you see a piece of code, and look at it, 337 00:12:52,890 --> 00:12:54,660 and then determine is it HTML, 338 00:12:54,660 --> 00:12:56,850 is it JavaScript, or is it XML? 339 00:12:56,850 --> 00:12:58,920 If you see something like a font or an image 340 00:12:58,920 --> 00:13:01,650 or an href in the tag, that is going to be HTML. 341 00:13:01,650 --> 00:13:04,800 If you see something like question or ID or type or element 342 00:13:04,800 --> 00:13:07,050 or entity, that's going to be XML. 343 00:13:07,050 --> 00:13:08,910 If you can make this kind of determination, 344 00:13:08,910 --> 00:13:10,620 you're going to have no issues answering questions 345 00:13:10,620 --> 00:13:12,090 that involve XML vulnerabilities, 346 00:13:12,090 --> 00:13:14,970 exploitations, or injections on the exam. 347 00:13:14,970 --> 00:13:17,550 So remember, an injection occurs when an attacker sends 348 00:13:17,550 --> 00:13:19,140 malicious data to a system, 349 00:13:19,140 --> 00:13:20,670 and it's then going to be processed as part 350 00:13:20,670 --> 00:13:22,290 of a commander query that can lead 351 00:13:22,290 --> 00:13:24,030 to unintended consequences. 352 00:13:24,030 --> 00:13:26,250 An SQL injection is an attack technique 353 00:13:26,250 --> 00:13:29,280 where malicious SQL code is inserted into input fields 354 00:13:29,280 --> 00:13:32,490 to manipulate or exploit a database-driven application. 355 00:13:32,490 --> 00:13:35,220 If you see something like apostrophe one equals one, 356 00:13:35,220 --> 00:13:37,560 this is going to be an SQL injection. 357 00:13:37,560 --> 00:13:40,320 XML injections, on the other hand, is an attack technique 358 00:13:40,320 --> 00:13:42,570 where malicious XML code is going to be inserted 359 00:13:42,570 --> 00:13:44,490 into input fields to manipulate 360 00:13:44,490 --> 00:13:47,310 or exploit an XML driven application or service. 361 00:13:47,310 --> 00:13:48,570 If you see any code that appears 362 00:13:48,570 --> 00:13:51,510 to be written in XML format in a log snippet on the exam, 363 00:13:51,510 --> 00:13:54,390 you can take a safe guess that this is an XML injection 364 00:13:54,390 --> 00:13:56,290 that's being attempted by an attacker.