WEBVTT

0:00:04.380000 --> 0:00:08.040000
 The ORASP Top 10 list of vulnerabilities.


0:00:08.040000 --> 0:00:11.960000
 In this video, I'm going to give you
 a formal introduction to the all

0:00:11.960000 --> 0:00:16.960000
 famous or the infamous ORASP Top
 10 list of vulnerabilities.

0:00:16.960000 --> 0:00:22.060000
 But more than that, I'm going to explain
 to you why it was created and

0:00:22.060000 --> 0:00:25.360000
 how it is typically used because
 it's not really a methodology.

0:00:25.360000 --> 0:00:31.140000
 It's more so a classification of the top
 10 list of vulnerabilities affecting

0:00:31.140000 --> 0:00:38.340000
 web applications or the web in general
 over a certain period of time.

0:00:38.340000 --> 0:00:43.340000
 And the point is that it is constantly
 updated to stay relevant with what

0:00:43.340000 --> 0:00:48.960000
 the world is dealing with in terms
 of the actual threats that face the

0:00:48.960000 --> 0:00:51.680000
 top threats that face web applications.

0:00:51.680000 --> 0:00:53.660000
 And the reason this is done
 will become apparent.

0:00:53.660000 --> 0:00:59.780000
 So, to begin, the ORASP Top 10 is a
 regularly updated list of the most

0:00:59.780000 --> 0:01:06.600000
 critical web application security risks
 that have affected and are essentially

0:01:06.600000 --> 0:01:12.000000
 affecting web applications or websites
 around the world today.

0:01:12.000000 --> 0:01:17.620000
 So it essentially involves a statistical
 analysis of the most common types

0:01:17.620000 --> 0:01:20.320000
 of attacks over a certain period of time.


0:01:20.320000 --> 0:01:24.060000
 And then based on that, these are
 compiled into a top 10 list.

0:01:24.060000 --> 0:01:29.020000
 And the reason they're put into a list
 is obviously to firstly show web

0:01:29.020000 --> 0:01:34.560000
 developers or even web app pen testers
 what the trends are like in terms

0:01:34.560000 --> 0:01:36.260000
 of what's being exploited.

0:01:36.260000 --> 0:01:40.600000
 And that'll help the developers or web
 application security professionals

0:01:40.600000 --> 0:01:45.300000
 better protect their web applications
 as they're able to prioritize.

0:01:45.300000 --> 0:01:50.260000
 But it also highlights the evolution in
 terms of the attacks and how things

0:01:50.260000 --> 0:01:55.960000
 are changing. And also the actual complexity
 and the maturity of attackers

0:01:55.960000 --> 0:02:02.460000
 with regards to the nature of new attacks
 and what they're focusing on.

0:02:02.460000 --> 0:02:06.180000
 And as I said, this will become apparent
 as we take a look at the actual

0:02:06.180000 --> 0:02:08.340000
 top 10 list of vulnerabilities.

0:02:08.340000 --> 0:02:13.200000
 So, it is maintained or it was created
 and is maintained by the open web

0:02:13.200000 --> 0:02:17.420000
 application security project also known
 as OASP, which is a nonprofit

0:02:17.420000 --> 0:02:21.600000
 organization focused on improving
 web application security.

0:02:21.600000 --> 0:02:27.020000
 Absolutely fantastic project with phenomenal
 people who have contributed

0:02:27.020000 --> 0:02:32.180000
 to it. And generally speaking, or seriously
 speaking, have made the web

0:02:32.180000 --> 0:02:35.680000
 a much safer place without OASP top 10.

0:02:35.680000 --> 0:02:41.260000
 We would be at least in my estimation,
 as I like saying, about 80% backward

0:02:41.260000 --> 0:02:47.500000
 or in the past with regards to being able
 to protect and essentially prevent

0:02:47.500000 --> 0:02:50.260000
 web applications from being exploited.

0:02:50.260000 --> 0:02:56.700000
 So it has contributed a lot to the
 defensive security or the security

0:02:56.700000 --> 0:03:02.160000
 posture of web applications
 in a positive way.

0:03:02.160000 --> 0:03:06.680000
 So the OASP top 10 serves as a valuable
 guide for developers, web app

0:03:06.680000 --> 0:03:10.900000
 investors and organizations to understand
 and prioritize common security

0:03:10.900000 --> 0:03:13.880000
 risks in web applications.

0:03:13.880000 --> 0:03:18.880000
 And the way they do this is I said,
 they pretty much have releases and

0:03:18.880000 --> 0:03:22.680000
 the OASP top 10 is, you know, as I've
 pointed out, is a well known list

0:03:22.680000 --> 0:03:26.220000
 of the top 10 most critical web
 application security risks.

0:03:26.220000 --> 0:03:30.880000
 And the reason why it's so beloved is primarily
 because it undergoes periodic

0:03:30.880000 --> 0:03:35.160000
 updates to ensure that it reflects the
 current threat landscape and the

0:03:35.160000 --> 0:03:39.420000
 evolving security challenges faced by
 web applications and also indicates

0:03:39.420000 --> 0:03:43.160000
 towards potential trends moving forward.

0:03:43.160000 --> 0:03:47.820000
 So the first version of the OASP top
 10 was released way back in 2003,

0:03:47.820000 --> 0:03:49.400000
 if you can believe it.

0:03:49.400000 --> 0:03:53.020000
 And it aimed to raise awareness about
 common web application security

0:03:53.020000 --> 0:03:56.900000
 risks and help developers prioritize
 security efforts.

0:03:56.900000 --> 0:04:00.440000
 And you'll actually see this and how
 important it is, especially if you

0:04:00.440000 --> 0:04:01.080000
 are a developer.

0:04:01.080000 --> 0:04:06.160000
 The list included risks like cross-site
 scripting, SQL injection and session

0:04:06.160000 --> 0:04:07.600000
 management issues.

0:04:07.600000 --> 0:04:11.940000
 So right from the very offset, it also,
 you know, during the early releases

0:04:11.940000 --> 0:04:18.700000
 was successfully able to predict trends
 with regards to what risks or

0:04:18.700000 --> 0:04:23.720000
 what vulnerabilities or attacks were
 likely to become more popular just

0:04:23.720000 --> 0:04:25.640000
 based on how the web was evolving.

0:04:25.640000 --> 0:04:32.680000
 So it is fairly accurate and it is a well
 respected list of vulnerabilities.

0:04:32.680000 --> 0:04:36.260000
 Now each release of the OASP top 10
 builds upon the previous versions,

0:04:36.260000 --> 0:04:37.280000
 which is very important.

0:04:37.280000 --> 0:04:41.960000
 It builds on top of the previous versions
 by taking into account, as I

0:04:41.960000 --> 0:04:47.900000
 said, multiple statistics or factors
 with regard to even how they may

0:04:47.900000 --> 0:04:52.580000
 shift a position of a particular
 vulnerability or threat.

0:04:52.580000 --> 0:05:00.840000
 So for example, in 2013 or the OASP
 top 10 2013, injection may have been

0:05:00.840000 --> 0:05:04.440000
 the top most threats.

0:05:04.440000 --> 0:05:08.740000
 So it was listed as number one, however,
 or A1, if you will, however,

0:05:08.740000 --> 0:05:15.720000
 and this is just an example based on,
 you know, a set based on various

0:05:15.720000 --> 0:05:18.500000
 factors that will not dive into right
 now because it's quite difficult

0:05:18.500000 --> 0:05:25.020000
 to explain it in the 2021 release or
 even the 2017 release that position

0:05:25.020000 --> 0:05:26.660000
 may have shifted.

0:05:26.660000 --> 0:05:30.840000
 And the point that I'm trying to make
 here is that, you know, when they

0:05:30.840000 --> 0:05:34.920000
 move on to the next version, it doesn't
 necessarily mean on the other

0:05:34.920000 --> 0:05:39.720000
 new release. It doesn't necessarily mean
 that, you know, because injection

0:05:39.720000 --> 0:05:44.160000
 is moved from position one to position
 three, that you shouldn't, you

0:05:44.160000 --> 0:05:46.460000
 know, you should essentially
 stop focusing on injection.

0:05:46.460000 --> 0:05:51.440000
 It just means that in terms of the
 numbers, the frequency of attacks,

0:05:51.440000 --> 0:05:56.220000
 the new threat of vulnerability now
 at the top most position is there

0:05:56.220000 --> 0:06:01.020000
 by virtue of that fact, the fact that
 it's the most common in a set period

0:06:01.020000 --> 0:06:07.320000
 of time. It doesn't, you know, negate
 the dangers or the risk posed by

0:06:07.320000 --> 0:06:09.680000
 some of the other ones that may
 have shifted in position.

0:06:09.680000 --> 0:06:13.420000
 It just means that for this period of
 time, this is what is relevant right

0:06:13.420000 --> 0:06:17.740000
 now. And of course, if you wanted a historical
 view, you'd still see that

0:06:17.740000 --> 0:06:22.400000
 vulnerabilities like, you know, SQL injection
 are still ranked quite high

0:06:22.400000 --> 0:06:27.120000
 up there. So that brings me now to the
 actual demo that I wanted to give

0:06:27.120000 --> 0:06:29.780000
 you. And I'm sure I'm going to show
 you where you can find the last top

0:06:29.780000 --> 0:06:33.480000
 10. Again, that's fairly simple, but
 I'm also going to be breaking down

0:06:33.480000 --> 0:06:37.920000
 some very important factors or aspects
 that you need to keep in mind when

0:06:37.920000 --> 0:06:47.000000
 using it and showing you how to calculate,
 you know, calculating things

0:06:47.000000 --> 0:06:49.720000
 like risk and so on and so forth.

0:06:49.720000 --> 0:06:53.740000
 So I'm going to switch over to my browser
 and we'll take a look at OASP

0:06:53.740000 --> 0:07:00.400000
 top 10. All right, so I'm currently
 in my browser and I'm just going to

0:07:00.400000 --> 0:07:04.000000
 navigate. I already have
 navigated to Google.com.

0:07:04.000000 --> 0:07:08.220000
 I'm just going to perform a search
 for OASP top 10 and just hit enter.

0:07:08.220000 --> 0:07:09.980000
 And that's pretty much all
 that you need to do.

0:07:09.980000 --> 0:07:13.980000
 Let me just change my language here
 to a language that most of you can

0:07:13.980000 --> 0:07:15.440000
 read. And there we are.

0:07:15.440000 --> 0:07:18.360000
 That's the first link right
 over your OS top 10.

0:07:18.360000 --> 0:07:22.120000
 And this will give you a description
 as to what the project is all about,

0:07:22.120000 --> 0:07:23.000000
 which I've done.

0:07:23.000000 --> 0:07:24.360000
 But let's go through it together.

0:07:24.360000 --> 0:07:27.800000
 And the reason for this will become
 apparent, but you can see that the

0:07:27.800000 --> 0:07:33.000000
 OS top 10 is a standard awareness document
 for developers and web application

0:07:33.000000 --> 0:07:37.760000
 security. It represents a broad consensus
 about the most critical security

0:07:37.760000 --> 0:07:41.460000
 risks to web applications or
 pose to web applications.

0:07:41.460000 --> 0:07:46.480000
 And it's globally recognized by developers
 as the first step towards more

0:07:46.480000 --> 0:07:49.600000
 secure coding. And that
 is absolutely true.

0:07:49.600000 --> 0:07:53.440000
 The moment I introduced this resource
 to developers, they immediately

0:07:53.440000 --> 0:07:58.720000
 improve the security posture of the
 web applications they're developing.

0:07:58.720000 --> 0:08:01.880000
 So companies should adopt this document
 and start the process of ensuring

0:08:01.880000 --> 0:08:04.660000
 that their web applications
 minimize these risks.

0:08:04.660000 --> 0:08:08.980000
 Using the OS top 10 is perhaps the most
 effective first step towards changing

0:08:08.980000 --> 0:08:13.080000
 the software development culture within
 your organization into one that

0:08:13.080000 --> 0:08:15.200000
 produces more secure code.

0:08:15.200000 --> 0:08:19.020000
 And the way it does this by first is
 by first telling developers, for

0:08:19.020000 --> 0:08:24.240000
 example, you know, that you will or
 these are, you know, the top 10 list

0:08:24.240000 --> 0:08:28.300000
 of vulnerabilities that you need to
 be that you need to prioritize.

0:08:28.300000 --> 0:08:33.100000
 And secondly, it goes about telling them,
 you know, what causes the vulnerability,

0:08:33.100000 --> 0:08:37.260000
 how it can be identified, which is
 useful for us as web app investors

0:08:37.260000 --> 0:08:42.340000
 and how it can be mitigated
 or patched, if you will.

0:08:42.340000 --> 0:08:46.480000
 So that brings us to the top 10
 web application security risks.

0:08:46.480000 --> 0:08:50.720000
 So as it says here, based on the current
 release, there are three new

0:08:50.720000 --> 0:08:54.480000
 categories, four categories with naming
 and scoping changes, which is

0:08:54.480000 --> 0:08:58.640000
 important. And some consolidation
 in the top 10 for 2021.

0:08:58.640000 --> 0:09:04.880000
 So the previous release was 2017 and the
 current release, as of me recording

0:09:04.880000 --> 0:09:10.140000
 this video, is the OS top 10 2021.

0:09:10.140000 --> 0:09:15.760000
 And based on or after each release,
 there will be a diagram similar to

0:09:15.760000 --> 0:09:19.520000
 the one where you're seeing the one
 you're seeing here that outlines the

0:09:19.520000 --> 0:09:25.000000
 changes made or the evolution of the
 previous list or the previous release

0:09:25.000000 --> 0:09:28.860000
 to the actual current release.

0:09:28.860000 --> 0:09:31.840000
 And as you can see, based on the description
 here, there are three new

0:09:31.840000 --> 0:09:36.880000
 categories and four categories have
 experienced name changes and scoping

0:09:36.880000 --> 0:09:42.040000
 changes. And you can dive into, you
 know, what these changes are and why

0:09:42.040000 --> 0:09:46.140000
 they were made by just going through
 this particular web page as we will

0:09:46.140000 --> 0:09:51.620000
 be. But before we do that, it's important
 to note that on the top right,

0:09:51.620000 --> 0:09:59.020000
 right over here, you can directly navigate
 to the OS top 10 2021 list

0:09:59.020000 --> 0:10:00.820000
 right over here.

0:10:00.820000 --> 0:10:04.400000
 And I'll explain, you know, how this
 website is sorted, but you can also

0:10:04.400000 --> 0:10:07.540000
 reference the previous
 version, which is 2017.

0:10:07.540000 --> 0:10:10.260000
 And those are also accessible
 in terms of downloads.

0:10:10.260000 --> 0:10:15.680000
 But taking a look at the actual changes,
 you can see that and this will

0:10:15.680000 --> 0:10:17.180000
 highlight the structure.

0:10:17.180000 --> 0:10:22.060000
 They're listed from one to 10 and
 the prefix is always a, all right.

0:10:22.060000 --> 0:10:27.340000
 And in this particular case, you can
 see that in 2017, injection was the,

0:10:27.340000 --> 0:10:30.860000
 you know, the top most security
 risk of vulnerability.

0:10:30.860000 --> 0:10:37.260000
 You then had a broken authentication
 and sensitive data exposure, XXE,

0:10:37.260000 --> 0:10:41.100000
 broken access control, security misconfiguration,
 cross-site scripting

0:10:41.100000 --> 0:10:44.060000
 was not really up there.

0:10:44.060000 --> 0:10:47.860000
 You have insecure deserialization,
 which was actually quite popular at

0:10:47.860000 --> 0:10:49.900000
 a particular point in time.

0:10:49.900000 --> 0:10:53.900000
 Using components with known vulnerabilities,
 that is referring to third

0:10:53.900000 --> 0:10:58.800000
 party plugins or libraries and then
 insufficient logging and monitoring.

0:10:58.800000 --> 0:11:02.920000
 Now, it's very important that when you
 do reference, like, for example,

0:11:02.920000 --> 0:11:08.940000
 within a report, the top 10 list of
 vulnerabilities, like a good example

0:11:08.940000 --> 0:11:15.000000
 of this is if you're writing a report,
 you can utilize these vulnerability

0:11:15.000000 --> 0:11:21.160000
 or risk categorizations or categories,
 if you will, to reference specific

0:11:21.160000 --> 0:11:25.100000
 vulnerabilities that you have found
 by saying, for example, let's say

0:11:25.100000 --> 0:11:27.360000
 you found a SQL injection vulnerability.

0:11:27.360000 --> 0:11:31.380000
 Within your report, you can sort of classify
 all injection vulnerabilities

0:11:31.380000 --> 0:11:35.260000
 by saying A03-2021 injection.

0:11:35.260000 --> 0:11:39.100000
 And you can also provide a reference
 to the actual page on the OAS website

0:11:39.100000 --> 0:11:40.400000
 right over here.

0:11:40.400000 --> 0:11:45.960000
 And that is done because it's said it's
 with most web app and test reports

0:11:45.960000 --> 0:11:47.120000
 that I've seen recently.

0:11:47.120000 --> 0:11:49.480000
 Pretty much everyone has adopted it.

0:11:49.480000 --> 0:11:53.540000
 And the reason everyone has adopted
 it is because the developers, when

0:11:53.540000 --> 0:11:57.440000
 taking a look at the recommendations
 given by you with regards to how

0:11:57.440000 --> 0:12:01.600000
 to fix it, can easily just
 refer to A03-2021.

0:12:01.600000 --> 0:12:04.140000
 And let's say they do that, for example.

0:12:04.140000 --> 0:12:10.840000
 So if we go to A03-2021, it'll first tell
 you the evolution side of things,

0:12:10.840000 --> 0:12:14.940000
 but it says that injection slides
 down to the third position.

0:12:14.940000 --> 0:12:21.280000
 94% of the applications were tested
 for some form of injection and the

0:12:21.280000 --> 0:12:27.180000
 33 CWEs mapped into this category have
 the second most occurrences in

0:12:27.180000 --> 0:12:30.640000
 applications. Cross-site scripting is
 now part of this category in this

0:12:30.640000 --> 0:12:32.000000
 edition as well.

0:12:32.000000 --> 0:12:33.740000
 So that's very important.

0:12:33.740000 --> 0:12:36.800000
 It's very important that you read the
 changes because if you're using

0:12:36.800000 --> 0:12:42.560000
 a previous release and releases usually
 happen every four years, which

0:12:42.560000 --> 0:12:47.400000
 makes sense. That's really enough time
 to see the actual changes and to

0:12:47.400000 --> 0:12:48.960000
 provide you with an updated list.

0:12:48.960000 --> 0:12:52.520000
 But the point I'm making is that the category
 changes are the most important

0:12:52.520000 --> 0:12:58.020000
 because if you reference 2017 incorrectly
 or let's say you reference A1

0:12:58.020000 --> 0:13:01.820000
-2017 and you put in something like OAS.

0:13:01.820000 --> 0:13:07.200000
 Or you say A1-2021 and injection because
 you've forgotten about the actual

0:13:07.200000 --> 0:13:11.620000
 changes in terms of the order and the
 names, that can be a bit problematic.

0:13:11.620000 --> 0:13:16.580000
 So the reason why I'm sort of nagging
 you on this is because make sure

0:13:16.580000 --> 0:13:21.440000
 that when you are moving to the latest
 release, that you use that release

0:13:21.440000 --> 0:13:23.920000
 instead of going back to 2017.

0:13:23.920000 --> 0:13:27.700000
 And make sure that everyone, like if
 you are working in a team, make sure

0:13:27.700000 --> 0:13:31.420000
 everyone is aware of this and they
 familiarize themselves with the new

0:13:31.420000 --> 0:13:34.340000
 updates to the list and the name changes.


0:13:34.340000 --> 0:13:39.640000
 So we now know that SQL Injection or sorry,
 cross-site scripting is included

0:13:39.640000 --> 0:13:47.860000
 in the injection category or security
 risks right over here in 2021.

0:13:47.860000 --> 0:13:52.200000
 So we can click on the particular
 risk or category.

0:13:52.200000 --> 0:13:56.000000
 And what you'll see now is there's going
 to be a lot of data, but don't

0:13:56.000000 --> 0:14:01.080000
 worry. This is the dedicated
 page for the OAS top 10 2021.

0:14:01.080000 --> 0:14:04.480000
 And, you know, it's telling
 us it's injection.

0:14:04.480000 --> 0:14:05.960000
 We have the CWEs map.

0:14:05.960000 --> 0:14:08.040000
 I'll explain what that is.

0:14:08.040000 --> 0:14:14.020000
 The max incidence rate, the average incidence
 rate, average weighted exploit,

0:14:14.020000 --> 0:14:17.120000
 average weighted impact, max,
 the maximum coverage.

0:14:17.120000 --> 0:14:22.880000
 The average coverage, the total occurrences
 and the total CVE, so common

0:14:22.880000 --> 0:14:27.480000
 vulnerability and exposures out of
 this particular type of attack.

0:14:27.480000 --> 0:14:31.900000
 Now, the problem is that the first
 issue that a lot of people run into

0:14:31.900000 --> 0:14:35.560000
 is that you may think that this
 is referring to SQL Injection.

0:14:35.560000 --> 0:14:39.800000
 And that is one of the reasons why alike
 OASP top 10 as well as the security

0:14:39.800000 --> 0:14:44.720000
 testing guide. And let me explain
 what this means, right?

0:14:44.720000 --> 0:14:48.680000
 So they'll firstly give you an overview,
 which we've already read.

0:14:48.680000 --> 0:14:53.300000
 And it'll also give you an explanation
 or a breakdown of specific nomenclature

0:14:53.300000 --> 0:14:56.340000
 used in terms of abbreviated words.

0:14:56.340000 --> 0:15:02.200000
 So, for example, CWEs are common
 weakness enumerations.

0:15:02.200000 --> 0:15:07.320000
 And, you know, you can also take a look
 at some of the other terms, which

0:15:07.320000 --> 0:15:10.780000
 I'll show you, you know, essentially what
 they mean when they are relevant.

0:15:10.780000 --> 0:15:16.940000
 But it'll give you a description as to
 what are the requirements for injection

0:15:16.940000 --> 0:15:18.560000
 attacks to take place.

0:15:18.560000 --> 0:15:22.280000
 So, firstly, user supply data is not
 validated, filtered or sanitized

0:15:22.280000 --> 0:15:27.680000
 by the application, dynamic queries
 or non-parameterized calls without

0:15:27.680000 --> 0:15:31.780000
 context aware, escaping or used
 directly in the interpreter.

0:15:31.780000 --> 0:15:35.980000
 Hostile data is used within object
 relational mapping or ORM.

0:15:35.980000 --> 0:15:39.600000
 Search parameters to extract
 additional sensitive records.

0:15:39.600000 --> 0:15:42.780000
 Hostile data is directly
 used or concatenated.

0:15:42.780000 --> 0:15:46.860000
 The SQL command contains the structure
 and malicious data in dynamic queries,

0:15:46.860000 --> 0:15:49.300000
 commands or stored procedures.

0:15:49.300000 --> 0:15:55.340000
 So, it'll now tell you what OASP
 considers common injections.

0:15:55.340000 --> 0:16:02.940000
 So, you firstly have SQL, NoSQL injection,
 OAS command injection, ORM.

0:16:02.940000 --> 0:16:10.000000
 You also have LDAP injection, expression
 language injection, object graph

0:16:10.000000 --> 0:16:15.800000
 navigation library injection, and the concept
 is identical among all interpreters.

0:16:15.800000 --> 0:16:20.240000
 Source code reviews the best method of detecting
 if applications are vulnerable

0:16:20.240000 --> 0:16:26.080000
 to injections. Automated testing of all
 parameters, headers, URLs, cookies,

0:16:26.080000 --> 0:16:29.260000
 JSON soap and XML data inputs
 is strongly encouraged.

0:16:29.260000 --> 0:16:35.320000
 Organizations can include static, dynamic
 and interactive application

0:16:35.320000 --> 0:16:39.920000
 security testing tools into the continuous
 integration, continuous development

0:16:39.920000 --> 0:16:47.040000
 pipeline to identify introduced injection
 flows before production deployment.

0:16:47.040000 --> 0:16:52.760000
 So, it tells you how to detect it and
 how you can go about performing

0:16:52.760000 --> 0:16:57.200000
 tests that will help you identify any
 potential injection vulnerabilities

0:16:57.200000 --> 0:17:01.860000
 within your application.

0:17:01.860000 --> 0:17:04.940000
 And it'll also tell you how
 these can be prevented.

0:17:04.940000 --> 0:17:08.380000
 And then it has a set of
 example attack scenarios.

0:17:08.380000 --> 0:17:11.820000
 And then you can go ahead and take a
 look at the references within this

0:17:11.820000 --> 0:17:13.680000
 particular page.

0:17:13.680000 --> 0:17:15.840000
 Now, why did I want to state this?

0:17:15.840000 --> 0:17:19.600000
 Well, this is sort of the way you
 can go through the actual list.

0:17:19.600000 --> 0:17:22.600000
 And again, you may be asking yourself,
 how is this relevant as a web app

0:17:22.600000 --> 0:17:27.120000
 pen tester? Well, firstly, you can treat
 this as a knowledge base, right,

0:17:27.120000 --> 0:17:32.720000
 to give you firstly an idea as to what
 is the incidence rate of a particular

0:17:32.720000 --> 0:17:36.800000
 vulnerability. And that can tell you
 whether you should focus on these

0:17:36.800000 --> 0:17:42.580000
 types of vulnerabilities or not.

0:17:42.580000 --> 0:17:44.880000
 And then you can see the average impact,
 which again, this tells you that

0:17:44.880000 --> 0:17:52.560000
 this is a very rare to find this based
 on the data collected, right?

0:17:52.560000 --> 0:17:54.520000
 So that's the average incidence rate.

0:17:54.520000 --> 0:17:57.960000
 But the maximum incidence
 rate is almost 20%.

0:17:57.960000 --> 0:18:02.420000
 The impact is quite high
 regardless of this.

0:18:02.420000 --> 0:18:06.920000
 What this means taking a look at this
 data, it means that yes, this is

0:18:06.920000 --> 0:18:10.540000
 a very, I wouldn't say rare.

0:18:10.540000 --> 0:18:14.960000
 I would just say that the incidence
 rate is very low in comparison to

0:18:14.960000 --> 0:18:16.780000
 some of the others.

0:18:16.780000 --> 0:18:22.940000
 But the weighted impact of the injection
 vulnerabilities is extremely

0:18:22.940000 --> 0:18:24.720000
 high, all right?

0:18:24.720000 --> 0:18:27.420000
 And you can take a look at the total
 occurrences here in terms of the

0:18:27.420000 --> 0:18:34.120000
 total numbers. Now, if we go back to
 the previous page and I just wanted

0:18:34.120000 --> 0:18:37.300000
 to highlight this, you can go ahead and
 take a look at, for example, broken

0:18:37.300000 --> 0:18:39.460000
 axis control here.

0:18:39.460000 --> 0:18:43.640000
 You can actually see that the max incidence
 rate is actually higher now

0:18:43.640000 --> 0:18:45.140000
 in this particular case.

0:18:45.140000 --> 0:18:46.860000
 But the impact is a little bit lower.

0:18:46.860000 --> 0:18:50.280000
 But you can see whites at the top and
 it'll also tell you whites at the

0:18:50.280000 --> 0:18:54.080000
 top. So you can see moves up from
 the fifth position from 2017.

0:18:54.080000 --> 0:18:57.620000
 So broken axis control is now up here.

0:18:57.620000 --> 0:19:02.460000
 94% of applications were tested for
 some form of broken axis control.

0:19:02.460000 --> 0:19:06.920000
 The 34 common weakness enumerations
 mapped to broken axis control had

0:19:06.920000 --> 0:19:11.240000
 more occurrences in applications than
 any other, which means they, for

0:19:11.240000 --> 0:19:14.420000
 some reason, seem to be occurring more.

0:19:14.420000 --> 0:19:18.660000
 And then you can click on any of these
 and navigate and learn more about

0:19:18.660000 --> 0:19:23.040000
 it. Now, what I want to focus on here
 is going to be the fact that you

0:19:23.040000 --> 0:19:26.960000
 can click on the actual, you know, that
 link right over here, the project

0:19:26.960000 --> 0:19:33.080000
 information that will take you to the
 actual primary web page here, which,

0:19:33.080000 --> 0:19:37.440000
 you know, just a documentation or repository
 that details or explains

0:19:37.440000 --> 0:19:42.920000
 every, every or each one of the
 top 10 list of vulnerabilities.

0:19:42.920000 --> 0:19:47.360000
 But in addition to that, you also have,
 you know, the making of OS top

0:19:47.360000 --> 0:19:51.480000
 10, where they will essentially break
 down right over here or give you

0:19:51.480000 --> 0:19:57.560000
 sort of a summary as to where they got
 their data to make these conclusions.

0:19:57.560000 --> 0:20:02.960000
 Also, for example, if you go into the
 data right over here, you can see

0:20:02.960000 --> 0:20:07.860000
 that, you know, one of the unique aspects
 of the current OS top 10 is

0:20:07.860000 --> 0:20:10.360000
 that it is built on in a hybrid manner.

0:20:10.360000 --> 0:20:14.260000
 There are two primary components to
 defining what 10 risks are in the

0:20:14.260000 --> 0:20:19.360000
 list. First is a data call cast out for
 organizations to contribute data.

0:20:19.360000 --> 0:20:22.660000
 They have collected about web application
 vulnerabilities in various processes.

0:20:22.660000 --> 0:20:27.260000
 This data will identify eight
 of the 10 risks in the top 10.

0:20:27.260000 --> 0:20:33.980000
 In 2017, organizations contributed data
 that covered over 114,000 applications

0:20:33.980000 --> 0:20:37.060000
 for the 2021 data call.

0:20:37.060000 --> 0:20:39.360000
 We are more than double that so far.

0:20:39.360000 --> 0:20:43.940000
 So they're actually using real data
 from real organizations to get this.

0:20:43.940000 --> 0:20:50.340000
 And why don't they rely, you know,
 just on just pure statistical data?

0:20:50.340000 --> 0:20:54.120000
 Well, as they say here, quite
 bluntly, it's incomplete.

0:20:54.120000 --> 0:20:57.700000
 The results in the data are largely
 limited to what we have figured out

0:20:57.700000 --> 0:21:01.260000
 how to test for in an automated fashion.

0:21:01.260000 --> 0:21:04.860000
 Talk to a seasoned pen test and they
 will tell you about stuff they find

0:21:04.860000 --> 0:21:07.500000
 and trends they see that
 aren't in the data.

0:21:07.500000 --> 0:21:08.700000
 And that is correct.

0:21:08.700000 --> 0:21:12.700000
 That's one of the key things that I
 wanted to point out is, well, this

0:21:12.700000 --> 0:21:16.140000
 list is very good and
 generally agreed upon.

0:21:16.140000 --> 0:21:20.240000
 You know, with with pro pen testers,
 you know, that there are certain

0:21:20.240000 --> 0:21:23.400000
 trends that you've seen, you know, just
 based on your experience and your

0:21:23.400000 --> 0:21:27.980000
 intuitive, you know, your intuitiveness,
 you're able to pick those out.

0:21:27.980000 --> 0:21:31.780000
 And it may not necessarily reflect
 for various reasons.

0:21:31.780000 --> 0:21:36.300000
 But the point is that it takes time for
 people to develop testing methodologies

0:21:36.300000 --> 0:21:40.200000
 for certain vulnerability types and
 then more time for those tests to

0:21:40.200000 --> 0:21:43.640000
 be automated and run against a large
 population of applications.

0:21:43.640000 --> 0:21:47.200000
 So this is one of the things that I
 love about them is that they know

0:21:47.200000 --> 0:21:51.500000
 that you cannot, you know, develop,
 you know, the best methodology for

0:21:51.500000 --> 0:21:53.400000
 testing cross-site scripting.

0:21:53.400000 --> 0:21:59.100000
 But if you, you know, if you have at
 it long enough, you'll eventually

0:21:59.100000 --> 0:22:02.540000
 get there. And the point that they're
 trying to make is that this can

0:22:02.540000 --> 0:22:08.200000
 only be backed by data in that if a methodology
 for performing, you know,

0:22:08.200000 --> 0:22:13.060000
 tests for cross-site scripting gets to
 a certain point or becomes mature.

0:22:13.060000 --> 0:22:18.380000
 You can measure its maturity by seeing
 whether if implemented from a defensive

0:22:18.380000 --> 0:22:23.500000
 perspective, whether it reduces the number
 of cross-site scripting vulnerabilities.

0:22:23.500000 --> 0:22:25.740000
 So you can go ahead and read this.

0:22:25.740000 --> 0:22:27.840000
 I don't want to take too
 much time on that.

0:22:27.840000 --> 0:22:31.720000
 What I wanted to focus on, you can take
 a look at the survey right over

0:22:31.720000 --> 0:22:36.060000
 here. But that's not really important
 to me at this point in time.

0:22:36.060000 --> 0:22:37.420000
 It may be to you.

0:22:37.420000 --> 0:22:42.300000
 But you can actually also take a look
 at one of the documents here.

0:22:42.300000 --> 0:22:44.900000
 And we go back to the top 10 list.

0:22:44.900000 --> 0:22:49.700000
 One thing that I wanted to highlight
 really that is very important is,

0:22:49.700000 --> 0:22:53.440000
 you know, for example, it'll essentially
 explain how the categories are

0:22:53.440000 --> 0:23:02.000000
 structured. But more importantly, it
 also will provide you with a, it'll

0:23:02.000000 --> 0:23:06.640000
 also provide you with information on
 how to use it as a standard, right?

0:23:06.640000 --> 0:23:09.840000
 So the OASP top 10 is primarily
 an awareness document.

0:23:09.840000 --> 0:23:14.020000
 However, this is not stopped organizations
 from using it as a de facto

0:23:14.020000 --> 0:23:18.380000
 industry, app-sex standard since
 its inception in 2003.

0:23:18.380000 --> 0:23:22.860000
 Now, the key thing that I want to point
 out here actually is going to

0:23:22.860000 --> 0:23:27.180000
 be the actual calculation of risk.

0:23:27.180000 --> 0:23:28.780000
 And I'm going to show you that right now.


0:23:28.780000 --> 0:23:34.220000
 That can be found in the
 OASP top 10 2017 list.

0:23:34.220000 --> 0:23:35.160000
 And this is just a PDF.

0:23:35.160000 --> 0:23:36.320000
 Now, don't worry.

0:23:36.320000 --> 0:23:41.340000
 We're not taking a look at we're not
 going to be using the 2017 list.

0:23:41.340000 --> 0:23:45.780000
 But the point that I want to point out
 is the fact that it goes over the

0:23:45.780000 --> 0:23:52.700000
 key lexicon that OASP uses and also
 the calculation or how to calculate

0:23:52.700000 --> 0:23:54.660000
 an assigned risk.

0:23:54.660000 --> 0:23:58.520000
 So firstly, there's a very good description
 of, you know, what are application

0:23:58.520000 --> 0:24:01.460000
 security risks and what is my risk.

0:24:01.460000 --> 0:24:06.740000
 So the matrix that can be used for calculation,
 and I'll show you where

0:24:06.740000 --> 0:24:09.500000
 the automated calculator can be found.

0:24:09.500000 --> 0:24:12.320000
 The matrix used is very
 easy to understand.

0:24:12.320000 --> 0:24:18.500000
 You have a table that comprises of,
 you know, multiple pretty much six

0:24:18.500000 --> 0:24:24.780000
 columns and three rows where you have
 sorting by threat agents and whether

0:24:24.780000 --> 0:24:30.180000
 the application specific, the exploitability
 of a particular risk, the

0:24:30.180000 --> 0:24:34.680000
 weakness prevalence, the weakness detectability,
 the technical impacts

0:24:34.680000 --> 0:24:36.140000
 and the business impact.

0:24:36.140000 --> 0:24:39.480000
 So weakness prevalence,
 I'll get to shortly.

0:24:39.480000 --> 0:24:44.340000
 But in terms of weakness detectability,
 that's fairly easy to understand.

0:24:44.340000 --> 0:24:47.540000
 You then have the technical
 impacts right over here.

0:24:47.540000 --> 0:24:51.400000
 So what are the impacts
 of the vulnerability?

0:24:51.400000 --> 0:24:55.880000
 And in terms of getting to this or
 assigning this, it really is quite

0:24:55.880000 --> 0:24:59.980000
 easy to do and I'll actually
 be walking you through it.

0:24:59.980000 --> 0:25:06.700000
 So you can take a look at the actual
 risks right over here, the OASP top

0:25:06.700000 --> 0:25:12.380000
 10, 2017 list. And within this PDF, like
 for example, injection, the risk

0:25:12.380000 --> 0:25:14.860000
 will be calculated automatically for you.


0:25:14.860000 --> 0:25:19.660000
 But you'll realize that this is too vague
 and that's where the Web Security

0:25:19.660000 --> 0:25:22.060000
 Testing Guide calculator
 will come into play.

0:25:22.060000 --> 0:25:26.260000
 But before we jump the gun, you can
 see that in terms of exploitability,

0:25:26.260000 --> 0:25:28.200000
 this has a value of three.

0:25:28.200000 --> 0:25:32.060000
 If we refer to the matrix, you can see
 that exploiting this vulnerability

0:25:32.060000 --> 0:25:38.300000
 is easy. Okay. In terms of prevalence,
 we have a level of two.

0:25:38.300000 --> 0:25:41.920000
 So you can take a look at prevalence
 right over here.

0:25:41.920000 --> 0:25:47.460000
 And you can see that that means that it
 is common right over here or common

0:25:47.460000 --> 0:25:49.980000
 to find out in the wild as it were.

0:25:49.980000 --> 0:25:53.800000
 In terms of detectability, you can
 again refer back to the matrix.

0:25:53.800000 --> 0:25:57.220000
 It's easy to detect and that is true.

0:25:57.220000 --> 0:26:00.020000
 And then if you take a look at the descriptions
 in each of these sections

0:26:00.020000 --> 0:26:04.180000
 broken down into attack vectors, the security
 weakness and then the impact,

0:26:04.180000 --> 0:26:07.260000
 the technical impact has a value
 of three, which is high.

0:26:07.260000 --> 0:26:10.000000
 And the business impact
 needs to be calculated.

0:26:10.000000 --> 0:26:11.700000
 And that's what I was referring to.

0:26:11.700000 --> 0:26:16.500000
 So, you know, in terms of exploitability,
 just using this as an example,

0:26:16.500000 --> 0:26:20.540000
 almost any source of data can be an injection
 vector, environment variables,

0:26:20.540000 --> 0:26:24.340000
 parameters, even URLs, external and
 internal web services and all types

0:26:24.340000 --> 0:26:28.740000
 of users. Injection flows occur when
 an attacker can send hostile data

0:26:28.740000 --> 0:26:30.260000
 to an interpreter.

0:26:30.260000 --> 0:26:33.980000
 In terms of the security weaknesses,
 you can see that this is very useful

0:26:33.980000 --> 0:26:38.340000
 for developers. It tells us that injection
 flows are very prevalent, particularly

0:26:38.340000 --> 0:26:43.420000
 legacy code. Injection vulnerabilities
 are often found in SQL, LDAP, XPath

0:26:43.420000 --> 0:26:49.100000
 or NoSQL queries, OS commands, XML passes,
 SMTP headers, expression languages

0:26:49.100000 --> 0:26:51.420000
 and ORM queries.

0:26:51.420000 --> 0:26:54.940000
 Injection flows are easy to discover
 when examining code.

0:26:54.940000 --> 0:26:58.180000
 Scanners and fuzzers can help attackers
 find injection flows, which is

0:26:58.180000 --> 0:27:02.500000
 true. And Bob Sweet is actually a very
 good tool for that in terms of

0:27:02.500000 --> 0:27:06.020000
 testing specific parameters
 or fuzzing parameters.

0:27:06.020000 --> 0:27:09.260000
 In terms of the impacts, injection
 can result in data loss, corruption

0:27:09.260000 --> 0:27:13.540000
 or disclosure to unauthorized parties,
 also known as data breaches, loss

0:27:13.540000 --> 0:27:16.040000
 of accountability or denial of access.

0:27:16.040000 --> 0:27:20.140000
 Injection can sometimes lead
 to complete host takeover.

0:27:20.140000 --> 0:27:24.540000
 The business impact will depend on the
 needs of the application and the

0:27:24.540000 --> 0:27:32.340000
 data. And then it goes into how to test
 if the application is vulnerable.

0:27:32.340000 --> 0:27:37.180000
 Firstly, if user supply data is not
 validated, the problem with this and

0:27:37.180000 --> 0:27:41.160000
 why we use the security testing guide
 is because this doesn't tell you

0:27:41.160000 --> 0:27:45.240000
 how to test it or in what order or
 what type of test to run, like for

0:27:45.240000 --> 0:27:47.780000
 example against LDAP.

0:27:47.780000 --> 0:27:55.180000
 What is useful and that's why this is
 a very good framework for application

0:27:55.180000 --> 0:27:59.700000
 security or application security professionals
 is because it goes into

0:27:59.700000 --> 0:28:02.700000
 how to prevent the attack.

0:28:02.700000 --> 0:28:06.980000
 Not only how to mitigate, but also
 mitigation and prevention is pretty

0:28:06.980000 --> 0:28:08.040000
 much the same thing.

0:28:08.040000 --> 0:28:11.860000
 But what I was referring to is how to
 identify it and how to incorporate

0:28:11.860000 --> 0:28:15.260000
 what you have learned the next time
 you develop a web application.

0:28:15.260000 --> 0:28:19.600000
 It shows you how to preventative
 actions that can be taken.

0:28:19.600000 --> 0:28:24.580000
 For example, for any residual dynamic
 queries, escape special characters

0:28:24.580000 --> 0:28:29.840000
 using the specific escapes in
 text for that interpreter.

0:28:29.840000 --> 0:28:33.300000
 Very useful and then has
 a set of references.

0:28:33.300000 --> 0:28:36.600000
 This is where it may become a little
 bit useful for attackers, where it

0:28:36.600000 --> 0:28:38.420000
 has example attacks and areas.

0:28:38.420000 --> 0:28:43.900000
 But also for developers where it gives
 them a sample query or a sample

0:28:43.900000 --> 0:28:47.420000
 SQL payload that is used
 to perform SQL injection.

0:28:47.420000 --> 0:28:49.860000
 So very, very, very useful.

0:28:49.860000 --> 0:28:55.380000
 So that is the actual risk aspect of
 it and why I wanted to focus on it.

0:28:55.380000 --> 0:28:59.700000
 What you can also do is take a look
 at some of the other resources.

0:28:59.700000 --> 0:29:04.640000
 Like for example, the previous version
 and the reason why I point this

0:29:04.640000 --> 0:29:08.180000
 out is because when you navigate there,
 you'll also get some of the resources.

0:29:08.180000 --> 0:29:11.440000
 Some very cool resources that you can
 use to improve your understanding

0:29:11.440000 --> 0:29:14.880000
 of the actual project.

0:29:14.880000 --> 0:29:20.600000
 And like for example, some video
 tutorials, some cheat sheets.

0:29:20.600000 --> 0:29:27.400000
 And if I can open this up here, you'll
 actually see some of them and you'll

0:29:27.400000 --> 0:29:29.800000
 actually, you know, you'll
 be able to use them.

0:29:29.800000 --> 0:29:33.820000
 So for example, the main website here,
 you'll be able to use them for

0:29:33.820000 --> 0:29:37.340000
 example, if I click on this here.

0:29:37.340000 --> 0:29:42.980000
 For specific technologies or specific
 vulnerabilities, this is very useful

0:29:42.980000 --> 0:29:45.240000
 for application security professionals.

0:29:45.240000 --> 0:29:49.240000
 They can use this to learn more about
 for example authentication from

0:29:49.240000 --> 0:29:54.080000
 security perspective and you know, provide
 them with guidelines on what

0:29:54.080000 --> 0:29:56.080000
 they should and shouldn't do.

0:29:56.080000 --> 0:29:59.740000
 So for example, you know, authentication
 solution and sensitive accounts

0:29:59.740000 --> 0:30:02.420000
 do not allow logins with
 sensitive accounts.

0:30:02.420000 --> 0:30:06.260000
 IE accounts that can be used internally
 within the solution such as a

0:30:06.260000 --> 0:30:09.440000
 back end, middleware, database, etc.

0:30:09.440000 --> 0:30:11.640000
 And these, this is extremely useful.

0:30:11.640000 --> 0:30:15.180000
 I've found this to be useful even,
 you know, from my perspective as I

0:30:15.180000 --> 0:30:19.560000
 have developed some, some
 web applications.

0:30:19.560000 --> 0:30:23.540000
 I always refer to this when I'm looking
 to secure a specific aspect of

0:30:23.540000 --> 0:30:26.520000
 my web application or a particular
 functionality.

0:30:26.520000 --> 0:30:31.040000
 So for example, what I recently took
 a look at was database security where

0:30:31.040000 --> 0:30:34.980000
 I went through, you know, these recommendations
 in order to go ahead and

0:30:34.980000 --> 0:30:39.220000
 secure my MySQL database because
 I was just curious about it.

0:30:39.220000 --> 0:30:42.700000
 And you can see it's highlighted here
 that you should run the MySQL secure

0:30:42.700000 --> 0:30:47.140000
 installation script to remove the default
 database and accounts, which

0:30:47.140000 --> 0:30:56.480000
 I previously wasn't aware of.

0:30:56.480000 --> 0:31:01.080000
 So if I click on that, you can see it
 refers to the MongoDB documentation.

0:31:01.080000 --> 0:31:04.820000
 So in other words, this is a very, very
 good starting point for anyone,

0:31:04.820000 --> 0:31:08.380000
 especially if you are a developer.

0:31:08.380000 --> 0:31:11.780000
 And more so than that, you also have,
 you know, the table of contents

0:31:11.780000 --> 0:31:16.760000
 and that also highlights a few other
 important aspects that I didn't go

0:31:16.760000 --> 0:31:22.680000
 into. But for example, you know, details
 about risk factors here where

0:31:22.680000 --> 0:31:28.680000
 you'll have a summary table that will
 essentially give you a scoring for

0:31:28.680000 --> 0:31:34.020000
 each of those risks or, you know, the
 actual vulnerabilities, if you will,

0:31:34.020000 --> 0:31:36.140000
 generally speaking, in terms
 of their category.

0:31:36.140000 --> 0:31:40.220000
 So the risk here, injection, you can see
 that the threat agents are application

0:31:40.220000 --> 0:31:45.920000
 specific. The attack vectors in terms
 of exploitability are easy.

0:31:45.920000 --> 0:31:49.220000
 Security weakness in terms of
 prevalence is very common.

0:31:49.220000 --> 0:31:52.460000
 Security weakness in terms of
 detectability, it's easy.

0:31:52.460000 --> 0:31:57.180000
 The impacts are severe and the impacts
 for the business or application

0:31:57.180000 --> 0:32:02.080000
 specific. So these are aspects that
 we'll be talking about now because

0:32:02.080000 --> 0:32:06.040000
 they're very important for a web app
 pen tester because remember, we're

0:32:06.040000 --> 0:32:07.800000
 not interested in securing stuff.

0:32:07.800000 --> 0:32:09.400000
 We're interested in hacking it.

0:32:09.400000 --> 0:32:13.060000
 And if you understand how developers
 think now that they're incorporating,

0:32:13.060000 --> 0:32:18.760000
 you know, secure coding and stuff like
 that, you'll be better placed to

0:32:18.760000 --> 0:32:22.240000
 actually understand, firstly, what causes
 the vulnerability because you're

0:32:22.240000 --> 0:32:24.300000
 looking at what they're looking at.

0:32:24.300000 --> 0:32:28.380000
 You're looking at what they're looking
 at and also, you know, you'll be

0:32:28.380000 --> 0:32:31.820000
 able to improve your understanding of
 web applications in general, what

0:32:31.820000 --> 0:32:32.820000
 causes vulnerabilities.

0:32:32.820000 --> 0:32:38.620000
 And in addition to that, thankfully
 to OAS, we now know, you know, how

0:32:38.620000 --> 0:32:42.780000
 we can go about identifying and exploiting
 these vulnerabilities or these

0:32:42.780000 --> 0:32:44.240000
 particular risks.

0:32:44.240000 --> 0:32:46.960000
 So with that being said, that's going
 to conclude this little practical

0:32:46.960000 --> 0:32:50.280000
 demo. I know the video went a little
 bit long, but I think it's important

0:32:50.280000 --> 0:32:54.100000
 that you familiarize yourself with
 OAS, especially if you are going to

0:32:54.100000 --> 0:32:58.440000
 be working in web application security
 in general, regardless of whether

0:32:58.440000 --> 0:33:03.040000
 you're a developer, web app, tech professional
 or pen tester, bug bounty

0:33:03.040000 --> 0:33:06.120000
 hunter, etc. And you'll
 see why as we progress.

0:33:06.120000 --> 0:33:09.860000
 So that being said, let me switch
 back over into the slides.

0:33:09.860000 --> 0:33:14.160000
 All right. So now that we have an understanding
 as to what the OAS top

0:33:14.160000 --> 0:33:19.520000
 10 list of risks or vulnerabilities
 is and what it's all about, how to

0:33:19.520000 --> 0:33:24.620000
 use it. Regardless, you know, of whether
 you're a pen tester or a developer

0:33:24.620000 --> 0:33:29.160000
 web application security professional,
 we can now turn our attention to

0:33:29.160000 --> 0:33:34.440000
 the actual implementation of the OAS
 web security testing guide, which

0:33:34.440000 --> 0:33:38.600000
 is much more aligned for web app and
 testers, at least in my particular

0:33:38.600000 --> 0:33:41.620000
 case, or in this particular case.

0:33:41.620000 --> 0:33:46.380000
 So I'll be introducing you to it into
 in the next video and we'll take

0:33:46.380000 --> 0:33:50.200000
 a look at the guide and I'll
 explain how it is laid out.

0:33:50.200000 --> 0:33:53.660000
 And then we'll take a look at the most
 important resource, which is the

0:33:53.660000 --> 0:33:58.740000
 actual checklist, which is a spreadsheet
 that will save you a lot of hours

0:33:58.740000 --> 0:34:04.620000
 and will make you into a decent web
 app pen tester, if you implement and

0:34:04.620000 --> 0:34:06.340000
 use it and understand it.

0:34:06.340000 --> 0:34:09.840000
 But with that being said, that's going
 to be it for this video and I'll

0:34:09.840000 --> 0:34:11.840000
 be seeing you in the next video.

