WEBVTT 0:00:06.400000 --> 0:00:11.880000 So, now that we have an understanding of what authentication is, authorization 0:00:11.880000 --> 0:00:19.620000 is, and session management is, we can begin exploring the authentication 0:00:19.620000 --> 0:00:35.820000 testing methodology that we guide as to firstly, how to test web applications 0:00:35.820000 --> 0:00:44.840000 for authentication, session management vulnerabilities, and more importantly, 0:00:44.840000 --> 0:00:49.780000 the reason why I am actually recording this particular video is to provide 0:00:49.780000 --> 0:00:52.280000 you with this methodology. 0:00:52.280000 --> 0:00:59.540000 Now, if you have taken the EWT certification, you should be familiar with 0:00:59.540000 --> 0:01:06.440000 this because I introduced the OASP web security testing guide in that 0:01:06.440000 --> 0:01:12.340000 particular certification or within the courses within that certification. 0:01:12.340000 --> 0:01:17.880000 And the reason why I really like the web security testing guide is not 0:01:17.880000 --> 0:01:23.380000 because it's something that I like to adhere to very strictly, but it 0:01:23.380000 --> 0:01:29.340000 sort of always ensures that I'm performing checks for things that I would 0:01:29.340000 --> 0:01:32.020000 typically not test for. 0:01:32.020000 --> 0:01:38.180000 And given that this course is really focused on authentication attacks, 0:01:38.180000 --> 0:01:43.380000 widely speaking or broadly speaking, I think it's important that we actually 0:01:43.380000 --> 0:01:47.680000 approach this methodologically before we get into any attacks or perform 0:01:47.680000 --> 0:01:49.700000 any attacks practically. 0:01:49.700000 --> 0:01:55.640000 So, with that being said, I think we need to understand what authentication 0:01:55.640000 --> 0:02:02.740000 testing is. If you're a web app and test what authentication testing means 0:02:02.740000 --> 0:02:08.620000 is essentially testing for authentication specific vulnerabilities or 0:02:08.620000 --> 0:02:12.620000 vulnerabilities specific to the authentication mechanisms. 0:02:12.620000 --> 0:02:18.200000 So, formally speaking, authentication testing is the process of probing 0:02:18.200000 --> 0:02:22.960000 and exploiting weaknesses in a web application's identity verification 0:02:22.960000 --> 0:02:27.600000 mechanisms or the authentication mechanisms, whether that be a login form 0:02:27.600000 --> 0:02:33.100000 using the standard username and password combo, or one that has two-factor 0:02:33.100000 --> 0:02:36.200000 authentication tokens, etc. 0:02:36.200000 --> 0:02:40.760000 So, the bottom line is that this involves testing various authentication 0:02:40.760000 --> 0:02:46.840000 controls like login forms, the password reset functionality, multi-factor 0:02:46.840000 --> 0:02:51.480000 authentication and account lockouts to discover any vulnerabilities that 0:02:51.480000 --> 0:02:56.720000 could allow unauthorized access or account compromise. 0:02:56.720000 --> 0:03:00.160000 So, the objective here is you're testing the authentication functionality 0:03:00.160000 --> 0:03:04.400000 of the web application that you're targeting, whether you're performing 0:03:04.400000 --> 0:03:10.460000 a bug bounty, whether you're doing bug bounty hunting or this is a standard 0:03:10.460000 --> 0:03:14.200000 web app pen test that you've been hired to perform. 0:03:14.200000 --> 0:03:19.720000 So, authentication testing targets flaws that may permit bypassing of 0:03:19.720000 --> 0:03:25.740000 login controls and these would include weak password policies. 0:03:25.740000 --> 0:03:34.220000 So, not the login form or authentication mechanism, not enforcing stronger 0:03:34.220000 --> 0:03:39.360000 passwords, essentially meaning that users would most likely be tempted 0:03:39.360000 --> 0:03:43.400000 to use very basic passwords that they remember, which can be susceptible 0:03:43.400000 --> 0:03:46.740000 to brute force attacks or dictionary attacks. 0:03:46.740000 --> 0:03:52.200000 Credential stuffing also as they're called, session fixation and inadequate 0:03:52.200000 --> 0:03:56.860000 token handling. So, don't worry, I've mentioned quite a few vulnerabilities 0:03:56.860000 --> 0:04:01.960000 or attacks here and we'll be exploring them to various degrees albies. 0:04:01.960000 --> 0:04:06.140000 In this course, I'm going to be focusing on some of the more modern or 0:04:06.140000 --> 0:04:12.660000 I should say targeting some of the more modern authentication mechanisms. 0:04:12.660000 --> 0:04:16.840000 So, going beyond the standard brute forcing a login form, but taking a 0:04:16.840000 --> 0:04:21.960000 look at vulnerabilities like authentication bypasses, let's see if I can 0:04:21.960000 --> 0:04:26.100000 remember any other, you know, bypassing any rate limiting. 0:04:26.100000 --> 0:04:31.540000 So, if there's a capture, how do you, you know, brute force that particular 0:04:31.540000 --> 0:04:34.160000 login form or how do you automate it? 0:04:34.160000 --> 0:04:36.620000 Because again, that can be quite complex. 0:04:36.620000 --> 0:04:38.020000 So, stuff like that. 0:04:38.020000 --> 0:04:41.360000 Now, the objective really, you know, simply port, which is why there's 0:04:41.360000 --> 0:04:46.800000 only one paragraph on this slide is that you're, so within this phase, 0:04:46.800000 --> 0:04:50.260000 you're trying to identify and, of course, exploit your, if you're a pen 0:04:50.260000 --> 0:04:56.440000 tester, weaknesses in authentication to gain unauthorized access. 0:04:56.440000 --> 0:04:59.660000 In addition to that, you're also trying to see whether you can elevate 0:04:59.660000 --> 0:05:01.260000 your privileges. 0:05:01.260000 --> 0:05:04.980000 So, moving from a standard user account to maybe getting the privileges 0:05:04.980000 --> 0:05:07.780000 of an admin user, that would be pretty cool. 0:05:07.780000 --> 0:05:13.320000 Or even hijack legitimate user sessions, therefore, or thus demonstrating 0:05:13.320000 --> 0:05:16.940000 the real world impact of compromised authentication security. 0:05:16.940000 --> 0:05:25.660000 And I'm approaching this from, you know, more so, a particular methodological 0:05:25.660000 --> 0:05:34.040000 approach and the use of the OSWSDG guide, as it were, essentially provide 0:05:34.040000 --> 0:05:40.180000 you with ways of not only testing for specific vulnerabilities, but the 0:05:40.180000 --> 0:05:45.480000 proper way of categorizing or documenting them so that when you're writing 0:05:45.480000 --> 0:05:50.240000 your report, they are as accurate as possible in terms of describing exactly 0:05:50.240000 --> 0:05:55.680000 what vulnerability you've found, but also replicating it and demonstrating 0:05:55.680000 --> 0:06:00.300000 the potential impact, which I think is quite important. 0:06:00.300000 --> 0:06:03.940000 Now, of course, this will also apply to a professional web app and test, 0:06:03.940000 --> 0:06:08.440000 but this also applies to bug bounty hunting, I would say quite a bit. 0:06:08.440000 --> 0:06:16.040000 So, that's where we have the WSDG or the OSWSDG testing guide. 0:06:16.040000 --> 0:06:21.100000 And for web application penetration testers, the OSWSDG service, both 0:06:21.100000 --> 0:06:26.000000 a training resource and a methodological guide, particularly in the critical 0:06:26.000000 --> 0:06:31.340000 area of authentication testing, particularly, but not limited to, as you'll 0:06:31.340000 --> 0:06:34.340000 see in a few seconds, if you're not familiar with it. 0:06:34.340000 --> 0:06:40.980000 The WSDG is not to be confused with the OSWSDG, which is sort of a catalog 0:06:40.980000 --> 0:06:46.160000 or list of vulnerabilities, you know, that are categorized by rank by 0:06:46.160000 --> 0:06:48.300000 OSW. That's something different. 0:06:48.300000 --> 0:06:54.980000 This is more so a a resource or a guide that sort of gives you an idea 0:06:54.980000 --> 0:07:01.400000 of, you know, what to test, when to test it, how to test it, etc. 0:07:01.400000 --> 0:07:07.100000 So, by providing standardized comprehensive guidance on testing steps, 0:07:07.100000 --> 0:07:12.360000 it enables testers like yourself to conduct effective, consistent, and 0:07:12.360000 --> 0:07:17.600000 impactful assessments of, in this case, authentication controls and other 0:07:17.600000 --> 0:07:23.220000 security areas, like session security or session management, that will 0:07:23.220000 --> 0:07:26.340000 be exploring later on within this very course. 0:07:26.340000 --> 0:07:29.900000 So, for now, we're just sticking to the authentication testing section 0:07:29.900000 --> 0:07:33.180000 of the OSWSDG testing guide. 0:07:33.180000 --> 0:07:37.540000 A link to the guide has been added to this slide, or you can just search 0:07:37.540000 --> 0:07:40.320000 for OSWSDG on Google. 0:07:40.320000 --> 0:07:43.860000 I'll show you what seconds. 0:07:43.860000 --> 0:07:48.940000 There's also a PDF, which I personally have on my iPad, pretty much for 0:07:48.940000 --> 0:07:51.040000 quick reference whenever I need to. 0:07:51.040000 --> 0:07:57.380000 But it's been an invaluable resource to me, specifically for, you know, 0:07:57.380000 --> 0:08:02.620000 these two points here, effective and consistent, because we use a methodology. 0:08:02.620000 --> 0:08:06.920000 Again, you don't have to rigorously adhere to one, but it also it always 0:08:06.920000 --> 0:08:14.620000 ensures that you're performing checks and the WSDG is not something that 0:08:14.620000 --> 0:08:17.020000 OSW has developed in isolation. 0:08:17.020000 --> 0:08:22.080000 It's actually a project that a lot of, you know, people on the defensive 0:08:22.080000 --> 0:08:28.300000 side, so DevOps, AppSec, DevSecOps contribute to as well as the offensive 0:08:28.300000 --> 0:08:32.680000 side. So, they actually contribute to making it as comprehensive and as 0:08:32.680000 --> 0:08:36.900000 standardized as possible, while still, you know, providing you with the 0:08:36.900000 --> 0:08:41.560000 flexibility to incorporate, you know, additional tests if you so want. 0:08:41.560000 --> 0:08:49.780000 So, I've listed out the tests that are in the OSWSDG, the latest version, 0:08:49.780000 --> 0:08:56.300000 hence the IDs here, and what they're used for, or generally speaking, 0:08:56.300000 --> 0:08:59.400000 and this will make much more sense in the PDF. 0:08:59.400000 --> 0:09:04.340000 Within the authentication tests or testing authentication section of the 0:09:04.340000 --> 0:09:09.600000 WSDG, these are the tests that are essentially recommended that, you know, 0:09:09.600000 --> 0:09:14.160000 you perform if you're testing the security of a web application, or even 0:09:14.160000 --> 0:09:16.980000 an API, but that's something that we're not covering right now. 0:09:16.980000 --> 0:09:21.020000 So, the first one is testing for credentials transported over an encrypted 0:09:21.020000 --> 0:09:28.060000 channel. So, that's essentially verifying that credentials or data being 0:09:28.060000 --> 0:09:32.860000 transferred from a browser, or your browser, to the web application or 0:09:32.860000 --> 0:09:40.300000 the web server, are transmitted using HTTPS or Vi HTTPS to ensure that 0:09:40.300000 --> 0:09:44.640000 they're encrypted and they cannot be intercepted and, you know, deciphered. 0:09:44.640000 --> 0:09:48.940000 So, man in the middle attacks, testing for default credentials. 0:09:48.940000 --> 0:09:52.420000 So, checking if any default credentials are still in use, especially when 0:09:52.420000 --> 0:09:57.340000 you're using or you're testing a third party web application, like a CMS 0:09:57.340000 --> 0:10:01.680000 or something like that, where you check for, you essentially check to 0:10:01.680000 --> 0:10:05.260000 see if there's use of any default credentials. 0:10:05.260000 --> 0:10:07.940000 You then have testing for weak lockout mechanisms. 0:10:07.940000 --> 0:10:11.680000 This is very, very relevant to what you're going to deal with in the modern 0:10:11.680000 --> 0:10:16.660000 day, at least as of me recording this course, where you're assessing the 0:10:16.660000 --> 0:10:26.760000 application's lockout mechanisms to prevent through traditional rate limiting, 0:10:26.760000 --> 0:10:32.440000 where failed attempts are limited to, let's say, 10 for every hour, and 0:10:32.440000 --> 0:10:35.820000 you're essentially locked out or an account is locked out after three 0:10:35.820000 --> 0:10:38.800000 failed attempts, and you have to reset the password. 0:10:38.800000 --> 0:10:44.140000 So, that's one of the security mechanisms that you typically see used 0:10:44.140000 --> 0:10:45.900000 in web applications. 0:10:45.900000 --> 0:10:51.140000 Another one on login forms is the captures, which I'll actually show you 0:10:51.140000 --> 0:10:57.660000 how to bypass or how you can still essentially not bypass, but include 0:10:57.660000 --> 0:11:00.060000 in your brute force attacks successfully. 0:11:00.060000 --> 0:11:04.520000 So, you can actually brute force perform a standard, you know, use name, 0:11:04.520000 --> 0:11:08.980000 password, brute force on a login form that has a capture and not bypass 0:11:08.980000 --> 0:11:16.940000 it, but also, you know, perform the essentially ensure that the that your 0:11:16.940000 --> 0:11:19.660000 capture entries per request are correct. 0:11:19.660000 --> 0:11:23.860000 Then you have testing for bypassing authentication schema. 0:11:23.860000 --> 0:11:26.920000 This again is also very relevant. 0:11:26.920000 --> 0:11:30.620000 What this is referring to for some of you experienced a web app pentas 0:11:30.620000 --> 0:11:35.840000 out there, pentasters out there is authentication bypass vulnerabilities. 0:11:35.840000 --> 0:11:41.260000 So, you know, this is where you identify flaws in the authentication process, 0:11:41.260000 --> 0:11:45.200000 which again is quite wide in terms of, you know, the different ways you 0:11:45.200000 --> 0:11:49.960000 can do that. But this essentially allows attackers or will allow you to 0:11:49.960000 --> 0:11:51.540000 bypass authentication. 0:11:51.540000 --> 0:11:55.120000 So, you know, I used a very basic example there. 0:11:55.120000 --> 0:11:59.660000 The standard nomenclature or, you know, this is colloquially known as 0:11:59.660000 --> 0:12:03.940000 authentication bypass where if you have a login form through some magic, 0:12:03.940000 --> 0:12:09.160000 which I'll show you, you're able to bypass the login form altogether, 0:12:09.160000 --> 0:12:13.820000 no brute force just bypass it and somehow magically you're logged in. 0:12:13.820000 --> 0:12:17.840000 You then have testing for vulnerable remember password function. 0:12:17.840000 --> 0:12:22.680000 So, this evaluates if the remember me functionalities implement is implemented 0:12:22.680000 --> 0:12:27.020000 securely without exposing sensitive data that could aid in unauthorized 0:12:27.020000 --> 0:12:32.180000 access. A good an example of how this is done well is if you are on a 0:12:32.180000 --> 0:12:40.200000 web application or let's say a SaaS service, and it has the forgot password 0:12:40.200000 --> 0:12:45.840000 functionality, if you enter an email, again, let's just say it's real 0:12:45.840000 --> 0:12:49.800000 or it's not real, you know, you're essentially performing a test, the 0:12:49.800000 --> 0:12:53.700000 web application will not tell you whether that email actually belongs 0:12:53.700000 --> 0:12:58.580000 to an account. So, there's no information that it's that's being exposed. 0:12:58.580000 --> 0:13:02.180000 So, the attacker will not be able to tell that, hey, there is an account 0:13:02.180000 --> 0:13:05.940000 with this email that could then allow them to maybe, you know, brute force 0:13:05.940000 --> 0:13:10.120000 that account. It just says that if this account is registered with us, 0:13:10.120000 --> 0:13:14.700000 we will send a password reset email to the email. 0:13:14.700000 --> 0:13:16.500000 So, it doesn't reveal anything beyond that. 0:13:16.500000 --> 0:13:21.500000 It doesn't even say that, hey, this email doesn't belong to any user or 0:13:21.500000 --> 0:13:24.740000 anything like that, because that can be very useful for attackers. 0:13:24.740000 --> 0:13:28.780000 So, another test that's quite important. 0:13:28.780000 --> 0:13:33.280000 Then we have a couple of others like testing for browser cache weaknesses. 0:13:33.280000 --> 0:13:38.500000 So, this ensures sensitive information is not only stored, is not stored, 0:13:38.500000 --> 0:13:42.140000 sorry, insecurely in the browser cache where attackers could retrieve 0:13:42.140000 --> 0:13:46.820000 it. Testing for weak password policy, that's your brute force attack where 0:13:46.820000 --> 0:13:50.600000 you examine the application's password policy to determine if it enforces 0:13:50.600000 --> 0:13:55.760000 sufficient password complexity and expiration requirements. 0:13:55.760000 --> 0:14:02.640000 So, you know, to the latter point there, it's always good for web application 0:14:02.640000 --> 0:14:08.000000 to continually prompt the user to reset their password, not mandatory, 0:14:08.000000 --> 0:14:12.000000 but something that's quite important in certain industries, for example, 0:14:12.000000 --> 0:14:17.220000 banking, and then testing for weak authentication in alternative channels. 0:14:17.220000 --> 0:14:22.320000 So, this involves testing alternative authentication channels, for example, 0:14:22.320000 --> 0:14:28.060000 APIs, mobile applications, etc., for weaker or inconsistent security practices 0:14:28.060000 --> 0:14:30.540000 that could lead to an account compromise. 0:14:30.540000 --> 0:14:35.660000 So, what this means, this is again, I'll use the example of online banking, 0:14:35.660000 --> 0:14:40.160000 at least in certain regions or countries, you have the ability to access 0:14:40.160000 --> 0:14:45.760000 your account online through a web application, or you can use your mobile 0:14:45.760000 --> 0:14:51.260000 application. And what you're doing here is what you're trying to assess 0:14:51.260000 --> 0:14:57.020000 whether the the web application uses, let's say a specific API, does the 0:14:57.020000 --> 0:15:01.000000 mobile application use the same API in the same standard, or is it using 0:15:01.000000 --> 0:15:05.740000 something weaker that could be, you know, potentially targeted, and instead 0:15:05.740000 --> 0:15:12.280000 of targeting the login form on, you know, the web application that you 0:15:12.280000 --> 0:15:17.060000 access in your browser, you may be, you may have more success in performing 0:15:17.060000 --> 0:15:23.260000 an attack, an authentication based attack on, you know, the mobile application, 0:15:23.260000 --> 0:15:26.640000 either through intercepting traffic, you know, there's many examples that 0:15:26.640000 --> 0:15:31.220000 I can give you, but these are the tests that are outlined in the latest 0:15:31.220000 --> 0:15:37.000000 version as of recording this video of the OSW SDG, more specifically under 0:15:37.000000 --> 0:15:41.660000 authentication. Remember, this is just a small subset of tests that deal 0:15:41.660000 --> 0:15:46.640000 or are pertinent to authentication, testing or testing authentication 0:15:46.640000 --> 0:15:49.160000 within a web application. 0:15:49.160000 --> 0:15:54.160000 So before I leave you, before I end this video, I'm going to switch over 0:15:54.160000 --> 0:15:58.600000 to my browser and show you what the OSW SDG looks like. 0:15:58.600000 --> 0:16:03.060000 It's completely free, you know, it's released or it's maintained, developed 0:16:03.060000 --> 0:16:04.780000 and maintained by OSP. 0:16:04.780000 --> 0:16:09.600000 So, you know, really, really awesome resource. 0:16:09.600000 --> 0:16:12.620000 So I'm just going to switch over into my browser really quickly and I'll 0:16:12.620000 --> 0:16:16.120000 see you, I'll see you there in a few seconds. 0:16:16.120000 --> 0:16:21.880000 All right, so I'm currently in my browser and I've just opened up the 0:16:21.880000 --> 0:16:26.860000 link that I added to the slides or you can just search for the OSW SDG 0:16:26.860000 --> 0:16:29.300000 or web security testing guide. 0:16:29.300000 --> 0:16:34.280000 So here's the project page, as you can see, and I'll just introduce you 0:16:34.280000 --> 0:16:37.740000 to it, of course, you can see it says over here, the web security testing 0:16:37.740000 --> 0:16:43.580000 guide, abbreviated as WSDG project produces the premier cybersecurity 0:16:43.580000 --> 0:16:48.880000 testing resource for web application developers and security professionals. 0:16:48.880000 --> 0:16:53.360000 The WSDG is a comprehensive guide to testing the security of web applications 0:16:53.360000 --> 0:16:58.020000 and web services created by the collaborative efforts of cybersecurity 0:16:58.020000 --> 0:17:01.140000 professionals and dedicated volunteers. 0:17:01.140000 --> 0:17:06.360000 The WSDG provides a framework of use by penetration testers and organizations 0:17:06.360000 --> 0:17:08.280000 all over the world. 0:17:08.280000 --> 0:17:12.320000 Enough said that, you know, I mean, this is, you know, I'm telling you 0:17:12.320000 --> 0:17:19.860000 to use it, but it really has been an invaluable resource to me, you know, 0:17:19.860000 --> 0:17:23.300000 over the years, and it's something that I always go back to whenever I, 0:17:23.300000 --> 0:17:28.720000 you know, I'm sort of feeling whenever I feel that I'm not on, you know, 0:17:28.720000 --> 0:17:32.240000 firm footing or I don't have a firm footing or I feel that I've missed 0:17:32.240000 --> 0:17:36.440000 something. The key thing to note is that there are different versions 0:17:36.440000 --> 0:17:41.480000 of the WSDG. There's this stable version, which is what you'd consider 0:17:41.480000 --> 0:17:45.940000 a production release, if you will. 0:17:45.940000 --> 0:17:50.060000 And there's also new versions coming out that, you know, update the framework. 0:17:50.060000 --> 0:17:53.040000 So it's not like a completely new framework with new IDs. 0:17:53.040000 --> 0:17:59.420000 It's sort of an update to the existing, to the existing guide, if you 0:17:59.420000 --> 0:18:04.800000 will. So you can take a look at the stable version, or you can always 0:18:04.800000 --> 0:18:09.220000 go back to, so if you go to the stable version here, believe that's 4 0:18:09.220000 --> 0:18:16.700000 .2, you can read it online, or alternatively, you can actually, if you 0:18:16.700000 --> 0:18:25.760000 go to the project link here, and you have this stable release there, there 0:18:25.760000 --> 0:18:28.240000 should be a way to get the PDF. 0:18:28.240000 --> 0:18:32.480000 So if I go into the release versions, there we are, download the PDF, 0:18:32.480000 --> 0:18:34.480000 which I already have open here. 0:18:34.480000 --> 0:18:39.200000 So this is the web security testing guide version 4.2. 0:18:39.200000 --> 0:18:44.720000 And, you know, you can see the, you can actually see this here. 0:18:44.720000 --> 0:18:50.300000 And if you go into the actual table of contents, you can see it breaks 0:18:50.300000 --> 0:18:55.300000 down various tests or phases of a web app pen test, generally speaking. 0:18:55.300000 --> 0:19:00.900000 So over here, you have your information gathering phase, you have configuration 0:19:00.900000 --> 0:19:06.320000 and deployment management testing, identity management testing, and what 0:19:06.320000 --> 0:19:09.740000 we are going to be focusing on, at least in this section, before we get 0:19:09.740000 --> 0:19:11.520000 into session management. 0:19:11.520000 --> 0:19:14.120000 And that is authentication testing. 0:19:14.120000 --> 0:19:23.160000 So I can click over in there, and you can see these were the as they are, 0:19:23.160000 --> 0:19:28.560000 I didn't put in their subsection header numbering, because that's not 0:19:28.560000 --> 0:19:29.520000 really important. 0:19:29.520000 --> 0:19:34.660000 As you'll see, each test has its own unique ID, right over here, which 0:19:34.660000 --> 0:19:39.940000 corresponds to what's in the slide, as I said, as of version 4.2. 0:19:39.940000 --> 0:19:43.820000 So you can go through each of the tests, and it'll give you a bit more 0:19:43.820000 --> 0:19:46.920000 of a description than what I gave you in the slides. 0:19:46.920000 --> 0:19:51.740000 So for example, if I went to, let's say the one we I was particularly 0:19:51.740000 --> 0:19:58.280000 interested in, which was, you know, testing for default credentials. 0:19:58.280000 --> 0:20:04.720000 So it actually gives you the root cause of the problem, and the test objective. 0:20:04.720000 --> 0:20:08.500000 So the test objectives are to enumerate the applications for default credentials 0:20:08.500000 --> 0:20:13.380000 and validate if they still exist, review and assess new user accounts, 0:20:13.380000 --> 0:20:17.940000 and if they are created with any defaults or identifiable patterns, so 0:20:17.940000 --> 0:20:18.860000 very, very nice. 0:20:18.860000 --> 0:20:22.800000 It tells you what to look out for, what the objectives are, and then how 0:20:22.800000 --> 0:20:27.240000 to test it. So in a black box testing, the test knows nothing about the 0:20:27.240000 --> 0:20:29.060000 application and its underlying infrastructure. 0:20:29.060000 --> 0:20:31.660000 In reality, this is often not true. 0:20:31.660000 --> 0:20:34.140000 And some information about the application is known. 0:20:34.140000 --> 0:20:37.260000 We suppose that you have identified through the use of the techniques 0:20:37.260000 --> 0:20:40.720000 described in this testing guide under the chapter information gathering, 0:20:40.720000 --> 0:20:45.480000 at least one or more common applications that may contain accessible administrative 0:20:45.480000 --> 0:20:50.420000 interfaces. So, you know, it gives you a description there, and it gives 0:20:50.420000 --> 0:20:52.960000 you more information about the procedure. 0:20:52.960000 --> 0:20:58.240000 So, you know, testing for use enumeration, testing for weak possible policy, 0:20:58.240000 --> 0:21:04.300000 and you know, what to look out for, and also how to modify your approach 0:21:04.300000 --> 0:21:08.480000 if you're performing a gray box pen test as opposed to a black box test. 0:21:08.480000 --> 0:21:12.380000 And then the really great, you know, an additional great thing is that 0:21:12.380000 --> 0:21:18.300000 it tells you the tools that, again, you should use, but I remember this 0:21:18.300000 --> 0:21:23.420000 is something that a lot of people have collaborated on the WSDG. 0:21:23.420000 --> 0:21:27.680000 And this is sort of a generalization of the most popular tools used for 0:21:27.680000 --> 0:21:29.200000 this type of testing. 0:21:29.200000 --> 0:21:33.620000 I'll use one more, like for example, testing for weak lockout mechanism, 0:21:33.620000 --> 0:21:39.920000 where you can see that, let me go into the test objectives here. 0:21:39.920000 --> 0:21:43.580000 So evaluate the account lockout mechanisms ability to mitigate brute force 0:21:43.580000 --> 0:21:48.280000 password guessing, evaluate the unlock mechanisms resistance to unauthorized 0:21:48.280000 --> 0:21:50.060000 account locking. 0:21:50.060000 --> 0:21:51.220000 And it tells you how to do it. 0:21:51.220000 --> 0:21:54.480000 So, attempt to log in with an incorrect password three times. 0:21:54.480000 --> 0:22:00.860000 So essentially how to test for, you know, a weak lockout mechanism, or, 0:22:00.860000 --> 0:22:05.060000 you know, if you're testing a well built or well secured web application 0:22:05.060000 --> 0:22:12.440000 how to test a secure or a strong lockout, a strong lockout mechanism, 0:22:12.440000 --> 0:22:14.520000 or at least a secure one. 0:22:14.520000 --> 0:22:18.560000 And then it gives you different, different considerations. 0:22:18.560000 --> 0:22:22.460000 So, for example, a capture may hinder brute force attacks, but they can 0:22:22.460000 --> 0:22:29.040000 come with their own set of it sort of gives you the augmentations or what 0:22:29.040000 --> 0:22:33.380000 to expect. And also the weaknesses that you should test for within these 0:22:33.380000 --> 0:22:37.400000 augmentation. So something like capture, which can be there to again, 0:22:37.400000 --> 0:22:39.440000 protect against brute force attacks. 0:22:39.440000 --> 0:22:44.560000 It also shows you how you can defeat it, depending on what type of capture 0:22:44.560000 --> 0:22:45.740000 you're dealing with. 0:22:45.740000 --> 0:22:50.580000 So, to evaluate a capture's effectiveness, it tells you how to do that 0:22:50.580000 --> 0:22:56.320000 as well. And then some remediation instructions, which can be very useful 0:22:56.320000 --> 0:22:58.640000 if you're writing a report, right? 0:22:58.640000 --> 0:23:03.040000 And that also gives you references to attacks linked to this or brute 0:23:03.040000 --> 0:23:06.920000 force attacks. And then again, you can proceed on anyway. 0:23:06.920000 --> 0:23:10.940000 The bottom line is, I just wanted to give you a feel for the OASP web 0:23:10.940000 --> 0:23:14.980000 security testing guide and how we're going to be using it. 0:23:14.980000 --> 0:23:19.480000 All right, so that brings us to the end of this video. 0:23:19.480000 --> 0:23:24.520000 I'm fairly comfortable and quite happy with how I've laid out everything. 0:23:24.520000 --> 0:23:29.480000 And now that we have the fundamentals covered, specifically in relation 0:23:29.480000 --> 0:23:34.380000 to authentication, we can start exploring some of the attacks or tests 0:23:34.380000 --> 0:23:43.540000 outlined in the WSDG testing guide, more specific or specifically the 0:23:43.540000 --> 0:23:47.900000 authentication tests and we'll be looking, as I said, not all of them, 0:23:47.900000 --> 0:23:53.700000 but some of the more common ones that are what you're likely to encounter 0:23:53.700000 --> 0:23:58.300000 in the real world, regardless as to whether you're on the defensive side 0:23:58.300000 --> 0:23:59.940000 or on the offensive side. 0:23:59.940000 --> 0:24:02.860000 But with that being said, I don't want to take too much of your time, 0:24:02.860000 --> 0:24:05.200000 that's going to be it for this video. 0:24:05.200000 --> 0:24:07.580000 And I will be seeing you in the next video.