WEBVTT 0:00:03.580000 --> 0:00:05.920000 Hello everyone and welcome. 0:00:05.920000 --> 0:00:10.680000 In this video we're going to be taking a closer look at server-side attacks, 0:00:10.680000 --> 0:00:17.680000 more specifically understanding what we mean when we say server-side. 0:00:17.680000 --> 0:00:22.860000 I'm pretty sure that you've probably been asking yourself the same question 0:00:22.860000 --> 0:00:28.560000 at the end of the previous video where we went through the modern web 0:00:28.560000 --> 0:00:33.060000 application architecture and we got to see a couple of examples. 0:00:33.060000 --> 0:00:37.880000 We didn't see any explicit reference to the term server-side and again 0:00:37.880000 --> 0:00:42.000000 you may be asking yourself well what exactly are you talking about when 0:00:42.000000 --> 0:00:45.900000 you say server-side and that's exactly what we're going to address in 0:00:45.900000 --> 0:00:51.140000 this video. So to begin with what does server-side mean? 0:00:51.140000 --> 0:00:57.060000 Now in the context of web application penetration testing the term server 0:00:57.060000 --> 0:01:03.240000 -side refers to the processes logic and infrastructure that operate on 0:01:03.240000 --> 0:01:05.940000 the server rather than the client. 0:01:05.940000 --> 0:01:10.960000 Now what that means especially when juxtaposed against what we covered 0:01:10.960000 --> 0:01:22.860000 in the previous video, you know layers and reference operate on the server. 0:01:22.860000 --> 0:01:28.060000 The best way to think about it is that server-side attacks deal with the 0:01:28.060000 --> 0:01:33.600000 web server layer or you know the business logic layer if you will which 0:01:33.600000 --> 0:01:35.740000 we'll take a look at shortly. 0:01:35.740000 --> 0:01:39.500000 So just think of web servers and application servers. 0:01:39.500000 --> 0:01:44.300000 Now it encompasses a little bit more but because we've covered some of 0:01:44.300000 --> 0:01:50.840000 the other attacks that involve or that revolve around let's say the data 0:01:50.840000 --> 0:01:54.760000 layer where you'd find databases which you know we actually tackled in 0:01:54.760000 --> 0:02:00.260000 the injection course and then of course APIs or the API layer which we 0:02:00.260000 --> 0:02:04.900000 covered in its own course we're really going to be narrowing down or focusing 0:02:04.900000 --> 0:02:14.200000 on specifically the application layer but you know that's really what 0:02:14.200000 --> 0:02:18.480000 this would mean in the case of this specific course however generally 0:02:18.480000 --> 0:02:22.300000 speaking I think it was it's probably important for me to explain what 0:02:22.300000 --> 0:02:24.420000 you know server-side means. 0:02:24.420000 --> 0:02:29.740000 So server-side functionality handles critical tasks such as request processing, 0:02:29.740000 --> 0:02:34.400000 business logic execution as you can see here communication with databases 0:02:34.400000 --> 0:02:37.940000 and APIs and integration with internal services. 0:02:37.940000 --> 0:02:43.660000 Unlike client-side vulnerabilities which target the user-facing components, 0:02:43.660000 --> 0:02:48.540000 server-side vulnerabilities exploit weaknesses in how the server processes 0:02:48.540000 --> 0:02:54.720000 inputs communicates with other systems and managers resources. 0:02:54.720000 --> 0:02:59.200000 So you can see deals with a lot of functions here and you know we've talked 0:02:59.200000 --> 0:03:04.820000 where we've explored input or injection -related attacks but now we're 0:03:04.820000 --> 0:03:07.880000 going to turn our attention to some of the other stuff that you know the 0:03:07.880000 --> 0:03:12.380000 back-end does if you will more specifically the application server. 0:03:12.380000 --> 0:03:17.640000 So that brings us now to server-side attacks. 0:03:17.640000 --> 0:03:22.820000 So we know what server-side is referring to but you know what is or what's 0:03:22.820000 --> 0:03:24.860000 involved in attacking the server-side. 0:03:24.860000 --> 0:03:31.100000 Well server-side attacks are exploits or attacks that target the back 0:03:31.100000 --> 0:03:36.380000 -end components of a web application and this includes web servers, application 0:03:36.380000 --> 0:03:39.320000 servers but also APIs and databases. 0:03:39.320000 --> 0:03:44.240000 Now as I mentioned this is generally not considered because for APIs and 0:03:44.240000 --> 0:03:48.860000 databases you really want to you know target or test them separately just 0:03:48.860000 --> 0:03:53.400000 given how complex they can be and that's why we did the same in this learning 0:03:53.400000 --> 0:03:58.600000 path. We covered API penetration testing in its own course or you know 0:03:58.600000 --> 0:04:03.480000 if I'm to speak in the language of this course we took a look at how to 0:04:03.480000 --> 0:04:05.280000 attack the API layer. 0:04:05.280000 --> 0:04:08.900000 We also took a look at how to attack the database layer in the advanced 0:04:08.900000 --> 0:04:10.300000 injections course. 0:04:10.300000 --> 0:04:14.180000 So we're now turning our attention to you know the application servers 0:04:14.180000 --> 0:04:19.280000 specifically or what you know what we would colloquially describe as the 0:04:19.280000 --> 0:04:28.740000 back-end right. So again I need to reiterate that unlike client-side if 0:04:28.740000 --> 0:04:32.940000 you will server-side attacks manipulate or exploit vulnerabilities in 0:04:32.940000 --> 0:04:37.980000 the server-side infrastructure or the server layer whether that be the 0:04:37.980000 --> 0:04:43.480000 web server layer or the application server layer. 0:04:43.480000 --> 0:04:47.960000 So these attacks can lead to you know unauthorized access, data breaches 0:04:47.960000 --> 0:04:50.380000 or even full-system compromise. 0:04:50.380000 --> 0:04:58.200000 I should say specifically full-system compromise especially in light of 0:04:58.200000 --> 0:05:02.580000 and this is because they leverage weaknesses in our servers process requests 0:05:02.580000 --> 0:05:05.840000 communicate with other components and manage data. 0:05:05.840000 --> 0:05:09.380000 So again as I pointed out a few seconds ago in this course we will only 0:05:09.380000 --> 0:05:13.780000 be focusing on vulnerabilities specific to the application or business 0:05:13.780000 --> 0:05:18.100000 layer as we have already explored attacks against the data layer which 0:05:18.100000 --> 0:05:22.780000 you know where you'd find your databases as well as API or the API layer. 0:05:22.780000 --> 0:05:26.980000 So I just want to ensure that again you understand exactly what we're 0:05:26.980000 --> 0:05:29.820000 targeting and this will make sense as we progress. 0:05:29.820000 --> 0:05:35.620000 Now one important thing or something that's important is that in order 0:05:35.620000 --> 0:05:39.760000 for you to differentiate server-side vulnerabilities from other types 0:05:39.760000 --> 0:05:43.340000 of web application vulnerabilities like let's say injection vulnerabilities 0:05:43.340000 --> 0:05:47.660000 you need to understand the specific functional characteristics and context 0:05:47.660000 --> 0:05:52.240000 of server-side functionality in a modern web application infrastructure 0:05:52.240000 --> 0:05:57.660000 or architecture and here are the key criterion factors to consider. 0:05:57.660000 --> 0:06:02.000000 So essentially what I've listed out here which you know continues into 0:06:02.000000 --> 0:06:06.880000 the next set of slides is how do you determine if a vulnerability or attack 0:06:06.880000 --> 0:06:12.220000 is server-side and how do you you know differentiate it from let's say 0:06:12.220000 --> 0:06:17.460000 an injection attack or I should say injection specific attack. 0:06:17.460000 --> 0:06:21.260000 So firstly we have the execution context right. 0:06:21.260000 --> 0:06:24.020000 So this actually makes or should make sense. 0:06:24.020000 --> 0:06:29.380000 Server-side vulnerabilities occur in the code or logic executed on the 0:06:29.380000 --> 0:06:33.220000 server rather than on the client or client side. 0:06:33.220000 --> 0:06:36.440000 So in your browser that's why we don't have we're not covering cross-side 0:06:36.440000 --> 0:06:38.340000 scripting here right. 0:06:38.340000 --> 0:06:43.660000 And this includes processes and interactions within components such as 0:06:43.660000 --> 0:06:48.560000 the web server application server and backend services and this will be 0:06:48.560000 --> 0:06:52.180000 something that will become apparent in the SSRF section of the course 0:06:52.180000 --> 0:06:56.040000 when we'll be taking a look at chaining vulnerabilities. 0:06:56.040000 --> 0:07:00.740000 I'll not divulge too much right now but you know we actually you'll actually 0:07:00.740000 --> 0:07:06.740000 see what the second point here means when we talk about the inclusion 0:07:06.740000 --> 0:07:12.440000 of processes and more so interactions with within components like you 0:07:12.440000 --> 0:07:14.700000 know the web server application server etc. 0:07:14.700000 --> 0:07:17.320000 And then of course you have the scope. 0:07:17.320000 --> 0:07:22.460000 So this is actually again it should make sense these vulnerabilities typically 0:07:22.460000 --> 0:07:27.800000 affect the server's infrastructure or let's say the application server 0:07:27.800000 --> 0:07:33.840000 layer configuration or inter component communication rather than the client 0:07:33.840000 --> 0:07:48.560000 side or the database that would be a server-side attack. 0:07:48.560000 --> 0:07:52.740000 However you need to distinguish it and you need to distinguish server 0:07:52.740000 --> 0:07:55.320000 -side specific vulnerabilities. 0:07:55.320000 --> 0:08:00.620000 So vulnerability is native to a specific layer as opposed to you know 0:08:00.620000 --> 0:08:06.020000 these complex attacks which again would be considered server-side but 0:08:06.020000 --> 0:08:10.620000 in juxtaposition or in comparison to stuff like injection-based attacks 0:08:10.620000 --> 0:08:15.200000 it can be very easy to conflate the two and to think that you know because 0:08:15.200000 --> 0:08:19.440000 you're performing injection that that is server-side it is and I understand 0:08:19.440000 --> 0:08:23.280000 that you might be thinking to yourself that you know server-side actually 0:08:23.280000 --> 0:08:28.360000 describes it pretty well but again in the context of this course now armed 0:08:28.360000 --> 0:08:32.760000 with the knowledge of the you know modern web application architecture 0:08:32.760000 --> 0:08:35.140000 the different models available. 0:08:35.140000 --> 0:08:39.200000 Again if you use the example of the microservices architecture model you 0:08:39.200000 --> 0:08:45.440000 can see that it's quite unwise to call a SQL injection attack server-side 0:08:45.440000 --> 0:08:51.560000 because again when you're talking about attacking data stores or databases 0:08:51.560000 --> 0:08:56.640000 it's not really the application logic per se you're really targeting the 0:08:56.640000 --> 0:08:59.580000 database and you're doing so through queries. 0:08:59.580000 --> 0:09:05.420000 Now examples of what I mean when I say scope here as sort of like a criteria 0:09:05.420000 --> 0:09:11.340000 for distinguishing server-side attacks or vulnerabilities from other types 0:09:11.340000 --> 0:09:16.800000 is you know file system manipulation internal network access and configuration 0:09:16.800000 --> 0:09:22.720000 exposure. So if you look at these examples they should actually again 0:09:22.720000 --> 0:09:27.440000 prove my point when I said that you know injection SQL injection as an 0:09:27.440000 --> 0:09:32.720000 example really deals with stuff in the database whereas when we now you 0:09:32.720000 --> 0:09:37.280000 know talk about server-side attacks specifically they really give you 0:09:37.280000 --> 0:09:43.180000 a different outcomes so you have file system manipulation, file system 0:09:43.180000 --> 0:09:47.600000 not database, file system manipulation they allow you to do some interesting 0:09:47.600000 --> 0:09:52.700000 things on the network and of course configuration exposure which you know 0:09:52.700000 --> 0:09:57.680000 to a certain extent you can do via you know SQL injection but again you 0:09:57.680000 --> 0:10:01.640000 can actually start to see what distinguishes the two and then of course 0:10:01.640000 --> 0:10:10.680000 you have interaction with and in this case you know vulnerabilities that 0:10:10.680000 --> 0:10:16.060000 exploit how the server interacts with other components for example APIs, 0:10:16.060000 --> 0:10:20.880000 microservices or external systems and again in this case if we use the 0:10:20.880000 --> 0:10:26.060000 example of SQL injection you can start to see that you know it's not really 0:10:26.060000 --> 0:10:33.080000 a native server-side attack of vulnerability you can utilize a server 0:10:33.080000 --> 0:10:38.240000 -side vulnerability specifically in the application layer and that's exactly 0:10:38.240000 --> 0:10:42.880000 what you do but also in the presentation layer because there's sanitization 0:10:42.880000 --> 0:10:49.000000 on that front as well you know and through that you're able to eventually 0:10:49.000000 --> 0:10:54.800000 reach the database so again very important to state that these do not 0:10:54.800000 --> 0:11:00.440000 directly target the database layer example SQL injection but may involve 0:11:00.440000 --> 0:11:05.160000 communication with it indirectly and that's true so this is all very nuanced 0:11:05.160000 --> 0:11:09.780000 but what I'm referring to the objective is to show you that they are native 0:11:09.780000 --> 0:11:16.240000 or vulnerabilities inherent to a specific layer if we use the the nomenclature 0:11:16.240000 --> 0:11:21.240000 used in the in the layered architecture model that we explored in the 0:11:21.240000 --> 0:11:26.500000 previous video some other criteria revolve around trust assumptions right 0:11:26.500000 --> 0:11:31.620000 so server-side vulnerabilities often exploit implicit very important word 0:11:31.620000 --> 0:11:36.560000 implicit trust between the server and its resources or components what 0:11:36.560000 --> 0:11:42.280000 does that mean well what what that means is that because let's say the 0:11:42.280000 --> 0:11:47.020000 application layer is considered the heart of the web application and you 0:11:47.020000 --> 0:11:53.280000 know it does all the you know it pretty much caters for a lot of the back 0:11:53.280000 --> 0:11:58.440000 end or what you'd consider to be back end functionality because of that 0:11:58.440000 --> 0:12:02.900000 you know if you're designing your web app you would assume or you would 0:12:02.900000 --> 0:12:07.720000 configure some of the other components like the database or the API layer 0:12:07.720000 --> 0:12:13.560000 to communicate implicitly or to be able to communicate implicitly with 0:12:13.560000 --> 0:12:22.660000 the the application server layer because again if you seems quite you 0:12:22.660000 --> 0:12:27.540000 know quite well hidden or you know generally speaking through your browser 0:12:27.540000 --> 0:12:33.280000 you're not able to interact with it quote unquote not able to I should 0:12:33.280000 --> 0:12:41.020000 say but hopefully you're getting you're getting an idea as to how this 0:12:41.020000 --> 0:12:46.240000 appears or what this looks like from the perspective of a developer there 0:12:46.240000 --> 0:12:54.380000 are certain trust assumptions you know that are if if you know if I can 0:12:54.380000 --> 0:12:59.100000 use the word here again implicit when you're talking about you know stuff 0:12:59.100000 --> 0:13:03.600000 that normal users cannot see through their browser so that's what we're 0:13:03.600000 --> 0:13:07.360000 trying to exploit is the fact that I'll give you a very tacit example 0:13:07.360000 --> 0:13:15.760000 if you're again setting up a WordPress site again on a Linux server not 0:13:15.760000 --> 0:13:20.000000 running as a as a container or anything but when you're configuring the 0:13:20.000000 --> 0:13:24.320000 connector which is part of the WordPress core and that's why by the way 0:13:24.320000 --> 0:13:28.700000 you'll see that we have vulnerabilities affecting WordPress plugins themes 0:13:28.700000 --> 0:13:34.300000 but something called the core and that's the application server so what 0:13:34.300000 --> 0:13:38.380000 what I was saying is when you're installing WordPress you need to specify 0:13:38.380000 --> 0:13:43.900000 credentials to access the MySQL database or whatever relational database 0:13:43.900000 --> 0:13:50.080000 you're using or want to use and again if you've not exposed the MySQL 0:13:50.080000 --> 0:13:54.240000 database or you know you're not you've not exposed the port you're just 0:13:54.240000 --> 0:13:59.500000 running it local host you'd say to yourself well you know I don't expect 0:13:59.500000 --> 0:14:05.940000 anyone to ever you know to ever reach this particular point or to interact 0:14:05.940000 --> 0:14:11.540000 with the application server so closely or so directly that they would 0:14:11.540000 --> 0:14:17.220000 be able to then access the database you what ends up happening is you 0:14:17.220000 --> 0:14:21.940000 know developers myself included would end up being too permissive with 0:14:21.940000 --> 0:14:30.160000 the connection between the application server and other components like 0:14:30.160000 --> 0:14:35.160000 the database or the data layer if that makes sense and what that ultimately 0:14:35.160000 --> 0:14:40.420000 ends up being is you use the root credentials in the connector or you 0:14:40.420000 --> 0:14:44.660000 configure the connector that allows you to interact allows the application 0:14:44.660000 --> 0:14:48.920000 server layer to interact with the database layer you know you essentially 0:14:48.920000 --> 0:14:54.940000 use root credentials because again trust assumptions so for example now 0:14:54.940000 --> 0:15:00.460000 speaking specifically about what this can lead up to or you know provide 0:15:00.460000 --> 0:15:05.220000 us as an attacker is you know the trust in user input which leads to insecurity 0:15:05.220000 --> 0:15:12.400000 serialization trust in internal network requests leads to SSRF so it's 0:15:12.400000 --> 0:15:16.900000 these trust assumptions that are made by the developers that again lead 0:15:16.900000 --> 0:15:21.480000 to or often cause vulnerabilities like the ones I've just pointed out 0:15:21.480000 --> 0:15:26.560000 here some other criteria which you know before you started this course 0:15:26.560000 --> 0:15:31.320000 this is what you typically be you would have considered server side because 0:15:31.320000 --> 0:15:35.460000 again you weren't aware of the fact that or you may have been but you 0:15:35.460000 --> 0:15:40.120000 you are not privy to the web application the modern web application architecture 0:15:40.120000 --> 0:15:45.420000 which again goes beyond just one server or one component so server resources 0:15:45.420000 --> 0:15:48.740000 you know these would be vulnerabilities that manipulate or exploit the 0:15:48.740000 --> 0:15:53.520000 resources and capabilities of the server such as its file system memory 0:15:53.520000 --> 0:15:58.160000 or CPU an example of this would be file upload right file upload vulnerability 0:15:58.160000 --> 0:16:05.360000 where you bypass the filter and you're in there so another criteria there 0:16:05.360000 --> 0:16:11.880000 now that begs the question what layers if we're to use the layered architecture 0:16:11.880000 --> 0:16:18.580000 model generally speaking the others would apply also but what layers are 0:16:18.580000 --> 0:16:22.420000 targeted or what layers do you target when you're talking about server 0:16:22.420000 --> 0:16:26.500000 side attacks and I guess I've already answered this but I think I need 0:16:26.500000 --> 0:16:30.760000 to be a bit more specific here so in a typical you know web application 0:16:30.760000 --> 0:16:34.360000 architecture server side attacks primarily target the following layers 0:16:34.360000 --> 0:16:39.200000 the web server layer which I mentioned so think of Apache stuff like that 0:16:39.200000 --> 0:16:44.560000 you know the web server layer is responsible or handles HTTP requests 0:16:44.560000 --> 0:16:48.480000 and serves static content or what is then displayed in the presentation 0:16:48.480000 --> 0:16:53.300000 layer in your browser pretty much the web server layer also typically 0:16:53.300000 --> 0:16:58.500000 acts as a gateway to the application server and then of course we have 0:16:58.500000 --> 0:17:02.040000 the application server layer which is sort of going to be our focus in 0:17:02.040000 --> 0:17:06.620000 this course this layer is responsible for processing dynamic content and 0:17:06.620000 --> 0:17:11.400000 execution of business logic right and it also does other stuff really 0:17:11.400000 --> 0:17:15.420000 cool stuff like communicating with the database and APIs to fulfill client 0:17:15.420000 --> 0:17:21.920000 requests and then of course we have the data access layer indirect you 0:17:21.920000 --> 0:17:27.520000 know indirectly here so exploits from the application or web server may 0:17:27.520000 --> 0:17:31.800000 manipulate data or compromise database integrity but they're not really 0:17:31.800000 --> 0:17:36.000000 targeted you know we talk about server side attacks you're not really 0:17:36.000000 --> 0:17:40.680000 going for directly you're not directly going for the data access layer 0:17:40.680000 --> 0:17:46.760000 you may end up there somehow as we'll see but that's not your focus you're 0:17:46.760000 --> 0:17:51.440000 really focused on you know the web server layer or the application server 0:17:51.440000 --> 0:17:58.600000 lens and you know some of the other functions that the the application 0:17:58.600000 --> 0:18:03.860000 server layer may be maybe performing or maybe interacting with including 0:18:03.860000 --> 0:18:09.080000 APIs as well but the key point is that the API layer and the data access 0:18:09.080000 --> 0:18:13.320000 layer not the focus it's really the web server layer and the application 0:18:13.320000 --> 0:18:17.840000 server layer so this diagram which we saw in the previous video don't 0:18:17.840000 --> 0:18:23.740000 worry if it looks too complex i've just organized it in a way that you 0:18:23.740000 --> 0:18:28.840000 know pretty much summarizes or reviews what we covered in the previous 0:18:28.840000 --> 0:18:35.400000 video but now contextualizes it a little bit more and also accounts for 0:18:35.400000 --> 0:18:39.300000 some of the terminology that i've been that i've been using interchange 0:18:39.300000 --> 0:18:45.720000 interchange interchangeably so when we talk about client side as i mentioned 0:18:45.720000 --> 0:18:49.680000 in the previous video web browser mobile application typical examples 0:18:49.680000 --> 0:18:55.640000 this is typically called the client side by pen testers right but from 0:18:55.640000 --> 0:18:59.820000 the developer's perspective it's called the presentation layer or this 0:18:59.820000 --> 0:19:03.820000 is what it's referred to as specifically when using the layered architecture 0:19:03.820000 --> 0:19:09.140000 model and then when i refer to the business or application layer what 0:19:09.140000 --> 0:19:13.820000 i'm referring to pretty much is the web server layer or tier or the application 0:19:13.820000 --> 0:19:18.760000 server tier which you can now see are now i've now separated that's what 0:19:18.760000 --> 0:19:23.280000 we would call server side now the other stuff comes into play or can be 0:19:23.280000 --> 0:19:27.080000 considered server side which is why internal services is highlighted in 0:19:27.080000 --> 0:19:31.800000 this in the same shade of orange as server side but it's not it's not 0:19:31.800000 --> 0:19:38.300000 really server side and i've already provided you with the reasons as to 0:19:38.300000 --> 0:19:42.980000 why you know it's not or they're not the API layer you can see is separate 0:19:42.980000 --> 0:19:48.560000 very important now as you can see here with this example because the application 0:19:48.560000 --> 0:19:55.060000 servers maybe are interacting with let's say the API layer and or the 0:19:55.060000 --> 0:20:02.860000 database layer you can eventually extend or chain vulnerabilities or exploitation 0:20:02.860000 --> 0:20:10.600000 whereby you exploit a server side or business slash application layer 0:20:10.600000 --> 0:20:16.900000 vulnerability like deserialization or SSRF that ends up you know allowing 0:20:16.900000 --> 0:20:20.620000 you to exploit the other layers or to access some of the other layers 0:20:20.620000 --> 0:20:24.780000 but the point is and i need to reiterate it when we talk about server 0:20:24.780000 --> 0:20:29.840000 side you again in some way may interact with the API layer or database 0:20:29.840000 --> 0:20:35.340000 layers part of the exploitation but it's not the focus the focus is going 0:20:35.340000 --> 0:20:40.200000 to be on inherent vulnerabilities within the layer as a whole but within 0:20:40.200000 --> 0:20:44.540000 you know web servers or application servers so hopefully this makes sense 0:20:44.540000 --> 0:20:50.920000 now and the terminology is sort of lining up but there we are and then 0:20:50.920000 --> 0:20:54.520000 of course i needed i think it was quite important for me to distinguish 0:20:54.520000 --> 0:20:57.760000 between a web server and an app server even though you know i'm pretty 0:20:57.760000 --> 0:21:01.700000 sure you're aware of the differences between the two but we have a web 0:21:01.700000 --> 0:21:07.180000 server application server and then the criteria categories of the differences 0:21:07.180000 --> 0:21:11.660000 or functionality have been added to the leftmost column where you have 0:21:11.660000 --> 0:21:16.360000 the role interaction processing output and some examples so in terms of 0:21:16.360000 --> 0:21:20.260000 the role that a web server plays you know as i said self-static content 0:21:20.260000 --> 0:21:25.240000 routes requests application server executes business logic generates dynamic 0:21:25.240000 --> 0:21:29.840000 responses in terms of interaction the web server communicates with the 0:21:29.840000 --> 0:21:41.020000 clients or communicates with databases apis and services so you can sort 0:21:41.020000 --> 0:21:45.560000 of understand why server side attacks are actually quite important or 0:21:45.560000 --> 0:21:51.620000 can actually be fairly critical in terms of their impact and then in terms 0:21:51.620000 --> 0:21:56.660000 of processing the web server an example is apache handles lightweight 0:21:56.660000 --> 0:22:01.580000 tasks like static file serving think of an html or bootstrap landing page 0:22:01.580000 --> 0:22:05.640000 something like that and then the application server handles the heavy 0:22:05.640000 --> 0:22:11.080000 processing tasks like data processing processing queries from login forms 0:22:11.080000 --> 0:22:19.000000 you know stuff like this and then you have the output so the output for 0:22:19.000000 --> 0:22:23.860000 web services you know typically to serve files html css javascript and 0:22:23.860000 --> 0:22:31.600000 then application server serves computed data json html xml which we covered 0:22:31.600000 --> 0:22:40.060000 in the advanced injection advanced injection attacks course and then examples 0:22:40.060000 --> 0:22:44.840000 of a web server which again you should now know or you probably were aware 0:22:44.840000 --> 0:22:50.120000 of them apache nginx micsoft ias web server in the case of an application 0:22:50.120000 --> 0:22:54.680000 server and many this is where a lot of people either get surprised whenever 0:22:54.680000 --> 0:22:59.620000 again i'm teaching this particular topic we have no js jango and spring 0:22:59.620000 --> 0:23:04.260000 boot and that's what they are and and now hopefully it's all coming together 0:23:04.260000 --> 0:23:09.220000 when if you search for on wikipedia for jango or no js they use the word 0:23:09.220000 --> 0:23:14.520000 server side and i hope it's starting to make sense now but technically 0:23:14.520000 --> 0:23:29.600000 speaking they're here even if they function as a web server they're not 0:23:29.600000 --> 0:23:36.100000 you typically actually in this case let's stick with jango flask in a 0:23:36.100000 --> 0:23:42.440000 production environment you would configure a jango flask to proxy requests 0:23:42.440000 --> 0:23:49.920000 through an actual web server like nginx so hopefully this this actually 0:23:49.920000 --> 0:23:54.460000 clarifies any potential questions you may have had regarding you know 0:23:54.460000 --> 0:23:58.120000 the actual distinction between the two because again i'm also guilty of 0:23:58.120000 --> 0:24:03.180000 this i have been guilty of it you know in terms of not understanding where 0:24:03.180000 --> 0:24:08.100000 to draw the line but hopefully this this table does it for you all right 0:24:08.100000 --> 0:24:12.760000 now i think i know the next question you're asking or you're probably 0:24:12.760000 --> 0:24:17.120000 asking yourself and that is okay Alexis could you tell us what vulnerabilities 0:24:17.120000 --> 0:24:22.640000 affect web servers as you've described them here and application servers 0:24:22.640000 --> 0:24:27.180000 again as you've defined them here well let's take a look so vulnerabilities 0:24:27.180000 --> 0:24:32.340000 in the web server layer which remember is different especially in the 0:24:32.340000 --> 0:24:36.320000 led architecture model you would have your traditional ones like directory 0:24:36.320000 --> 0:24:40.300000 traversal that's why if you go and search for cve's related to Apache 0:24:40.300000 --> 0:24:46.260000 or nginx a majority of them are going to uh are going to be related to 0:24:46.260000 --> 0:24:50.680000 directory traversal so if you're not familiar with what directory traversal 0:24:50.680000 --> 0:24:56.720000 is you know in this case you know it involves uh the actual exploitation 0:24:56.720000 --> 0:25:02.020000 involves you know it exploits in proper validation or file paths to access 0:25:02.020000 --> 0:25:06.400000 sensitive files outside the intended directory so an example of what that 0:25:06.400000 --> 0:25:10.420000 would look like is when you use uh you know essentially traversing uh 0:25:10.420000 --> 0:25:14.760000 the directory and in this case trying to get the contents of the password 0:25:14.760000 --> 0:25:20.860000 file on linux you also have others like HTTP response splitting so this 0:25:20.860000 --> 0:25:25.120000 manipulates HTTP headers to inject malicious responses or redirect users 0:25:25.120000 --> 0:25:29.800000 to malicious sites now it's starting to make sense uh you know when we 0:25:29.800000 --> 0:25:34.360000 describe these as web server layer vulnerabilities or vulnerabilities 0:25:34.360000 --> 0:25:38.640000 specific to web servers it starts to make sense because now that i've 0:25:38.640000 --> 0:25:48.600000 described or defined what web servers mean really especially from the 0:25:48.600000 --> 0:25:53.260000 architecture you can you can start to understand that if you are if you're 0:25:53.260000 --> 0:25:58.380000 able to you know perform HTTP response splitting that you're really targeting 0:25:58.380000 --> 0:26:02.180000 the web server layer you're not really it's not really the web application 0:26:02.180000 --> 0:26:08.260000 per se or the application server it's really the web server and then of 0:26:08.260000 --> 0:26:12.480000 course you have your standards like misconfigured TLS set so exploits 0:26:12.480000 --> 0:26:17.580000 we co-outdated configurations example of this is supporting SSL version 0:26:17.580000 --> 0:26:21.960000 3 or weak ciphers allowing man in the middle attacks then you have your 0:26:21.960000 --> 0:26:25.920000 file inclusion vulnerabilities that you know exploits in proper handling 0:26:25.920000 --> 0:26:31.360000 or file paths to execute unauthorized files on the server um and you know 0:26:31.360000 --> 0:26:36.980000 it should be fairly simple now it's it should start to make sense and 0:26:36.980000 --> 0:26:40.740000 then of course you have the app server layer and the vulnerabilities found 0:26:40.740000 --> 0:26:48.760000 therein now this is not you know um this is not a comprehensive list but 0:26:48.760000 --> 0:26:55.020000 uh again i've sort of structured it um in a way that makes sense so starting 0:26:55.020000 --> 0:26:59.860000 off with server site request forgery uh this exploits the server's ability 0:26:59.860000 --> 0:27:06.260000 to make HTTP requests enabling attackers to access internal or external 0:27:06.260000 --> 0:27:11.940000 resources okay and then insecure deserialization this allows attackers 0:27:11.940000 --> 0:27:17.140000 to inject malicious payloads during the deserialization process which 0:27:17.140000 --> 0:27:21.680000 could potentially lead to remote code execution or privilege escalation 0:27:21.680000 --> 0:27:26.740000 which now if you if you think of it from you know the from the perspective 0:27:26.740000 --> 0:27:31.620000 of layers it actually makes sense you know Apache really can't you really 0:27:31.620000 --> 0:27:36.380000 can't elevate your privileges with uh you know there isn't a vulnerability 0:27:36.380000 --> 0:27:41.300000 uh native to let's say Apache that leads to privilege escalation because 0:27:41.300000 --> 0:27:47.620000 again of its role in the architecture what it does limits its functionality 0:27:47.620000 --> 0:27:51.940000 uh and what it can access however when you're dealing with the actual 0:27:51.940000 --> 0:28:00.680000 application server you can now access more that's why they're more examples 0:28:00.680000 --> 0:28:05.360000 here are broken access control so uh flaws in unauthorized logic allow 0:28:05.360000 --> 0:28:10.160000 attackers to perform actions or access resources without proper permissions 0:28:10.160000 --> 0:28:14.100000 and then of course command injection uh this exploits vulnerabilities 0:28:14.100000 --> 0:28:19.040000 in the application server to execute arbitrary system commands on the 0:28:19.040000 --> 0:28:24.200000 host and that's why if you're uh if you're taking a look at exploit DB 0:28:24.200000 --> 0:28:30.100000 uh the best way to identify web application vulnerabilities uh that are 0:28:30.100000 --> 0:28:34.800000 native to the application server is when the classification of the vulnerability 0:28:34.800000 --> 0:28:41.520000 um or sort of the impact is just stated as RCE so whenever for example 0:28:41.520000 --> 0:28:48.360000 if you see let's say alexis web app RCE and not SQL injection or you know 0:28:48.360000 --> 0:28:53.300000 um something else then you know it's dealing with the application server 0:28:53.300000 --> 0:28:59.540000 or again generally speaking it's the it's it's referring to that um anyway 0:28:59.540000 --> 0:29:05.600000 i now created this really cool or at least i think you know i consider 0:29:05.600000 --> 0:29:12.960000 cool uh this this really cool visualization of the layers using the example 0:29:12.960000 --> 0:29:16.600000 of the of the ecommerce web application we explored in the previous video 0:29:16.600000 --> 0:29:21.400000 but diving a little bit deep by sort of outlining where specific vulnerabilities 0:29:21.400000 --> 0:29:26.100000 inherent native vulnerabilities are found or the layers they're found 0:29:26.100000 --> 0:29:30.920000 in so the core what we're covering in this course is going to be focused 0:29:30.920000 --> 0:29:36.280000 on the application server layer all right and that's why it's highlighted 0:29:36.280000 --> 0:29:41.200000 in red SSRF insecure deserialization broken access control we're really 0:29:41.200000 --> 0:29:47.120000 focusing on SSRF and in and insecure deserialization uh if we take a look 0:29:47.120000 --> 0:29:50.860000 at the client layer now that you you actually have this complete picture 0:29:50.860000 --> 0:29:54.600000 it makes sense that you'd find you know cross-site scripting insecure 0:29:54.600000 --> 0:29:59.980000 client storage etc web server layer as we just explored a few seconds 0:29:59.980000 --> 0:30:05.140000 ago or i think a minute ago directory traversal response splitting misconfigured 0:30:05.140000 --> 0:30:14.420000 uh SSL TLS certs um i've already covered the application um server layer 0:30:14.420000 --> 0:30:18.700000 of vulnerabilities if we take a look at the database layer we have SQL 0:30:18.700000 --> 0:30:23.820000 injection uh not LDAP injection but you know uh that would be the internal 0:30:23.820000 --> 0:30:27.780000 service layer but you get the idea what we covered in the injection attacks 0:30:27.780000 --> 0:30:33.220000 course you know if it's a relational database it would be SQL injection 0:30:33.220000 --> 0:30:40.960000 if it's a no SQL database it would be uh no SQL injection um and uh yeah 0:30:40.960000 --> 0:30:46.860000 so by the way by the way in case you're wondering if you remember in the 0:30:46.860000 --> 0:30:51.920000 advanced injection at um in the advanced injection attacks course when 0:30:51.920000 --> 0:30:56.940000 we were speaking about ORM injection ORM would be considered middleware 0:30:56.940000 --> 0:31:02.600000 so it would either fall in the application server layer typically um as 0:31:02.600000 --> 0:31:06.940000 a sort of another component uh but still in that layer and its job if 0:31:06.940000 --> 0:31:11.480000 you remember was to facilitate communication between the application server 0:31:11.480000 --> 0:31:18.700000 or the back end if you will and the date so and the the the database layer 0:31:18.700000 --> 0:31:23.120000 um so hopefully it's all starting to come together and then of course 0:31:23.120000 --> 0:31:30.100000 we have the um API layer where you have um you know BOLA um which i have 0:31:30.100000 --> 0:31:37.160000 already explained data exposure insecure uh you know uh data exposure 0:31:37.160000 --> 0:31:42.280000 a lack of rate limiting I don't need to list out the whole list but hopefully 0:31:42.280000 --> 0:31:47.020000 you're starting to get the idea and then of course in the internal services 0:31:47.020000 --> 0:31:50.980000 layer which would deal with authentication generally or at least in the 0:31:50.980000 --> 0:31:55.060000 case of this example the email notification service you'd have vulnerabilities 0:31:55.060000 --> 0:32:00.360000 like you know API key mismanagement uh fairly common and then queue injection 0:32:00.360000 --> 0:32:06.020000 etc etc so in this case you can see again based on that example um that 0:32:06.020000 --> 0:32:11.260000 i introduced in the previous video sort of outlining this um this fictitious 0:32:11.260000 --> 0:32:15.160000 web application that is uh built using the layered architecture model 0:32:15.160000 --> 0:32:19.980000 you can see that uh right over here we have the web server nginx the application 0:32:19.980000 --> 0:32:26.200000 server is using python the python uwsti um application server but this 0:32:26.200000 --> 0:32:29.600000 is where you'd have vulnerabilities like insecure deserialization which 0:32:29.600000 --> 0:32:34.360000 um would affect you know the data uh can affect the database layer the 0:32:34.360000 --> 0:32:38.500000 authentication uh service as well as in this case the email notification 0:32:38.500000 --> 0:32:44.780000 service uh SSRF can also you know give you access to a lot more than what 0:32:44.780000 --> 0:32:50.340000 i've just listed out here but in this example the API layer um so there 0:32:50.340000 --> 0:32:55.000000 you are hopefully it's all come together now as a complete picture and 0:32:55.000000 --> 0:33:00.380000 now that we have this um complete or holistic understanding of where everything 0:33:00.380000 --> 0:33:06.040000 falls you know in modern web applications how they're designed or what 0:33:06.040000 --> 0:33:13.080000 type of structure uh they follow or they're built on if if if that makes 0:33:13.080000 --> 0:33:16.900000 sense of course i know i've relied on the layered architecture model quite 0:33:16.900000 --> 0:33:22.280000 a bit but again if you explore microservices and some of the other architecture 0:33:22.280000 --> 0:33:25.620000 models it's fairly simple there's always going to be this distinction 0:33:25.620000 --> 0:33:31.720000 between layers and the applications um the application server layer generally 0:33:31.720000 --> 0:33:36.540000 speaking even in the case of microservices uh you know what ends up happening 0:33:36.540000 --> 0:33:41.420000 in that architecture model is that specific functions that let's say uh 0:33:41.420000 --> 0:33:46.240000 you know previously a core the the back end of the web application would 0:33:46.240000 --> 0:33:51.800000 do in sort of a monolithic fashion is now broken up into separate uh let's 0:33:51.800000 --> 0:33:56.020000 say containers that do different things like handle authentication handle 0:33:56.020000 --> 0:34:00.700000 uh the the the cart checkouts the payment gateway stuff is but they're 0:34:00.700000 --> 0:34:05.780000 all running you know in the same layer the web server is different uh 0:34:05.780000 --> 0:34:09.600000 the client side again all the presentation layers treated differently 0:34:09.600000 --> 0:34:14.620000 the APIs have their own layer and hopefully it all makes sense anyway 0:34:14.620000 --> 0:34:18.800000 um with that being said that brings us to the end of this video and now 0:34:18.800000 --> 0:34:24.220000 that we have this uh you know very good um foundation to work from we 0:34:24.220000 --> 0:34:30.280000 can begin exploring the first um server side vulnerability or attack and 0:34:30.280000 --> 0:34:34.660000 that's obviously going to involve server side request forgery so with 0:34:34.660000 --> 0:34:37.540000 that being said that's going to be it for this video and i'll be seeing