WEBVTT 0:00:02.320000 --> 0:00:07.040000 The web application penetration testing lifecycle. 0:00:07.040000 --> 0:00:11.880000 And the objective for this section is to now introduce you to the actual 0:00:11.880000 --> 0:00:16.560000 web application penetration testing process or lifecycle. 0:00:16.560000 --> 0:00:22.540000 And what that will entail will be to firstly get an understanding of the 0:00:22.540000 --> 0:00:27.660000 web application penetration testing methodology, the generalized one, 0:00:27.660000 --> 0:00:32.960000 and we'll be taking a look at a couple of commonly used or industry standard 0:00:32.960000 --> 0:00:36.900000 web application penetration testing methodologies. 0:00:36.900000 --> 0:00:42.500000 Once we have an understanding of the actual methodologies used, you'll 0:00:42.500000 --> 0:00:47.720000 soon learn that it is not, there isn't a standardized format that you 0:00:47.720000 --> 0:00:52.540000 should use or that you are required to use, although it is always a good 0:00:52.540000 --> 0:00:57.540000 practice to be aware of these methodologies and to essentially use them 0:00:57.540000 --> 0:01:02.280000 as resources to ensure that your web application penetration tests or 0:01:02.280000 --> 0:01:07.000000 your web application security tests are as thorough as possible. 0:01:07.000000 --> 0:01:11.500000 Once we've taken a look at the general methodologies, we're going to turn 0:01:11.500000 --> 0:01:14.040000 our attention to some specific methodologies. 0:01:14.040000 --> 0:01:18.580000 And we'll do that by introducing ourselves to the OASP top 10 list of 0:01:18.580000 --> 0:01:22.060000 vulnerabilities, and I'll explain why this is important. 0:01:22.060000 --> 0:01:27.020000 And as part of that, we're also going to be exploring the OASP web security 0:01:27.020000 --> 0:01:31.600000 testing guide and checklist, and we'll be exploring how we can use that 0:01:31.600000 --> 0:01:38.720000 as web application penetration testers to help organize structure, orchestrate, 0:01:38.720000 --> 0:01:43.700000 and track our web application security tests or web application penetration 0:01:43.700000 --> 0:01:49.820000 tests so that our web app pen tests are as thorough and as efficient as 0:01:49.820000 --> 0:01:54.840000 possible. We will then end off this section by taking a look at the re 0:01:54.840000 --> 0:01:59.940000 -engagement phase of a web application penetration test, and we'll close 0:01:59.940000 --> 0:02:05.740000 up the section finally with the final video being on documentation and 0:02:05.740000 --> 0:02:11.580000 reporting or the process of documenting your findings and how to appropriately 0:02:11.580000 --> 0:02:17.500000 report them in preparation for the final report, which is to be sent to 0:02:17.500000 --> 0:02:21.380000 the client you're performing the web application penetration test for. 0:02:21.380000 --> 0:02:25.500000 And this will apply as well if you are a bug bounty hunter. 0:02:25.500000 --> 0:02:30.380000 The report structure changes slightly, but overall, the information communicated 0:02:30.380000 --> 0:02:33.680000 within it remains generally speaking the same. 0:02:33.680000 --> 0:02:39.460000 So with that being said, let's get started by taking a look at the general 0:02:39.460000 --> 0:02:44.320000 web application penetration testing methodology, and more importantly, 0:02:44.320000 --> 0:02:48.780000 we'll get an understanding as to why we require a methodology when performing 0:02:48.780000 --> 0:02:52.760000 any form of security engagement and why it's useful. 0:02:52.760000 --> 0:02:58.020000 So to kick things off, let's revisit what web app pen testing is. 0:02:58.020000 --> 0:03:03.440000 And again, there should be no, there should be no confusion as to why 0:03:03.440000 --> 0:03:06.920000 we're focusing on web app pen testing over web app security testing. 0:03:06.920000 --> 0:03:09.920000 If you remember, I explained the difference. 0:03:09.920000 --> 0:03:14.280000 We're primarily interested in web app pen testing as a process or as a 0:03:14.280000 --> 0:03:17.460000 subset of web application security testing. 0:03:17.460000 --> 0:03:22.120000 So web application penetration testing is a comprehensive security assessment 0:03:22.120000 --> 0:03:27.420000 that is aimed at identifying vulnerabilities and weaknesses in web applications 0:03:27.420000 --> 0:03:33.900000 and also verifying the actual risk posed by these vulnerabilities by attempting 0:03:33.900000 --> 0:03:39.080000 to exploit the vulnerabilities to verify and to essentially come up with 0:03:39.080000 --> 0:03:44.080000 a risk or to assign a risk to a particular vulnerability or misconfiguration. 0:03:44.080000 --> 0:03:48.820000 And it works by trying to simulate real world attacks and evaluating the 0:03:48.820000 --> 0:03:53.180000 web application security posture and then providing recommendations for 0:03:53.180000 --> 0:03:57.960000 remediation based on the results of the actual web app pen testing process, 0:03:57.960000 --> 0:04:02.720000 which as I said, involves identification and exploitation of misconfigurations 0:04:02.720000 --> 0:04:03.880000 or vulnerabilities. 0:04:03.880000 --> 0:04:12.000000 Now, why do we need to use or why is it generally good practice or best 0:04:12.000000 --> 0:04:15.400000 practice to utilize a methodology? 0:04:15.400000 --> 0:04:20.240000 Well, using a methodology for web application penetration testing is vitally 0:04:20.240000 --> 0:04:24.760000 important as it provides a structured and systematic approach to conduct 0:04:24.760000 --> 0:04:26.480000 thorough security assessments. 0:04:26.480000 --> 0:04:29.000000 And again, why is this important? 0:04:29.000000 --> 0:04:33.700000 Well, for two primary reasons based on my own experience, especially when 0:04:33.700000 --> 0:04:37.760000 dealing with web application penetration testing, what you'll soon find 0:04:37.760000 --> 0:04:42.060000 is regardless of the scope of what you've been asked to assess. 0:04:42.060000 --> 0:04:46.800000 So for example, you know, maybe one or two domains, you need to be wary 0:04:46.800000 --> 0:04:51.040000 of the fact that a web application is very large in terms of its attack 0:04:51.040000 --> 0:04:56.000000 surface. And what that means as a web app pen tester is that there are 0:04:56.000000 --> 0:04:58.960000 a lot of tests that you need to perform. 0:04:58.960000 --> 0:05:05.040000 And when you do not follow a, you know, a very detailed methodology that 0:05:05.040000 --> 0:05:10.120000 at least attempts to provide you with guidance on, you know, some of the 0:05:10.120000 --> 0:05:14.840000 most common vectors you should try and test first, or, you know, some 0:05:14.840000 --> 0:05:18.640000 of the most common tests you should run first, what you'll end up finding 0:05:18.640000 --> 0:05:23.400000 is that your web application penetration tests are not that thorough or 0:05:23.400000 --> 0:05:28.080000 comprehensive. So that's the first reason in terms of, you know, generally 0:05:28.080000 --> 0:05:32.320000 speaking, how much you're being exposed to and even more so in this particular 0:05:32.320000 --> 0:05:36.380000 case or in the case of web app pen testing, when compared to standard 0:05:36.380000 --> 0:05:40.900000 network pen testing, you'll find that the amount of attacks or the amount 0:05:40.900000 --> 0:05:44.480000 of tests you can perform are quite large in number. 0:05:44.480000 --> 0:05:48.640000 But if you utilize a methodology that sorts everything out and maybe even 0:05:48.640000 --> 0:05:52.780000 categorizes it based on, you know, what aspect of the web application 0:05:52.780000 --> 0:05:57.460000 you're testing or what functionality you're testing, it'll be much easier 0:05:57.460000 --> 0:06:02.140000 even as we get into the actual reporting, which brings me to the second 0:06:02.140000 --> 0:06:05.900000 reason why using a methodology is important. 0:06:05.900000 --> 0:06:11.100000 And that is to firstly establish a good sense or a good understanding 0:06:11.100000 --> 0:06:17.140000 as to, you know, what you typically need to do when dealing with a certain 0:06:17.140000 --> 0:06:18.480000 type of web application. 0:06:18.480000 --> 0:06:23.040000 So essentially building your own internal methodology with regards to 0:06:23.040000 --> 0:06:26.420000 streamlining your approach because the first time you do a web app pen 0:06:26.420000 --> 0:06:28.900000 test, you're going to be inefficient. 0:06:28.900000 --> 0:06:33.720000 And this experience or your tacit or intuitive understanding of what needs 0:06:33.720000 --> 0:06:38.740000 to be done first will only come through the, you know, through free performing 0:06:38.740000 --> 0:06:40.380000 frequent web app pen tests. 0:06:40.380000 --> 0:06:45.160000 And secondly, also getting exposure to multiple, you know, web applications 0:06:45.160000 --> 0:06:50.740000 and a good way of doing this I've seen for students or juniors is to utilize 0:06:50.740000 --> 0:06:55.100000 a methodology like the ones I'm going to be highlighting like the OS, 0:06:55.100000 --> 0:06:56.580000 web security testing guide. 0:06:56.580000 --> 0:07:00.800000 Because what they learn is that this, their understanding of what could 0:07:00.800000 --> 0:07:03.940000 be tested is so, was so limited. 0:07:03.940000 --> 0:07:08.240000 And when they got their hands on the OSB web security testing guide and 0:07:08.240000 --> 0:07:12.980000 checklist, they were blown away by how much they had missed previously 0:07:12.980000 --> 0:07:16.040000 in terms of the tests that they could have performed. 0:07:16.040000 --> 0:07:20.220000 So it goes without saying that, you know, the actual methodology you use 0:07:20.220000 --> 0:07:21.400000 is very important. 0:07:21.400000 --> 0:07:24.860000 And that brings me now to the actual importance as which I can sort of 0:07:24.860000 --> 0:07:29.080000 break down. And I think it is important and that's why I've added them 0:07:29.080000 --> 0:07:33.660000 in the slide. So firstly, we have consistency and standardization. 0:07:33.660000 --> 0:07:37.560000 This is very, very important, especially within an organization. 0:07:37.560000 --> 0:07:41.240000 And this is something your client will be able to tell or your clients 0:07:41.240000 --> 0:07:48.280000 will be able to tell, you know, the longer you keep performing web app 0:07:48.280000 --> 0:07:51.040000 pen tests if they are not being able to be able to tell. 0:07:51.040000 --> 0:07:53.520000 So you know, you're consistent with regards to how they are structured 0:07:53.520000 --> 0:07:58.660000 and the tools used and the methodologies used and you know, they may not 0:07:58.660000 --> 0:08:02.960000 be reported in a consistent way or in a standardized way. 0:08:02.960000 --> 0:08:06.000000 You know, that indicates that, you know, while you may have performed, 0:08:06.000000 --> 0:08:10.880000 let's say, a good security assessment, you know, you cannot be relied 0:08:10.880000 --> 0:08:21.020000 on primarily because of the ad hoc mentality you are proceeding in. 0:08:21.020000 --> 0:08:25.940000 Or the red teaming side of things where you're not really limited to a 0:08:25.940000 --> 0:08:29.840000 methodology. But even in that case, if you are performing adverse emulation 0:08:29.840000 --> 0:08:35.580000 and the adversary emulation campaign involves, involves attacking a web 0:08:35.580000 --> 0:08:41.320000 application, you'll typically adapt the attack to match the actual attack 0:08:41.320000 --> 0:08:45.620000 flow and the TTPs of the threat actor you're trying to emulate. 0:08:45.620000 --> 0:08:49.080000 So even in that case, you're down to using a methodology. 0:08:49.080000 --> 0:08:52.960000 So in essence, a methodology ensures that penetration tests are performed 0:08:52.960000 --> 0:08:56.060000 consistently across different web applications and projects. 0:08:56.060000 --> 0:09:00.100000 It provides standardized procedures, tools and techniques, ensuring that 0:09:00.100000 --> 0:09:04.940000 all necessary areas of the application security are thoroughly tested. 0:09:04.940000 --> 0:09:08.440000 You then have comprehensive coverage, which is very important. 0:09:08.440000 --> 0:09:12.700000 So a well-defined methodology helps ensure comprehensive coverage of the 0:09:12.700000 --> 0:09:14.120000 web application security. 0:09:14.120000 --> 0:09:18.820000 It guides testers to assess all critical components and functionalities, 0:09:18.820000 --> 0:09:23.120000 reducing the risk of overlooking crucial security flaws, which is something 0:09:23.120000 --> 0:09:26.060000 you find over and over again. 0:09:26.060000 --> 0:09:29.460000 So again, no, I'm not disseminating the use of your own methodology. 0:09:29.460000 --> 0:09:34.480000 But if they are established ones, especially like the one I pointed out, 0:09:34.480000 --> 0:09:40.200000 the WSTG or OS PoEB security testing guide, and you choose to use your 0:09:40.200000 --> 0:09:43.660000 own and you miss out on tests that you could have performed if you are 0:09:43.660000 --> 0:09:43.840000 following the test. 0:09:43.840000 --> 0:09:50.120000 If you are following even lightly the WSTG guide or checklist, then at 0:09:50.120000 --> 0:09:54.040000 that point, that is a form of irresponsibility. 0:09:54.040000 --> 0:09:58.500000 The point I'm trying to make is take a look at these methodologies. 0:09:58.500000 --> 0:10:02.040000 You can also use them or adapt them to your own liking as I'll show you 0:10:02.040000 --> 0:10:03.380000 as we proceed in this section. 0:10:03.380000 --> 0:10:07.860000 But it's very important that you never or you rarely miss out on some 0:10:07.860000 --> 0:10:13.900000 crucial tests that could reveal security flaws or misconfigurations. 0:10:13.900000 --> 0:10:18.120000 Thirdly, we have efficiency and time management. 0:10:18.120000 --> 0:10:23.280000 So this obviously makes sense and is sort of self-explanatory, but following 0:10:23.280000 --> 0:10:28.280000 a methodology streamlines the testing process, making it more efficient 0:10:28.280000 --> 0:10:29.720000 and time effective. 0:10:29.720000 --> 0:10:33.120000 What that means is that testers can prioritize tasks. 0:10:33.120000 --> 0:10:36.980000 They can focus on high risk areas and avoid wasting time on redundant 0:10:36.980000 --> 0:10:41.460000 activities. And another reason for this with regards to efficiency and 0:10:41.460000 --> 0:10:47.240000 time management is that delegation can be performed even more effectively 0:10:47.240000 --> 0:10:52.220000 because now if you're using a methodology that has proper categorization, 0:10:52.220000 --> 0:10:56.880000 let's say, of types of vulnerabilities or of specific tests related to 0:10:56.880000 --> 0:11:01.800000 functionality of a web application, what you can do is if you have a large 0:11:01.800000 --> 0:11:06.960000 team or a team of more than two web app testers, what you can do is delegate 0:11:06.960000 --> 0:11:10.580000 different categories of tests to them. 0:11:10.580000 --> 0:11:15.960000 And what that does is it gives the team an understanding as to where each 0:11:15.960000 --> 0:11:20.900000 team members' roles and responsibilities begin with regards to the tests 0:11:20.900000 --> 0:11:23.220000 that they should be running and where they end. 0:11:23.220000 --> 0:11:28.280000 And at that point, you can also extrapolate from that that the reporting 0:11:28.280000 --> 0:11:32.600000 becomes much easier to organize because you can just ask team member to 0:11:32.600000 --> 0:11:42.600000 provide you with the documentation and the logs that they have after performing 0:11:42.600000 --> 0:11:50.120000 a certain number of tests or after performing a particular test or checking 0:11:50.120000 --> 0:11:53.300000 for specific vulnerabilities. 0:11:53.300000 --> 0:11:58.480000 You then have, of course, the other aspects which are the thorough identification 0:11:58.480000 --> 0:12:00.480000 of vulnerabilities. 0:12:00.480000 --> 0:12:04.760000 So a methodology encourages detailed testing and comprehensive assessments, 0:12:04.760000 --> 0:12:08.440000 and it helps testers identify both common and rare vulnerabilities, which 0:12:08.440000 --> 0:12:13.360000 is something you'll see once I expose you to the WS-DG. 0:12:13.360000 --> 0:12:18.320000 So improving the overall security posture of the web application. 0:12:18.320000 --> 0:12:21.580000 And we obviously have risk prioritization. 0:12:21.580000 --> 0:12:25.060000 So what this means is that a methodology allows testers to assign risk 0:12:25.060000 --> 0:12:30.140000 levels to identified vulnerabilities based on their potential impact on 0:12:30.140000 --> 0:12:31.840000 the application and business. 0:12:31.840000 --> 0:12:37.160000 And this is typically found or put into the report, and this will eventually 0:12:37.160000 --> 0:12:41.680000 assist stakeholders in prioritizing and addressing critical issues first. 0:12:41.680000 --> 0:12:47.140000 So the key point is that if you're performing a web app test and you don't 0:12:47.140000 --> 0:12:52.440000 have a methodology and you do not know how to essentially calculate the 0:12:52.440000 --> 0:12:57.780000 risk posed by a misconfiguration security flaw or vulnerability, you'll 0:12:57.780000 --> 0:13:03.120000 not know whether or not or how to communicate this to the actual client. 0:13:03.120000 --> 0:13:08.900000 And this is something that is the actual risk and the risk you calculate 0:13:08.900000 --> 0:13:12.320000 or the risk you assign to a vulnerability that you find as a web app pen 0:13:12.320000 --> 0:13:16.420000 tester is what the client is paying you to do, because they need to know 0:13:16.420000 --> 0:13:19.220000 firstly whether vulnerabilities exist. 0:13:19.220000 --> 0:13:25.260000 And secondly, what are the risks associated with that vulnerability? 0:13:25.260000 --> 0:13:29.440000 And more importantly, that will help them understand what they need to 0:13:29.440000 --> 0:13:32.920000 patch first or what they need to fix first based on vulnerabilities that 0:13:32.920000 --> 0:13:37.900000 have a high risk or a high score. 0:13:37.900000 --> 0:13:40.760000 And then of course, that ties into what I was just saying, which is effective 0:13:40.760000 --> 0:13:42.560000 reporting and communication. 0:13:42.560000 --> 0:13:46.560000 So a structured methodology encourages well documented reports that are 0:13:46.560000 --> 0:13:51.220000 easy to understand for both technical and non-technical stakeholders, 0:13:51.220000 --> 0:13:56.260000 clear communication of findings, and recommendations is vital for remediation 0:13:56.260000 --> 0:13:59.000000 efforts from the client's perspective. 0:13:59.000000 --> 0:14:03.240000 And then of course, we have a couple of other, you know, important things 0:14:03.240000 --> 0:14:07.200000 that we can assign to using methodologies, but for example, you know, 0:14:07.200000 --> 0:14:09.080000 industry standards in best practices. 0:14:09.080000 --> 0:14:12.480000 So many methodologies are based on industry standards in best practices, 0:14:12.480000 --> 0:14:16.860000 such as those provided by organizations like OASP and NIST, following 0:14:16.860000 --> 0:14:20.800000 established guidelines ensures a comprehensive and relevant assessment. 0:14:20.800000 --> 0:14:24.540000 What this means is that in certain cases, you may be tasked with performing 0:14:24.540000 --> 0:14:29.680000 a pen test or a web app pen test for an organization that needs to be, 0:14:29.680000 --> 0:14:36.840000 or that is essentially requires or at the present moment in time is compliant 0:14:36.840000 --> 0:14:41.600000 with specific compliance standards or industry standards, if you will. 0:14:41.600000 --> 0:14:45.520000 And what that means is, for example, let's say you're performing, you 0:14:45.520000 --> 0:14:52.400000 know, a web app pen test on a web application that is used by, let's say, 0:14:52.400000 --> 0:14:53.540000 a medical institution. 0:14:53.540000 --> 0:14:59.420000 In that case, they may, they probably are in alignment with the hyper 0:14:59.420000 --> 0:15:01.460000 compliance standard. 0:15:01.460000 --> 0:15:07.480000 And what that means is that from a web app pen testers perspective, you 0:15:07.480000 --> 0:15:10.460000 can at that point only perform certain tests. 0:15:10.460000 --> 0:15:15.480000 So you need to also structure your actual assessment in alignment with 0:15:15.480000 --> 0:15:19.780000 that, that compliance standard and what that compliance standard entails 0:15:19.780000 --> 0:15:23.700000 with regards to the effects it'll have on your on your web app pen test. 0:15:23.700000 --> 0:15:26.940000 And that's one of the reasons why, you know, for example, in penetration 0:15:26.940000 --> 0:15:32.500000 testing, there is use of the penetration testing execution standard, which 0:15:32.500000 --> 0:15:37.260000 dives deeper into how to structure your web app pen test if you're performing 0:15:37.260000 --> 0:15:41.200000 or how to structure your pen test if you're performing a pen test for 0:15:41.200000 --> 0:15:47.620000 a client that, you know, stores, for example, customer, financial information, 0:15:47.620000 --> 0:15:50.680000 stuff like that, because that is important. 0:15:50.680000 --> 0:15:52.580000 You then have legal and ethical compliance. 0:15:52.580000 --> 0:15:56.280000 So methodology helps ensure that penetration testing is conducted in an 0:15:56.280000 --> 0:16:00.920000 ethical and lawful manner, respecting the rules of engagement and gaining 0:16:00.920000 --> 0:16:04.320000 proper authorization from the target organization. 0:16:04.320000 --> 0:16:06.220000 And that, of course, makes sense. 0:16:06.220000 --> 0:16:10.960000 If you treat what what you'll typically see happening is regardless of 0:16:10.960000 --> 0:16:15.680000 the actual scope agreed on with the client, or even a scope defined, you 0:16:15.680000 --> 0:16:20.380000 know, for a bug bounty, you know, for a particular bug bounty program, 0:16:20.380000 --> 0:16:24.840000 you'll typically see that unless it, you know, even if it's explicitly 0:16:24.840000 --> 0:16:29.220000 stated, some pen testers, especially if your juniors or unexperienced 0:16:29.220000 --> 0:16:34.280000 are unaware of the fact that, you know, some tests are limited or can 0:16:34.280000 --> 0:16:38.280000 be limited, you know, to the actual scope. 0:16:38.280000 --> 0:16:43.020000 And that particular scope is not just in place because of, you know, for 0:16:43.020000 --> 0:16:49.100000 the organization wants to limit the test to just those domains, but it 0:16:49.100000 --> 0:16:53.500000 could also be for a plethora of other reasons, you know, that have to 0:16:53.500000 --> 0:16:59.040000 do with certain certain jurisdictions, or the fact that they store certain 0:16:59.040000 --> 0:17:04.600000 types of data. And the point that I'm trying to make here is that it firstly 0:17:04.600000 --> 0:17:10.420000 within your pen testing team or individually will help you get a better 0:17:10.420000 --> 0:17:15.440000 grasp of the legalities and the ethics involved in performing a pen test 0:17:15.440000 --> 0:17:18.620000 in general, but also a web application penetration test. 0:17:18.620000 --> 0:17:23.540000 And the fact that if you are to do anything, you need to get written agreement 0:17:23.540000 --> 0:17:27.600000 and authorization from the client before you start anything because you 0:17:27.600000 --> 0:17:32.980000 could be legally culpable if you do not abide by those, you know, by those 0:17:32.980000 --> 0:17:36.520000 standards and those standards can only be found in well established and 0:17:36.520000 --> 0:17:40.420000 adopted methodologies or frameworks. 0:17:40.420000 --> 0:17:45.080000 And then of course, we have the other importance, which is pretty cool, 0:17:45.080000 --> 0:17:48.980000 I would say, and you'll actually see yourself once I expose you to the 0:17:48.980000 --> 0:17:50.740000 methodology, you'll actually see this. 0:17:50.740000 --> 0:17:53.920000 So that is the detection of complex vulnerability. 0:17:53.920000 --> 0:17:57.680000 So advanced security vulnerabilities often require a structured approach 0:17:57.680000 --> 0:17:59.400000 in order to be identified. 0:17:59.400000 --> 0:18:04.160000 What that means is that in certain cases, you may only discover a vulnerability 0:18:04.160000 --> 0:18:08.900000 in a web application after the discovery of a previous misconfiguration 0:18:08.900000 --> 0:18:12.420000 in that you sort of need to chain vulnerabilities, right? 0:18:12.420000 --> 0:18:17.720000 Or a vulnerability only discloses itself or becomes apparent because of 0:18:17.720000 --> 0:18:19.620000 a security misconfiguration. 0:18:19.620000 --> 0:18:23.860000 And that can only happen if you're following a structured methodology 0:18:23.860000 --> 0:18:28.400000 that will allow you to, you know, reference or will essentially point 0:18:28.400000 --> 0:18:31.700000 towards a reference that, you know, this may have led to this. 0:18:31.700000 --> 0:18:37.300000 And that's why you're seeing this now instead of, you know, instead of 0:18:37.300000 --> 0:18:39.380000 why you weren't able to see it previously. 0:18:39.380000 --> 0:18:41.100000 And that's just a very basic example. 0:18:41.100000 --> 0:18:44.900000 But, you know, methodology enables testers to apply specialized techniques 0:18:44.900000 --> 0:18:48.720000 and tools to detect complex vulnerabilities that might be missed in ad 0:18:48.720000 --> 0:18:55.860000 hoc testing. And that also applies to environments that are running specific 0:18:55.860000 --> 0:18:59.860000 technologies or environments that are configured in a certain way. 0:18:59.860000 --> 0:19:03.760000 If you are unaware of, you know, the nuances in terms of, you know, web 0:19:03.760000 --> 0:19:06.860000 application architecture, you may miss out on this. 0:19:06.860000 --> 0:19:12.040000 So, for example, usually say this with junior pen testers or junior web 0:19:12.040000 --> 0:19:16.800000 app pen testers is they'll test a site for SQL injection or an input, 0:19:16.800000 --> 0:19:21.620000 an application input for SQL injection, but do not try and perform no 0:19:21.620000 --> 0:19:26.740000 SQL injection, essentially meaning that they do not know or are not aware 0:19:26.740000 --> 0:19:32.040000 of the fact that no SQL databases exist or in memory databases exist. 0:19:32.040000 --> 0:19:37.780000 They're just assuming that the web application is using a relational database. 0:19:37.780000 --> 0:19:41.480000 And the use of a methodology, as I pointed out earlier, will introduce 0:19:41.480000 --> 0:19:47.100000 you to these other technologies or architecture specific nuances that 0:19:47.100000 --> 0:19:53.880000 you previously weren't aware of. 0:19:53.880000 --> 0:19:57.420000 So, eventually lead you to become a much more comprehensive or and thorough 0:19:57.420000 --> 0:20:01.820000 penetration tester, but also allow you to detect much more complex vulnerabilities 0:20:01.820000 --> 0:20:06.080000 that are very sensitive with regards to how they can be found, or are 0:20:06.080000 --> 0:20:10.200000 very difficult to find, you know, through ad hoc testing, just given the 0:20:10.200000 --> 0:20:11.800000 nature of ad hoc testing in general. 0:20:11.800000 --> 0:20:17.840000 So, what is a web application penetration testing methodology? 0:20:17.840000 --> 0:20:21.360000 Now that we've got the importance is what is it? 0:20:21.360000 --> 0:20:25.360000 Well, a web application penetration testing methodology is a structured 0:20:25.360000 --> 0:20:30.680000 and systematic approach to conducting security assessments of web applications. 0:20:30.680000 --> 0:20:35.100000 It helps you identify potential vulnerabilities and weaknesses, assesses 0:20:35.100000 --> 0:20:38.860000 the application security posture and provides actionable recommendations 0:20:38.860000 --> 0:20:40.260000 for remediation. 0:20:40.260000 --> 0:20:44.920000 While specific methodologies may vary, the following steps commonly included 0:20:44.920000 --> 0:20:49.980000 in a web application, the following are steps included, common steps included 0:20:49.980000 --> 0:20:53.360000 in a web application penetration testing methodology. 0:20:53.360000 --> 0:21:00.400000 So again, these are just the common steps that I have seen in my own experience. 0:21:00.400000 --> 0:21:03.000000 Of course, these are phases. 0:21:03.000000 --> 0:21:08.620000 I've gone over the objectives, but I'll be breaking them down as we proceed 0:21:08.620000 --> 0:21:12.520000 or progress within this section. 0:21:12.520000 --> 0:21:17.600000 So, generally speaking, a web app, a pen testing methodology will consist 0:21:17.600000 --> 0:21:19.240000 of the following phases. 0:21:19.240000 --> 0:21:22.940000 So, you'll typically start off with pre-engagement, where you'll define 0:21:22.940000 --> 0:21:26.160000 the scope and objectives of the penetration test, including the target 0:21:26.160000 --> 0:21:30.420000 web application, the URLs and the functionalities to be tested with the 0:21:30.420000 --> 0:21:35.820000 client. You'll also within this phase be required to obtain proper authorization 0:21:35.820000 --> 0:21:39.560000 and permission from the application owner or the client to conduct the 0:21:39.560000 --> 0:21:43.400000 test, and you'll be required to gather relevant information about the 0:21:43.400000 --> 0:21:48.240000 application such as the technology is used, user roles and business critical 0:21:48.240000 --> 0:21:48.800000 functionalities. 0:21:48.800000 --> 0:21:52.100000 This is all subject to what you agree on with the client. 0:21:52.100000 --> 0:21:55.780000 And the third point there with regards to pre-engagement refers to cases 0:21:55.780000 --> 0:22:01.040000 where you're performing a white box web app pen test, whereby you are 0:22:01.040000 --> 0:22:04.580000 going to be provided with information about the environment as opposed 0:22:04.580000 --> 0:22:10.320000 to a black box web app pen test where you're going in blind without any 0:22:10.320000 --> 0:22:16.700000 information about the web application beforehand. 0:22:16.700000 --> 0:22:22.040000 The next phase is typically information gathering and reconnaissance. 0:22:22.040000 --> 0:22:25.760000 This is where you perform passive reconnaissance to gather publicly available 0:22:25.760000 --> 0:22:29.560000 information about the application and its infrastructure. 0:22:29.560000 --> 0:22:33.980000 You enumerate subdomains, directories and files to discover hidden or 0:22:33.980000 --> 0:22:38.240000 sensitive content, and you can use tools like N-Map to identify open ports 0:22:38.240000 --> 0:22:40.340000 or services running on the web server. 0:22:40.340000 --> 0:22:44.520000 You can also utilize or you know will be required to utilize Google Docs 0:22:44.520000 --> 0:22:48.780000 to find indexed information, files and directories on the target website. 0:22:48.780000 --> 0:22:51.600000 And then of course you have threat modeling which is not always included 0:22:51.600000 --> 0:22:55.380000 but in certain cases you may need to analyze the application's architecture 0:22:55.380000 --> 0:22:59.600000 and data flow to identify potential threats and attack vectors. 0:22:59.600000 --> 0:23:02.900000 You'll also be required to build an attack service model to understand 0:23:02.900000 --> 0:23:06.100000 how attackers can interact with the application and what the constraints 0:23:06.100000 --> 0:23:11.660000 are. You'll also identify potential high risk areas and prioritize testing 0:23:11.660000 --> 0:23:12.920000 efforts accordingly. 0:23:12.920000 --> 0:23:17.360000 So this is just taking the info or the intelligence gathered from the 0:23:17.360000 --> 0:23:22.620000 recon phase into consideration and then laying it out or mapping out the 0:23:22.620000 --> 0:23:27.520000 web application, analyzing how it works based on the info you gathered, 0:23:27.520000 --> 0:23:31.420000 building the attack surface model based on the scope and also what you're 0:23:31.420000 --> 0:23:36.480000 able to find. And then based on your experience identify the high risk 0:23:36.480000 --> 0:23:42.060000 areas that you can start off with or the low hanging fruit if you will. 0:23:42.060000 --> 0:23:46.820000 You then have vulnerability scanning and this will involve the utilization 0:23:46.820000 --> 0:23:50.820000 of automated vulnerability scanners like Burp Suite or OASP ZAP which 0:23:50.820000 --> 0:23:54.460000 are really web proxies but they are third party web app vulnerability 0:23:54.460000 --> 0:24:01.100000 scanners. But ZAP and Burp Suite are typically used because of the flexibility 0:24:01.100000 --> 0:24:06.040000 that they offer and the robust features that they offer in terms of how 0:24:06.040000 --> 0:24:11.720000 good or how useful they are in analyzing and testing web applications. 0:24:11.720000 --> 0:24:16.540000 And of course you can utilize Burp Suite or ZAP and you'll also be required 0:24:16.540000 --> 0:24:21.120000 or you typically will verify and validate the scan results manually to 0:24:21.120000 --> 0:24:23.100000 eliminate false positives and false negatives. 0:24:23.100000 --> 0:24:26.940000 So what that means is that after you've performed a vulnerability scan 0:24:26.940000 --> 0:24:31.200000 either using an automated third party scanner or even a semi automated 0:24:31.200000 --> 0:24:36.420000 web proxy like Burp Suite or ZAP, you then need to take a look at the 0:24:36.420000 --> 0:24:41.480000 scan results and then go through the findings and verify them manually 0:24:41.480000 --> 0:24:46.260000 to essentially validate that they do exist or to eliminate false positives 0:24:46.260000 --> 0:24:50.740000 and false negatives because vulnerability scanners are not perfect in 0:24:50.740000 --> 0:24:55.360000 that sense. You then have the manual testing and exploitation phase which 0:24:55.360000 --> 0:24:57.440000 again is self explanatory. 0:24:57.440000 --> 0:25:00.900000 It involves performing manual testing to validate and exploit identified 0:25:00.900000 --> 0:25:03.440000 vulnerabilities in the application. 0:25:03.440000 --> 0:25:08.680000 Testing for input validation issues, authentication bypasses, authorization 0:25:08.680000 --> 0:25:11.500000 flaws and business logic vulnerabilities. 0:25:11.500000 --> 0:25:17.340000 So you can think of SQL injection and of course LFI upload vulnerabilities 0:25:17.340000 --> 0:25:24.360000 and then the obvious objectivia is to attempt to exploit security flaws 0:25:24.360000 --> 0:25:28.720000 of vulnerabilities to demonstrate their impact and their potential risk 0:25:28.720000 --> 0:25:29.620000 to the web application. 0:25:29.620000 --> 0:25:33.100000 So that's really the most important aspect. 0:25:33.100000 --> 0:25:37.760000 And then of course you can break down individual aspects of functionality 0:25:37.760000 --> 0:25:41.900000 or you'll typically see this being done like authentication and authorization 0:25:41.900000 --> 0:25:47.120000 testing where you'll be typically, you know, will perform or test the 0:25:47.120000 --> 0:25:50.720000 applications, authentication mechanisms to identify weaknesses in password 0:25:50.720000 --> 0:25:54.380000 policies, session management and account lockout procedures. 0:25:54.380000 --> 0:25:59.680000 What this means is that if you're performing a web app and test on a web 0:25:59.680000 --> 0:26:04.320000 application that has authentication functionality like a login form, you'd 0:26:04.320000 --> 0:26:08.940000 essentially try and find weaknesses in it like does the verification email 0:26:08.940000 --> 0:26:12.740000 or the password reset email expire after a certain period of time. 0:26:12.740000 --> 0:26:16.680000 Is there a secure password policy implemented that prevents users from 0:26:16.680000 --> 0:26:20.660000 entering passwords with only four characters? 0:26:20.660000 --> 0:26:25.880000 You know, is there a feature that protects that authentication form against 0:26:25.880000 --> 0:26:27.480000 brute force attacks? 0:26:27.480000 --> 0:26:32.140000 Is there two factor authentication and you know elements like that? 0:26:32.140000 --> 0:26:35.840000 And then of course the other objective is to evaluate the applications 0:26:35.840000 --> 0:26:40.920000 access controls to ensure that unauthorized users cannot access sensitive 0:26:40.920000 --> 0:26:42.220000 functionalities or data. 0:26:42.220000 --> 0:26:48.560000 So just access control around resources, you know, that are running on 0:26:48.560000 --> 0:26:53.000000 the web server or that, you know, are essentially part of the web application 0:26:53.000000 --> 0:26:57.320000 themselves. You then have session management testing where you'll evaluate 0:26:57.320000 --> 0:27:00.820000 the application session management mechanisms to prevent session fixation 0:27:00.820000 --> 0:27:04.600000 session hijacking and session related attacks. 0:27:04.600000 --> 0:27:07.820000 And you'll also check for session timeout settings and proper session 0:27:07.820000 --> 0:27:11.800000 token handling. And then you have information disclosure. 0:27:11.800000 --> 0:27:14.920000 This is where you review how the application handles sensitive information 0:27:14.920000 --> 0:27:19.240000 such as passwords, user data and confidential files. 0:27:19.240000 --> 0:27:22.860000 And you'll also test for information disclosure through error messages, 0:27:22.860000 --> 0:27:27.680000 server responses or proper or improper access controls. 0:27:27.680000 --> 0:27:31.680000 And then of course finalizing everything you have business logic testing 0:27:31.680000 --> 0:27:35.920000 where you analyze the application's business logic to identify flaws that 0:27:35.920000 --> 0:27:38.540000 could lead to unauthorized access or data manipulation. 0:27:38.540000 --> 0:27:42.140000 And you'll test for order related vulnerabilities, privilege escalation 0:27:42.140000 --> 0:27:44.960000 and other business logic flaws. 0:27:44.960000 --> 0:27:49.060000 And again, this may not make much sense to you right now and that is understandable. 0:27:49.060000 --> 0:27:53.580000 And that's why I'm going over generalized methodology first. 0:27:53.580000 --> 0:27:56.540000 You'll typically see this type of methodology being implemented. 0:27:56.540000 --> 0:28:01.820000 But the problem as you can see is it still doesn't give you a set of tests 0:28:01.820000 --> 0:28:05.360000 that you can perform, for example, incline site testing. 0:28:05.360000 --> 0:28:09.440000 So let me just walk you through the remaining phases. 0:28:09.440000 --> 0:28:13.500000 So within client site testing, you'll evaluate client site code like HTML, 0:28:13.500000 --> 0:28:17.400000 JavaScript for potential security vulnerabilities such as, you know, DOM 0:28:17.400000 --> 0:28:19.260000 based cross site scripting. 0:28:19.260000 --> 0:28:22.720000 And you'll be required to test for insecure client storage and sensitive 0:28:22.720000 --> 0:28:28.140000 data exposure. And then of course you have the final, the actual final 0:28:28.140000 --> 0:28:32.120000 phases of our Web App Paint test, which involves reporting where you'll 0:28:32.120000 --> 0:28:35.420000 document and prioritize the identified security vulnerabilities. 0:28:35.420000 --> 0:28:39.460000 And risks. And you'll provide a detailed report to developers and stakeholders, 0:28:39.460000 --> 0:28:42.840000 including recommendations for remediation. 0:28:42.840000 --> 0:28:46.560000 You'll assist developers in fixing the identified security issues and 0:28:46.560000 --> 0:28:50.740000 retesting the application to ensure that the fixes were successful. 0:28:50.740000 --> 0:28:55.180000 And post engagement is sometimes included and sometimes not where you'll 0:28:55.180000 --> 0:28:58.880000 conduct a post engagement meeting to discuss the test results with the 0:28:58.880000 --> 0:29:03.600000 stakeholders. And you'll provide security awareness training to the development 0:29:03.600000 --> 0:29:07.980000 team to promote secure coding practices if you are contracted to do that 0:29:07.980000 --> 0:29:12.020000 by the client. So the point that I'm trying to make here is that that 0:29:12.020000 --> 0:29:13.340000 is a generalized methodology. 0:29:13.340000 --> 0:29:17.340000 And there are several web application penetration testing methodologies 0:29:17.340000 --> 0:29:22.260000 that security professionals and organizations can follow to conduct comprehensive 0:29:22.260000 --> 0:29:23.820000 and structured assessments. 0:29:23.820000 --> 0:29:27.740000 Now the key thing to note is that each methodology has its approach and 0:29:27.740000 --> 0:29:32.540000 focus areas. But they all share the common goal of identifying exploiting 0:29:32.540000 --> 0:29:36.900000 and even mitigating vulnerabilities in web applications. 0:29:36.900000 --> 0:29:40.360000 And here are some of the, you know, the popular or widely adopted web 0:29:40.360000 --> 0:29:43.120000 application penetration testing methodologies. 0:29:43.120000 --> 0:29:46.540000 Now the first one is the penetration testing execution standard. 0:29:46.540000 --> 0:29:49.460000 This one is not that common. 0:29:49.460000 --> 0:29:54.420000 The reason I added it in here is because in addition to, you know, primarily 0:29:54.420000 --> 0:29:59.200000 being a penetration testing methodology or framework, it really is thought 0:29:59.200000 --> 0:30:00.660000 of as a framework. 0:30:00.660000 --> 0:30:06.280000 You know, in addition to being one methodology used primarily for penetration 0:30:06.280000 --> 0:30:11.760000 testing in general, the reason I recommend it here is because it also 0:30:11.760000 --> 0:30:16.520000 has a methodology for web application methodologies. 0:30:16.520000 --> 0:30:22.780000 And then penetration testing specific method approaches or web application 0:30:22.780000 --> 0:30:24.760000 security assessments. 0:30:24.760000 --> 0:30:29.000000 And I'll actually demonstrate this to you shortly in with regards to how 0:30:29.000000 --> 0:30:32.880000 it works and where you can find documentation around it, but it provides 0:30:32.880000 --> 0:30:36.760000 a structured approach from pre engagement through reporting and follow 0:30:36.760000 --> 0:30:39.740000 up, making it suitable for comprehensive assessments. 0:30:39.740000 --> 0:30:43.960000 Right. And the abbreviation is typically referred to as in the industry 0:30:43.960000 --> 0:30:47.920000 as PTS and it is thought of as a framework. 0:30:47.920000 --> 0:30:50.900000 And the reason is thought of as a framework because it's gone beyond just 0:30:50.900000 --> 0:30:57.940000 a single, a single very specific approach and sort of adapts it to multiple 0:30:57.940000 --> 0:31:00.580000 forms of pen tests or security assessments. 0:31:00.580000 --> 0:31:05.400000 So for example, it has a methodology for performing pen tests on mobile 0:31:05.400000 --> 0:31:11.760000 applications or, you know, performing a pen test on cloud environments. 0:31:11.760000 --> 0:31:15.000000 And for that matter, it is very, very comprehensive. 0:31:15.000000 --> 0:31:18.860000 Now, I personally am not really a fan of the approach or the methodology 0:31:18.860000 --> 0:31:22.480000 that they recommend for web application penetration testing. 0:31:22.480000 --> 0:31:27.080000 And that's why I utilize and pretty much everyone I know utilize to a 0:31:27.080000 --> 0:31:32.060000 certain degree the OSB web security testing guide and checklist. 0:31:32.060000 --> 0:31:37.000000 All right. So the OSB web security testing guide also known as WSDG is 0:31:37.000000 --> 0:31:40.900000 a comprehensive resource provided by the open web application security 0:31:40.900000 --> 0:31:42.640000 project called OSB. 0:31:42.640000 --> 0:31:44.340000 You may be familiar with them. 0:31:44.340000 --> 0:31:47.640000 And it pretty much offers you a structured methodology. 0:31:47.640000 --> 0:31:51.820000 And I'll highlight that word there because you'll actually see how structured 0:31:51.820000 --> 0:31:55.960000 it is. It offers a structured methodology for performing web application 0:31:55.960000 --> 0:32:00.580000 security testing or even penetration testing if you adapt it. 0:32:00.580000 --> 0:32:03.960000 And I'll be walking you through it and how to use it and how I generally 0:32:03.960000 --> 0:32:06.060000 use it as we progress. 0:32:06.060000 --> 0:32:11.000000 With that being said, now that we have an understanding as to, you know, 0:32:11.000000 --> 0:32:15.740000 the importance of utilizing a methodology and the common web app pen testing 0:32:15.740000 --> 0:32:17.580000 methodology used and the phases of the web application. 0:32:17.580000 --> 0:32:19.620000 And then the process is contained within it. 0:32:19.620000 --> 0:32:27.820000 That typically that typically consists or comprise or exist within the 0:32:27.820000 --> 0:32:29.500000 actual methodology. 0:32:29.500000 --> 0:32:33.860000 And we've obviously explored the two primary methodologies I recommend. 0:32:33.860000 --> 0:32:39.520000 We can now move on to introducing you to the OSB the OSB top 10 list of 0:32:39.520000 --> 0:32:40.160000 vulnerabilities. 0:32:40.160000 --> 0:32:44.620000 And then after that, we'll go into the web security testing guide and 0:32:44.620000 --> 0:32:50.260000 I'll show you why we need to introduce the OSB top 10 list of vulnerabilities 0:32:50.260000 --> 0:32:56.140000 because within web application penetration testing reports, you'll typically 0:32:56.140000 --> 0:33:01.720000 see frequent references to OSB top 10 or even the web security testing 0:33:01.720000 --> 0:33:05.220000 guide. But with that being said, that's going to be it for this video 0:33:05.220000 --> 0:33:07.780000 and I will be seeing you in the next video.