WEBVTT 0:00:03.200000 --> 0:00:06.020000 Hello everyone and welcome to this video. 0:00:06.020000 --> 0:00:09.520000 In this video, we're going to be taking a look at the various types of 0:00:09.520000 --> 0:00:12.080000 web service implementations. 0:00:12.080000 --> 0:00:15.020000 So again, you might be a little bit confused as to what this means. 0:00:15.020000 --> 0:00:19.080000 Don't worry. What I'm essentially going to be going over is the different 0:00:19.080000 --> 0:00:24.900000 types of protocols or frameworks that are used, you know, for the implementation 0:00:24.900000 --> 0:00:28.520000 of web services or in the implementation of web services. 0:00:28.520000 --> 0:00:32.460000 So when I mentioned soap in the previous set of videos, that's an example 0:00:32.460000 --> 0:00:34.500000 of an implementation. 0:00:34.500000 --> 0:00:37.580000 And again, the reason why I'm calling them implementations as opposed 0:00:37.580000 --> 0:00:42.820000 to protocols is because, you know, firstly, the many of these that I'll 0:00:42.820000 --> 0:00:48.280000 be covering in this video are sort of might be seen as a little bit outdated 0:00:48.280000 --> 0:00:51.340000 and might have nuanced functionality. 0:00:51.340000 --> 0:00:54.680000 But they can still be utilized, you know, in the implementation of web 0:00:54.680000 --> 0:00:58.540000 services. So I'm not going to be very specific and call them protocols. 0:00:58.540000 --> 0:01:04.660000 They're usually seen as implementations or ways of implementing web services. 0:01:04.660000 --> 0:01:09.960000 So to kick things off, we need to understand what this means and formally, 0:01:09.960000 --> 0:01:13.800000 I mean now so web service implementations refer to the different ways 0:01:13.800000 --> 0:01:23.680000 in which web services can be created, deployed and we're really interested 0:01:23.680000 --> 0:01:28.380000 in the final word there or the final two words, which is and used. 0:01:28.380000 --> 0:01:31.220000 So that's something to keep in mind. 0:01:31.220000 --> 0:01:35.460000 Now, there are several methods and technologies available for implementing 0:01:35.460000 --> 0:01:40.220000 web services. And we'll be exploring them in the next set of slides. 0:01:40.220000 --> 0:01:43.500000 So I'm only covering a couple of them here. 0:01:43.500000 --> 0:01:47.520000 And again, the reason for that is I do not want to bombard you with a 0:01:47.520000 --> 0:01:52.720000 lot of these at the moment, because truth truth be told, when I started 0:01:52.720000 --> 0:01:57.500000 out, you know, performing even the most basic types of web service pen 0:01:57.500000 --> 0:02:00.820000 testing, I was essentially doing it with soap. 0:02:00.820000 --> 0:02:04.980000 Okay, and that's why this course is focused on soap, because in my opinion, 0:02:04.980000 --> 0:02:06.980000 it's the best starting point. 0:02:06.980000 --> 0:02:10.720000 If you can get this right, testing APIs will be a breeze. 0:02:10.720000 --> 0:02:12.500000 I can almost guarantee that. 0:02:12.500000 --> 0:02:14.100000 So what is soap? 0:02:14.100000 --> 0:02:17.960000 Soap stands for the simple object access protocol. 0:02:17.960000 --> 0:02:24.680000 Soap is a validation of web services. 0:02:24.680000 --> 0:02:29.580000 Soap based web services utilize XML as their message format. 0:02:29.580000 --> 0:02:31.320000 So this is very important. 0:02:31.320000 --> 0:02:36.860000 So whenever you see XML being included, in the case of soap, what this 0:02:36.860000 --> 0:02:42.340000 means is that if you intercepted a request facilitated through HTTP to 0:02:42.340000 --> 0:02:47.340000 a soap web service or a soap web service endpoint, you would see, you 0:02:47.340000 --> 0:02:51.600000 know, it's standard, it follows the standard, the standard definition 0:02:51.600000 --> 0:02:55.040000 in terms of HTTP requests and responses. 0:02:55.040000 --> 0:03:00.860000 So the point is you'll see all of the required or pertinent request headers. 0:03:00.860000 --> 0:03:05.020000 But in the body, you will now see XML. 0:03:05.020000 --> 0:03:09.320000 And that's where they, you know, that's where you have the specification, 0:03:09.320000 --> 0:03:12.340000 or that's in the actual protocol now. 0:03:12.340000 --> 0:03:17.140000 And that's where you specify, you what you want to do. 0:03:17.140000 --> 0:03:20.880000 But in this case, because when we'll be taking a look at soap closely, 0:03:20.880000 --> 0:03:25.640000 we'll be pretty much trying to utilize soap to understand how a particular 0:03:25.640000 --> 0:03:31.020000 web application works, or how, you know, what data it can access, etc. 0:03:31.020000 --> 0:03:33.620000 The key thing is that it utilizes XML. 0:03:33.620000 --> 0:03:35.800000 So I just want to make you aware of that. 0:03:35.800000 --> 0:03:36.680000 I'll be exploring this. 0:03:36.680000 --> 0:03:39.480000 I don't want to dive into it here because the other slides that cover 0:03:39.480000 --> 0:03:45.200000 it, but just understand that XML soap, XML soap, that's a very important 0:03:45.200000 --> 0:03:48.120000 thing that I had to understand. 0:03:48.120000 --> 0:03:55.560000 You then have JSON RPC, you then have XML RPC, JSON RPC, and XML RPC are 0:03:55.560000 --> 0:03:59.960000 lightweight protocols for remote procedure calls or RPC, you know, RPC 0:03:59.960000 --> 0:04:03.380000 calls that utilize JSON or XML. 0:04:03.380000 --> 0:04:08.540000 You typically do not see JSON RPC or XML RPC being used anymore. 0:04:08.540000 --> 0:04:13.960000 That's why even WordPress has phased out the utilization of XML RPC, because 0:04:13.960000 --> 0:04:19.520000 in during those days, it was a web service implementation. 0:04:19.520000 --> 0:04:23.580000 They were not trying to create an API in terms of the definition I gave 0:04:23.580000 --> 0:04:24.960000 you in the previous video. 0:04:24.960000 --> 0:04:29.320000 They were really exposing it so that two computers could communicate with 0:04:29.320000 --> 0:04:33.340000 each other. And that's why when you utilize a tool like WordPress can, 0:04:33.340000 --> 0:04:37.960000 you can make the brute force faster or you can increase the speed of a 0:04:37.960000 --> 0:04:42.360000 brute force attack, specifically on the WordPress login form through the 0:04:42.360000 --> 0:04:47.900000 use of XML RPC. So essentially utilizing the functionality offered by 0:04:47.900000 --> 0:04:54.440000 the actual web service endpoint to facilitate a type of attack that, yes, 0:04:54.440000 --> 0:04:57.640000 we'll have consequences on the actual web application. 0:04:57.640000 --> 0:05:05.740000 But the point is that the login is not being done, you know, by intercepting 0:05:05.740000 --> 0:05:10.720000 utilizing the burp suite in Truda to essentially substitute the value 0:05:10.720000 --> 0:05:14.440000 of the password parameter and then, you know, sending requests and all 0:05:14.440000 --> 0:05:19.060000 of that. One of the really cool things that you'll notice with web services 0:05:19.060000 --> 0:05:25.520000 and APIs is that in certain cases when throttling is not enabled, you 0:05:25.520000 --> 0:05:30.300000 pretty much have the highest speed of communication and interaction. 0:05:30.300000 --> 0:05:35.000000 And you know, you can drastically speed up attacks like brute force attacks. 0:05:35.000000 --> 0:05:38.320000 So the point is that WordPress, when they decided they were going to, 0:05:38.320000 --> 0:05:42.680000 you know, create an API because they wanted, you know, developers to use 0:05:42.680000 --> 0:05:47.180000 specific sets of functionality and, you know, much more, they've now switched 0:05:47.180000 --> 0:05:51.220000 to a REST API in modern versions of WordPress. 0:05:51.220000 --> 0:05:55.920000 So the bottom line is that these are simpler alternatives to soap for 0:05:55.920000 --> 0:05:57.740000 implementing web services. 0:05:57.740000 --> 0:06:03.240000 In the case of REST, what is now popular, REST stands for representational 0:06:03.240000 --> 0:06:09.540000 state transfer. It is an architectural style for designing networked applications. 0:06:09.540000 --> 0:06:13.320000 And it utilizes HTTP as its communication protocol. 0:06:13.320000 --> 0:06:17.240000 We'll touch on all of these in a second, but I just wanted to give you 0:06:17.240000 --> 0:06:20.640000 that initial foray into all of them. 0:06:20.640000 --> 0:06:26.220000 So let's take a look at XMNR PC because it really was at a certain point, 0:06:26.220000 --> 0:06:32.140000 the most widely implemented web service implementation or most utilized 0:06:32.140000 --> 0:06:36.160000 web service implementation in terms of facilitating the communication 0:06:36.160000 --> 0:06:40.080000 in a standardized way between two systems. 0:06:40.080000 --> 0:06:45.380000 So XML RPC, XML stands for extensible markup language. 0:06:45.380000 --> 0:06:50.400000 RPC is a remote procedure call, was created in 1998 and is a protocol 0:06:50.400000 --> 0:06:56.540000 and set of conventions for encoding and decoding data in XML format and 0:06:56.540000 --> 0:06:58.960000 using it for remote procedure calls. 0:06:58.960000 --> 0:07:02.940000 It is a simple and lightweight protocol for enabling communications between 0:07:02.940000 --> 0:07:07.360000 software applications running on different systems, often over a network 0:07:07.360000 --> 0:07:08.820000 like the internet. 0:07:08.820000 --> 0:07:14.300000 XML RPC has been used as a precursor to modern web service, modern web 0:07:14.300000 --> 0:07:16.840000 service protocols like soap and REST. 0:07:16.840000 --> 0:07:21.600000 And it works by sending HTTP requests that call a single method implemented 0:07:21.600000 --> 0:07:23.800000 on the remote system. 0:07:23.800000 --> 0:07:26.040000 Okay, so very, very simple to understand. 0:07:26.040000 --> 0:07:31.340000 And you can get a better understanding of it by taking a look at a request, 0:07:31.340000 --> 0:07:33.460000 an XML RPC request. 0:07:33.460000 --> 0:07:37.900000 So in this case, you can see that this is being facilitated over HTTP. 0:07:37.900000 --> 0:07:41.520000 And in this case, you can see the request headers are pretty much what 0:07:41.520000 --> 0:07:50.940000 you would and then the actual resource or URI, and then the version of 0:07:50.940000 --> 0:07:54.440000 HTTP or the, yeah, the version of HTTP. 0:07:54.440000 --> 0:08:00.080000 And then additional request headers like the user agent, host content 0:08:00.080000 --> 0:08:02.920000 type, content length, etc. 0:08:02.920000 --> 0:08:07.720000 But if you remember, when I was pointing out or explaining how soap worked, 0:08:07.720000 --> 0:08:12.720000 the XML, the actual payload or the data or whatever you're trying to do 0:08:12.720000 --> 0:08:15.220000 is sent in XML format. 0:08:15.220000 --> 0:08:20.820000 And it must contain method call or the tag method call with the tag method 0:08:20.820000 --> 0:08:24.740000 name sub item. So method call method name. 0:08:24.740000 --> 0:08:29.480000 So you're essentially, you know, trying to access a specific type of functionality. 0:08:29.480000 --> 0:08:32.800000 In this case, the method name is my method. 0:08:32.800000 --> 0:08:38.320000 In terms of parameters, it looks like the value is set to Google.com. 0:08:38.320000 --> 0:08:41.760000 And yeah, so this, this one really doesn't make that much sense. 0:08:41.760000 --> 0:08:47.220000 But the point is that XML RPC encodes data in XML format, which is both 0:08:47.220000 --> 0:08:50.000000 human readable and machine readable. 0:08:50.000000 --> 0:08:53.340000 And this is the key thing here, where you might have still had a lingering 0:08:53.340000 --> 0:08:56.860000 amount of confusion as to what I pointed out earlier. 0:08:56.860000 --> 0:09:02.820000 And that was if web services are designed for machine to machine communication, 0:09:02.820000 --> 0:09:07.820000 how can we as attackers, you know, attack it or, you know, try and perform 0:09:07.820000 --> 0:09:10.800000 security testing on it if we cannot understand it? 0:09:10.800000 --> 0:09:15.920000 Well, the reason we can understand it is because of formats like XML. 0:09:15.920000 --> 0:09:20.840000 And in the case of APIs, where, you know, the rest API utilizes JSON, 0:09:20.840000 --> 0:09:23.500000 JSON is even much simpler to understand. 0:09:23.500000 --> 0:09:29.300000 So while they have been designed so that two systems or applications can 0:09:29.300000 --> 0:09:33.640000 communicate with one another, it doesn't mean that they obscure and cannot 0:09:33.640000 --> 0:09:37.240000 be understood. It doesn't mean that they're communicating with binary. 0:09:37.240000 --> 0:09:42.620000 It just means that they're in a format that any other system can understand. 0:09:42.620000 --> 0:09:46.380000 And this works repeatedly 100% of the time. 0:09:46.380000 --> 0:09:51.460000 So going back to the point here, XML RPC encodes data in XML format, which 0:09:51.460000 --> 0:09:54.620000 is both human readable and machine readable. 0:09:54.620000 --> 0:09:59.180000 And it utilizes XML tags to represent data types and method calls. 0:09:59.180000 --> 0:10:01.000000 Okay, so fairly simple. 0:10:01.000000 --> 0:10:04.660000 In terms of requests and responses, you can see that with this request, 0:10:04.660000 --> 0:10:08.900000 we have, you know, the method name sample method, the value is an integer 0:10:08.900000 --> 0:10:13.140000 with, you know, the number 42 or the integer value 42. 0:10:13.140000 --> 0:10:18.140000 In terms of the response, you can see based on whatever your request is 0:10:18.140000 --> 0:10:23.200000 or whatever method it is calling, and the value assigned to the parameter 0:10:23.200000 --> 0:10:25.880000 there, you will then get a response. 0:10:25.880000 --> 0:10:30.400000 In this case, you can see it says method response parameter value string 0:10:30.400000 --> 0:10:34.180000 hello world. So in this case, they don't really match because why would 0:10:34.180000 --> 0:10:37.260000 42 be linked to hello world? 0:10:37.260000 --> 0:10:38.880000 But this is just an example. 0:10:38.880000 --> 0:10:43.720000 So the point is that if I made the request, if a, if a, an application 0:10:43.720000 --> 0:10:49.820000 or web app made a request with the following method and value of 42, why 0:10:49.820000 --> 0:10:54.680000 would another web application respond with hello world? 0:10:54.680000 --> 0:10:58.780000 I just put them here to essentially highlight the response. 0:10:58.780000 --> 0:11:03.260000 So again, pay attention to the, to the differences in that in the XML 0:11:03.260000 --> 0:11:06.780000 tags. So in a request, you're using method call. 0:11:06.780000 --> 0:11:10.180000 And in the response, it responds with method response. 0:11:10.180000 --> 0:11:12.040000 So just keep that in mind. 0:11:12.040000 --> 0:11:15.780000 We then have JSON RPC, all right. 0:11:15.780000 --> 0:11:22.520000 So JSON RPC is a remote procedure call protocol that is encoded in JSON. 0:11:22.520000 --> 0:11:25.880000 JSON stands for JavaScript object notation. 0:11:25.880000 --> 0:11:31.680000 And like XML RPC, JSON RPC enables communication between software components 0:11:31.680000 --> 0:11:35.160000 or systems running on different machines or platforms. 0:11:35.160000 --> 0:11:40.300000 JSON RPC is known for its simplicity and ease of use and has become popular 0:11:40.300000 --> 0:11:44.900000 in web development and microservice, microservice architecture. 0:11:44.900000 --> 0:11:48.100000 JSON RPC is very similar to XML RPC. 0:11:48.100000 --> 0:11:53.280000 However, it is usually used because it provides much more human readable 0:11:53.280000 --> 0:11:58.780000 messages given that it utilizes JSON over XML because XML can be very 0:11:58.780000 --> 0:12:00.280000 difficult to read at times. 0:12:00.280000 --> 0:12:02.760000 I'm sure many of you can concur. 0:12:02.760000 --> 0:12:07.620000 And it's also used or preferred over XML RPC because it utilizes a less, 0:12:07.620000 --> 0:12:13.320000 a less amount of data for, for, to essentially communicate, right? 0:12:13.320000 --> 0:12:18.180000 JSON RPC allows a client to invoke methods or functions on a remote server 0:12:18.180000 --> 0:12:23.940000 by sending a JSON object that specifies the method to call and its parameters. 0:12:23.940000 --> 0:12:30.320000 The message sent to invoke a method is a request with a single, with a 0:12:30.320000 --> 0:12:32.800000 single object serialized using JSON. 0:12:32.800000 --> 0:12:34.760000 And it typically has three properties. 0:12:34.760000 --> 0:12:37.500000 This is very important in the case of JSON. 0:12:37.500000 --> 0:12:40.820000 I'm really focused on the JSON side of things here, but you'll typically 0:12:40.820000 --> 0:12:42.880000 see that you have the method. 0:12:42.880000 --> 0:12:45.820000 So that's the name of the method to invoke the parameters. 0:12:45.820000 --> 0:12:49.500000 So this is an array of objects to pass as arguments. 0:12:49.500000 --> 0:12:54.820000 And then the ID, the request ID used to match the responses or requests. 0:12:54.820000 --> 0:12:57.080000 So let's take a look at what this looks like. 0:12:57.080000 --> 0:13:02.000000 So in this case, this is an example of a JSON RPC remote procedure called 0:13:02.000000 --> 0:13:07.040000 request. And you can see here, it has the standard, if it's going over 0:13:07.040000 --> 0:13:12.400000 HTTP, it has the standard HTTP request headers where you have the again, 0:13:12.400000 --> 0:13:14.180000 the method or the verb. 0:13:14.180000 --> 0:13:18.240000 In this case, it's post the URI and then the version of HTTP. 0:13:18.240000 --> 0:13:20.920000 And then, you know, user agent host, etc. 0:13:20.920000 --> 0:13:29.780000 But now you can see the actual JSON payload is highlighted in the previous 0:13:29.780000 --> 0:13:35.000000 slide. So this is a single object serialized using JSON and note the three 0:13:35.000000 --> 0:13:36.380000 properties. We have the method. 0:13:36.380000 --> 0:13:38.360000 This is where the method is specified. 0:13:38.360000 --> 0:13:41.780000 So if I was trying to log in, for example, or authenticate, they typically 0:13:41.780000 --> 0:13:47.020000 don't call it log in, but authenticate, the parameters would be username, 0:13:47.020000 --> 0:13:50.900000 password, etc. And you know, you can also extend it via ID. 0:13:50.900000 --> 0:13:52.700000 But this is generally speaking how it works. 0:13:52.700000 --> 0:13:56.240000 And many of you who have used JSON already know this, you can already 0:13:56.240000 --> 0:14:00.520000 tell how much easier it was or how much easier it is to read over something 0:14:00.520000 --> 0:14:06.600000 like this. If I go back to XML RPC, XML generally speaking is not human 0:14:06.600000 --> 0:14:09.040000 readable, at least in my opinion. 0:14:09.040000 --> 0:14:10.320000 But there we are. 0:14:10.320000 --> 0:14:16.400000 So let's now turn our attention to the primary protocol here. 0:14:16.400000 --> 0:14:17.700000 And that's going to be soap. 0:14:17.700000 --> 0:14:26.000000 This is the one we're going to be focusing on testing in terms of object 0:14:26.000000 --> 0:14:27.340000 access protocol. 0:14:27.340000 --> 0:14:31.700000 And it is a protocol for exchanging structured information in the implementation 0:14:31.700000 --> 0:14:33.300000 of web services. 0:14:33.300000 --> 0:14:38.060000 It is a protocol that defines a set of rules and conventions for structuring 0:14:38.060000 --> 0:14:42.300000 messages, defining remote procedure calls, and handling communication 0:14:42.300000 --> 0:14:46.920000 between software components over a network, typically the internet. 0:14:46.920000 --> 0:14:51.920000 Soap is seen as the natural successor to XML RPC, and is known for its 0:14:51.920000 --> 0:14:57.420000 strong typing and extend an extensive feature set, which includes security, 0:14:57.420000 --> 0:15:00.680000 reliability, and transaction support. 0:15:00.680000 --> 0:15:06.900000 Soap web services may also but typically do provide web service web services 0:15:06.900000 --> 0:15:12.840000 definition language or WSDL declaration that specifies how they may be 0:15:12.840000 --> 0:15:15.920000 used or interacted with, which is true. 0:15:15.920000 --> 0:15:20.720000 Soap is an example of a proper protocol that is used in the implementation 0:15:20.720000 --> 0:15:22.900000 of web services, right? 0:15:22.900000 --> 0:15:27.780000 And one of the key things that you need to note is that with web service 0:15:27.780000 --> 0:15:34.340000 protocols like soap or even API protocols like rest, they usually provide 0:15:34.340000 --> 0:15:41.840000 or come with, I would use the word provide, but they usually provide a 0:15:41.840000 --> 0:15:43.820000 definition, right? 0:15:43.820000 --> 0:15:49.440000 For the actual for the actual web service or the API, what the web services 0:15:49.440000 --> 0:15:54.240000 definition language does is it does exactly that it pretty much tells 0:15:54.240000 --> 0:16:02.320000 you or you as a developer or a tester or the actual, another system, how 0:16:02.320000 --> 0:16:07.640000 the, how the web service operates and how to make specific requests for 0:16:07.640000 --> 0:16:11.320000 specific information, how to do certain things, etc. 0:16:11.320000 --> 0:16:18.220000 So it's essentially, think of it as a dictionary or a, yeah, you can think 0:16:18.220000 --> 0:16:19.000000 of it as a dictionary. 0:16:19.000000 --> 0:16:23.680000 So it essentially tells you that, hey, okay, this is the web service here. 0:16:23.680000 --> 0:16:27.260000 If you want to communicate with me, this is how to do it. 0:16:27.260000 --> 0:16:31.760000 And more so if you want to do specific things, this is how to do it. 0:16:31.760000 --> 0:16:36.040000 If there is authentication configured, it'll say before you do anything, 0:16:36.040000 --> 0:16:37.680000 make sure you authenticate. 0:16:37.680000 --> 0:16:41.420000 If you can't authenticate, I'm not going to allow you to do anything. 0:16:41.420000 --> 0:16:47.980000 Now the cool thing is, is that these are generally required that WSDLs 0:16:47.980000 --> 0:16:51.380000 are generally required and are paired with the, you know, a corresponding 0:16:51.380000 --> 0:16:54.660000 web service, because the information is required. 0:16:54.660000 --> 0:16:58.780000 Now the great thing is as a pen test, if you can find a WSDL definition 0:16:58.780000 --> 0:17:04.700000 or a web service or an API, it'll pretty much tell you how it works. 0:17:04.700000 --> 0:17:08.020000 So you don't have to figure out exactly how this works and how to make 0:17:08.020000 --> 0:17:08.700000 certain requests. 0:17:08.700000 --> 0:17:13.360000 Your job is to try and see, first, leave this authorization and authentication, 0:17:13.360000 --> 0:17:16.700000 whether you can bypass or attack the authentication. 0:17:16.700000 --> 0:17:20.800000 Secondly, you're then going to try and see what other types of vulnerabilities 0:17:20.800000 --> 0:17:26.480000 may exist based on what methods, what any, what methods are enabled or 0:17:26.480000 --> 0:17:31.740000 what methods are available in terms of getting data, authenticating, performing 0:17:31.740000 --> 0:17:34.660000 certain actions, etc. 0:17:34.660000 --> 0:17:37.640000 This is an example of a SOAP request. 0:17:37.640000 --> 0:17:41.260000 Again, you can see the request headers such as user agent, hosts, content 0:17:41.260000 --> 0:17:45.380000 type, etc. And remember, SOAP utilizes XML. 0:17:45.380000 --> 0:17:47.560000 So the body of the request is an XML. 0:17:47.560000 --> 0:17:52.540000 So that's why it's seen as the successor to XML RPC, primarily because 0:17:52.540000 --> 0:17:54.680000 of its security features. 0:17:54.680000 --> 0:18:02.400000 But you can see we have this information here, but we have the actual 0:18:02.400000 --> 0:18:07.160000 method. And then the parameter, which in this case is the host. 0:18:07.160000 --> 0:18:10.880000 And then of course, you know, you have the envelope tag, which I'll actually 0:18:10.880000 --> 0:18:12.220000 talk about later. 0:18:12.220000 --> 0:18:17.980000 So you can see very, very simple to understand in terms of now having 0:18:17.980000 --> 0:18:23.880000 a clarity on how each of these implementations operates and why one may 0:18:23.880000 --> 0:18:25.880000 be picked over the other. 0:18:25.880000 --> 0:18:30.400000 In terms of the requests and responses, you can see how they look here, 0:18:30.400000 --> 0:18:34.060000 where we'll utilize the previous example seen in the previous slide where 0:18:34.060000 --> 0:18:38.920000 the input parameter is 42 in the response based on whatever method was 0:18:38.920000 --> 0:18:42.280000 being used, the response will then respond accordingly. 0:18:42.280000 --> 0:18:44.360000 In this case, it says Hello World. 0:18:44.360000 --> 0:18:49.400000 The point is not the point is that this is not what their web services 0:18:49.400000 --> 0:18:51.100000 are typically used for. 0:18:51.100000 --> 0:18:55.600000 This is just a simple example of a request and a corresponding response. 0:18:55.600000 --> 0:18:59.540000 The output of the response is has been made much simpler. 0:18:59.540000 --> 0:19:04.360000 So as not to confuse you until you've gotten your hands dirty with with 0:19:04.360000 --> 0:19:08.200000 SOAP in this particular case, or XML for that matter. 0:19:08.200000 --> 0:19:12.580000 And that brings us finally to rest or restful APIs, right, which is what 0:19:12.580000 --> 0:19:18.960000 you typically see being used for modern day APIs or based on the definition 0:19:18.960000 --> 0:19:25.480000 APIs. So rest, which stands for Representational State Transfer is an 0:19:25.480000 --> 0:19:30.440000 architect is an architectural style for designing network applications. 0:19:30.440000 --> 0:19:35.120000 It is not a protocol or technology itself, but rather a set of principles 0:19:35.120000 --> 0:19:40.540000 and constraints that guide the design of web services and APIs. 0:19:40.540000 --> 0:19:46.140000 Rest is widely utilized for building scalable, stateless and easy to maintain, 0:19:46.140000 --> 0:19:50.140000 typically APIs that can be accessed over the internet. 0:19:50.140000 --> 0:19:55.860000 Rest web services generally utilize JSON or XML, but any other message 0:19:55.860000 --> 0:19:59.800000 transport format like even plaintext can be used, but that would, you 0:19:59.800000 --> 0:20:03.440000 know, make things a little bit complex. 0:20:03.440000 --> 0:20:09.560000 And coming to how it works, it utilizes methods primarily on an endpoint. 0:20:09.560000 --> 0:20:13.980000 So you can see we have the methods specified on the extreme left and then 0:20:13.980000 --> 0:20:19.040000 the action. So in the case of the get method, this will retrieve a resource 0:20:19.040000 --> 0:20:22.280000 on the server or list a collection of records. 0:20:22.280000 --> 0:20:27.680000 Some examples of endpoints are listed here where we have a ws.site forward 0:20:27.680000 --> 0:20:34.300000 slash book. If we make a get request, you know, with rest or that particular 0:20:34.300000 --> 0:20:39.900000 endpoint API endpoint, it subject to authentication, it will display all 0:20:39.900000 --> 0:20:44.840000 the list of books available and the same for, you know, specifying or 0:20:44.840000 --> 0:20:47.260000 trying to get a particular value. 0:20:47.260000 --> 0:20:51.100000 Like in this case, a specific book. 0:20:51.100000 --> 0:20:54.340000 In the case of put, this will change the state of a resource, replace 0:20:54.340000 --> 0:20:56.720000 it or create it if it does not exist. 0:20:56.720000 --> 0:21:00.580000 You can see that this is typically what an endpoint looks like. 0:21:00.580000 --> 0:21:04.020000 And the same for post, you know, post creates a new resource or record, 0:21:04.020000 --> 0:21:07.400000 delete, deletes a resource or record. 0:21:07.400000 --> 0:21:10.940000 So again, if you think of this from the perspective of a web service, 0:21:10.940000 --> 0:21:16.340000 you can already start to understand that in terms of attacks, nothing 0:21:16.340000 --> 0:21:18.520000 really has changed fundamentally. 0:21:18.520000 --> 0:21:23.000000 The point is that the same SQL injection payload that you were using in 0:21:23.000000 --> 0:21:26.400000 a web application would still apply here. 0:21:26.400000 --> 0:21:30.860000 Your job is to try and find inputs that are not sanitized and based on 0:21:30.860000 --> 0:21:35.040000 what I defined in the previous video and the differences between web applications 0:21:35.040000 --> 0:21:42.020000 and APIs or web services, you can already tell that if these protocols 0:21:42.020000 --> 0:21:46.480000 are used, not in the case of rest, but if these protocols are used for 0:21:46.480000 --> 0:21:51.500000 in the case of web services to essentially facilitate machine to machine 0:21:51.500000 --> 0:21:56.440000 communication, they may not have input validation. 0:21:56.440000 --> 0:21:57.900000 And you're exactly right. 0:21:57.900000 --> 0:22:02.220000 And that's why that is the importance of performing web service security 0:22:02.220000 --> 0:22:07.740000 testing, because a lot of developers and companies had ignored the security 0:22:07.740000 --> 0:22:13.940000 implications of, again, not factoring in or not thinking or considering 0:22:13.940000 --> 0:22:19.520000 once that attackers would try and would try and modify these services 0:22:19.520000 --> 0:22:20.900000 or these endpoints. 0:22:20.900000 --> 0:22:24.420000 And if they don't have the standard protection mechanisms, then you're 0:22:24.420000 --> 0:22:27.700000 in trouble because those attacks will work just the same. 0:22:27.700000 --> 0:22:30.720000 I can utilize the same SQL injection payload. 0:22:30.720000 --> 0:22:34.940000 Maybe I'll have to modify it a little bit, but the logic remains the same. 0:22:34.940000 --> 0:22:40.500000 If you're making a request via soap, let's say, via a soap web service, 0:22:40.500000 --> 0:22:46.480000 and it is, that request will then be processed or will involve interaction 0:22:46.480000 --> 0:22:49.480000 with the back end MySQL database. 0:22:49.480000 --> 0:22:53.980000 And the input is not being validated for malicious payloads. 0:22:53.980000 --> 0:22:59.160000 I'll pretty much be able to perform you know, SQL injection attack. 0:22:59.160000 --> 0:23:03.420000 Now, the nuance comes into play, or whether the nuance comes into play 0:23:03.420000 --> 0:23:04.960000 is the response. 0:23:04.960000 --> 0:23:10.480000 So in most cases, what you'll typically see is in certain cases, the response 0:23:10.480000 --> 0:23:12.320000 may give you some data back. 0:23:12.320000 --> 0:23:15.580000 In that case, it'll be error based SQL injection. 0:23:15.580000 --> 0:23:20.980000 But in most cases, APIs or web services, generally speaking, depending 0:23:20.980000 --> 0:23:25.960000 on the implementation of a particular method, may not return a response 0:23:25.960000 --> 0:23:31.620000 in a format that is understandable or desirable for a human being. 0:23:31.620000 --> 0:23:36.460000 The point is that web services or communication between two machines is 0:23:36.460000 --> 0:23:42.600000 very simple. They just request was processed correctly. 0:23:42.600000 --> 0:23:48.380000 So they may not return output in in text format, because why would a computer 0:23:48.380000 --> 0:23:52.280000 or an application need that they would just need what is important. 0:23:52.280000 --> 0:23:56.880000 And what is important, generally speaking is, yes, your request was processed 0:23:56.880000 --> 0:23:59.940000 successfully or no, there was an issue with your syntax. 0:23:59.940000 --> 0:24:04.300000 That's all. So you're all starting to get an understanding as to how all 0:24:04.300000 --> 0:24:06.180000 of this ties in together. 0:24:06.180000 --> 0:24:10.260000 And with that being said, now that we've covered in my eyes, the fundamentals 0:24:10.260000 --> 0:24:16.760000 of web services and the underlying technology, barring one video or the 0:24:16.760000 --> 0:24:20.720000 video we're exploring next, we can now start to better understand where 0:24:20.720000 --> 0:24:22.960000 the vulnerabilities lie. 0:24:22.960000 --> 0:24:26.860000 And now that we understand that I'm really excited and I'm sure you must 0:24:26.860000 --> 0:24:30.940000 be too in terms of getting your hands dirty. 0:24:30.940000 --> 0:24:33.700000 And don't worry, that will be coming as we proceed. 0:24:33.700000 --> 0:24:37.300000 But with that being said, that's going to be it for this video. 0:24:37.300000 --> 0:24:39.200000 And I will be seeing you in the next video.