WEBVTT

0:00:04.200000 --> 0:00:08.880000
 Bypassing authentication schema
 parameter manipulation.

0:00:08.880000 --> 0:00:10.580000
 So welcome everyone.

0:00:10.580000 --> 0:00:15.820000
 In this video, we're going to be touching
 on another authentication testing

0:00:15.820000 --> 0:00:18.640000
 test, if you will, or testing technique.

0:00:18.640000 --> 0:00:24.340000
 That's essentially related to the authentication
 schema, or rather bypassing

0:00:24.340000 --> 0:00:29.540000
 it and in specific, or to be more specific,
 the technique will be exploring

0:00:29.540000 --> 0:00:31.980000
 is parameter manipulation.

0:00:31.980000 --> 0:00:37.600000
 So this is going to be quite closely
 linked to what we did in the previous

0:00:37.600000 --> 0:00:41.920000
 video, but this is what we're focusing
 on specifically is what you would

0:00:41.920000 --> 0:00:49.560000
 consider a broken authentication
 attack or vulnerability.

0:00:49.560000 --> 0:00:57.220000
 And there's many forms or ways through
 which this vulnerability can be

0:00:57.220000 --> 0:01:03.160000
 exploited, or rather I should say there's
 various types of, there's various

0:01:03.160000 --> 0:01:09.520000
 ways, this vulnerability
 sort of manifests itself.

0:01:09.520000 --> 0:01:16.300000
 What that means is parameter manipulation
 is just one of the ways of bypassing

0:01:16.300000 --> 0:01:18.600000
 authentication or the
 authentication schema.

0:01:18.600000 --> 0:01:20.440000
 But again, I'm getting out of myself.

0:01:20.440000 --> 0:01:25.220000
 Let's get, let's actually get an understanding
 as to what this particular

0:01:25.220000 --> 0:01:31.080000
 test is all about in relation to, of
 course, the OSW SDG and I've listed

0:01:31.080000 --> 0:01:32.600000
 the ID there for the test.

0:01:32.600000 --> 0:01:35.900000
 That's WSDG, ATH, N, 0, 4.

0:01:35.900000 --> 0:01:40.500000
 So the bypass authentication schema test
 in the OASP web security testing

0:01:40.500000 --> 0:01:48.200000
 guide, also known as WSDG focuses on
 the application process or processes

0:01:48.200000 --> 0:01:52.380000
 that allow attackers to circumvent
 or bypass authentication mechanisms

0:01:52.380000 --> 0:01:56.440000
 entirely. So in the previous video,
 the second part of the attack after

0:01:56.440000 --> 0:02:00.940000
 we had sort of identified the lockout
 mechanism or rate limiting, what

0:02:00.940000 --> 0:02:04.940000
 we did was what you would consider
 an authentication bypass.

0:02:04.940000 --> 0:02:09.100000
 But the reason I didn't call it that
 is because the means through which

0:02:09.100000 --> 0:02:13.520000
 that is achieved was not what you typically
 associate with broken authentication

0:02:13.520000 --> 0:02:19.260000
 per se, because it was more so the
 week or the week lockout mechanism

0:02:19.260000 --> 0:02:21.880000
 that led to the authentication bypass.

0:02:21.880000 --> 0:02:27.720000
 But when talking about bypassing the authentication
 schema, this is usually

0:02:27.720000 --> 0:02:34.380000
 limited to various aspects of the
 authentication mechanism itself.

0:02:34.380000 --> 0:02:39.100000
 So this particular test or technique
 helps penetration testers evaluate

0:02:39.100000 --> 0:02:42.940000
 whether there are gaps in the authentication
 schema that could grant unauthorized

0:02:42.940000 --> 0:02:46.700000
 access to an application
 or a web application.

0:02:46.700000 --> 0:02:50.300000
 So the primary goal of this test is
 to identify and exploit flaws in the

0:02:50.300000 --> 0:02:52.500000
 authentication schema.

0:02:52.500000 --> 0:02:56.800000
 And this includes any technique or method
 that an attacker or, you know,

0:02:56.800000 --> 0:03:01.560000
 pentestal you might use to bypass authentication
 checks, thereby gaining

0:03:01.560000 --> 0:03:04.160000
 unauthorized access without
 valid credentials.

0:03:04.160000 --> 0:03:17.320000
 So the key point is bypassing authentication
 schema or bypassing the schema.

0:03:17.320000 --> 0:03:23.380000
 So to say, essentially takes out the
 need for the use of credentials.

0:03:23.380000 --> 0:03:28.560000
 And again, you've got an idea
 of that in the previous video.

0:03:28.560000 --> 0:03:34.960000
 But generally speaking, when talking about
 broken authentication vulnerabilities

0:03:34.960000 --> 0:03:41.020000
 or the process of bypassing authentication
 altogether, the word or the

0:03:41.020000 --> 0:03:44.240000
 term sort of implies what's happening.

0:03:44.240000 --> 0:03:45.700000
 We're not using credentials.

0:03:45.700000 --> 0:03:47.460000
 We don't need credentials.

0:03:47.460000 --> 0:03:51.100000
 In certain cases, we may need, let's
 say, a use name or something like

0:03:51.100000 --> 0:03:56.540000
 that. But we're sort of just bypassing
 the login form completely and,

0:03:56.540000 --> 0:03:58.400000
 you know, logging in.

0:03:58.400000 --> 0:04:03.180000
 So, you know, what are the objectives?

0:04:03.180000 --> 0:04:07.820000
 What are the outcomes, you know, in
 relation to this test, if they're

0:04:07.820000 --> 0:04:13.080000
 not already obvious, firstly, detect misconfigurations
 or insecure implementations

0:04:13.080000 --> 0:04:15.300000
 in the authentication process.

0:04:15.300000 --> 0:04:21.100000
 And that, you know, is really that particular
 point applies very widely,

0:04:21.100000 --> 0:04:24.420000
 because again, if you're performing a
 web app pentest, you want to highlight

0:04:24.420000 --> 0:04:29.180000
 any weakness or discrepancy regardless
 of whether you were able to bypass

0:04:29.180000 --> 0:04:30.940000
 authentication or not.

0:04:30.940000 --> 0:04:34.500000
 Secondly, identify alternative routes
 or endpoints that provide unauthorized

0:04:34.500000 --> 0:04:39.080000
 access. That's something a lot of people
 don't really factor in that there

0:04:39.080000 --> 0:04:43.020000
 may be a login form, but there may be
 other ways of authenticating that

0:04:43.020000 --> 0:04:47.340000
 may be weaker and sort of bypass the
 whole login form from a security

0:04:47.340000 --> 0:04:50.680000
 perspective. What that means is that
 a company can spend a lot of time

0:04:50.680000 --> 0:04:56.080000
 securing the, let's say, a login form, you
 know, adding all sorts of protection

0:04:56.080000 --> 0:04:59.620000
 mechanisms, lockout mechanisms, etc.

0:04:59.620000 --> 0:05:03.760000
 But if they have other, you know, other
 authentication endpoints, like

0:05:03.760000 --> 0:05:10.100000
 let's say through an API, and that is significantly
 weaker, has no authentication,

0:05:10.100000 --> 0:05:13.460000
 then, you know, it sort of defeats the
 purpose because you only need an

0:05:13.460000 --> 0:05:19.380000
 attacker with experience or with the
 knowledge of how to interact with

0:05:19.380000 --> 0:05:22.060000
 an API to sort of circumvent that.

0:05:22.060000 --> 0:05:26.280000
 And then, of course, finally, validate
 if the unprotected endpoints allow

0:05:26.280000 --> 0:05:27.780000
 access to restricted resources.

0:05:27.780000 --> 0:05:32.400000
 So I use the API example, because
 it is quite common.

0:05:32.400000 --> 0:05:36.080000
 And we'll be exploring this as we progress
 within this learning path and

0:05:36.080000 --> 0:05:38.660000
 into the API penetration testing course.

0:05:38.660000 --> 0:05:41.920000
 We'll probably cover this a little
 bit when we're in this course, when

0:05:41.920000 --> 0:05:47.060000
 we're talking about the JWTs or JSON web
 tokens and token based authentication.

0:05:47.060000 --> 0:05:51.520000
 So when it comes down to bypassing
 authentication schema, what are the

0:05:51.520000 --> 0:05:53.300000
 types of vulnerabilities here?

0:05:53.300000 --> 0:05:56.460000
 What are you looking for generally?

0:05:56.460000 --> 0:05:59.580000
 So the first is obviously the unprotected
 authentication endpoints.

0:05:59.580000 --> 0:06:03.720000
 So some web applications expose endpoints
 or resources that do not require

0:06:03.720000 --> 0:06:07.600000
 authentication. And attackers may access
 these directly without logging

0:06:07.600000 --> 0:06:12.380000
 in. Some common examples include admin panels
 or configuration files inadvertently

0:06:12.380000 --> 0:06:15.740000
 exposed to unauthenticated users.

0:06:15.740000 --> 0:06:21.480000
 So, you know, fairly simple to understand
 what that is, what that pertains

0:06:21.480000 --> 0:06:24.740000
 to. The second is default
 or hard coded credentials.

0:06:24.740000 --> 0:06:29.860000
 So some web applications or applications
 in general, utilize default or

0:06:29.860000 --> 0:06:33.780000
 hard coded usernames and passwords
 that attackers can leverage to gain

0:06:33.780000 --> 0:06:34.860000
 unauthorized access.

0:06:34.860000 --> 0:06:38.020000
 Now, you may be wondering or thinking
 to yourself, well, does this really

0:06:38.020000 --> 0:06:42.880000
 affect modern, you know, web applications
 or modern infrastructure on

0:06:42.880000 --> 0:06:47.500000
 the web? The answer to that is yes, especially,
 and again, I'm emphasizing

0:06:47.500000 --> 0:06:52.640000
 the word especially, or specifically
 when you have a company, or let's

0:06:52.640000 --> 0:06:58.200000
 say a SAS that is quite large in terms
 of scale, or, you know, the web

0:06:58.200000 --> 0:07:03.360000
 application, et cetera, that's spread
 across regions and they have multiple

0:07:03.360000 --> 0:07:07.540000
 API endpoints. They're using a plethora
 of different software, both made

0:07:07.540000 --> 0:07:12.020000
 by themselves or developed in
-house and also third party.

0:07:12.020000 --> 0:07:17.380000
 And in all of this mess, which again
 is firstly very difficult to manage,

0:07:17.380000 --> 0:07:20.680000
 but you can imagine internally how difficult
 it is to secure and to manage,

0:07:20.680000 --> 0:07:26.240000
 maintain and manage that security,
 you know, across updates, upgrades,

0:07:26.240000 --> 0:07:30.900000
 change of systems, change of system
 administrators, change of security

0:07:30.900000 --> 0:07:38.000000
 personnel, you're always likely to find
 one that, you know, is affected

0:07:38.000000 --> 0:07:43.360000
 by this web default useernames or
 default credentials are in use.

0:07:43.360000 --> 0:07:50.560000
 So, to be more specific, these credentials
 could also typically are also

0:07:50.560000 --> 0:07:52.020000
 left in application code.

0:07:52.020000 --> 0:07:55.660000
 So think of secrets and git
 repositories, et cetera.

0:07:55.660000 --> 0:08:00.280000
 That's very common configuration files,
 another common one, or during

0:08:00.280000 --> 0:08:03.600000
 the setup phases, you know,
 without having been changed.

0:08:03.600000 --> 0:08:06.840000
 So, that's a key one there.

0:08:06.840000 --> 0:08:09.440000
 The third is, you know, weak
 or missing access control.

0:08:09.440000 --> 0:08:15.180000
 So, this is fairly what you'd consider
 basic, but still prevalent, I would

0:08:15.180000 --> 0:08:20.080000
 say, especially in development environments
 or in staging environments.

0:08:20.080000 --> 0:08:24.300000
 So certain pages or resources may lack
 proper access control checks, meaning

0:08:24.300000 --> 0:08:28.400000
 users who are not authenticated or who
 are authenticated as low privileged

0:08:28.400000 --> 0:08:32.780000
 users. So, you know, just a standard
 user can access restricted areas.

0:08:32.780000 --> 0:08:36.300000
 That's typically called privilege escalation,
 even on the web, where you

0:08:36.300000 --> 0:08:40.240000
 have access as one user, but you're
 able to, you know, either elevate

0:08:40.240000 --> 0:08:44.660000
 your privileges to that of the admin
 or access stuff that the admin can

0:08:44.660000 --> 0:08:48.540000
 access, which again is typically considered
 a form of privilege escalation.

0:08:48.540000 --> 0:08:54.520000
 So, examples of this include insufficient
 access control or access control

0:08:54.520000 --> 0:09:01.360000
 enforcement on administrator or
 admin or privilege resources.

0:09:01.360000 --> 0:09:06.580000
 And then we have, of course, right over
 here, we have parameter manipulation.

0:09:06.580000 --> 0:09:12.100000
 So, in this particular case, as the name
 suggests, this is the demo we're

0:09:12.100000 --> 0:09:13.660000
 going to go through.

0:09:13.660000 --> 0:09:15.440000
 And there's a good reason for that.

0:09:15.440000 --> 0:09:19.580000
 Attackers may manipulate URL parameters,
 cookies, headers or post data

0:09:19.580000 --> 0:09:23.880000
 to trick the application into
 bypassing authentication.

0:09:23.880000 --> 0:09:27.180000
 And this could involve modifying session
 tokens or tampering with parameters

0:09:27.180000 --> 0:09:42.880000
 that control access levels or the request
 to be more specific is the typical

0:09:42.880000 --> 0:09:50.100000
 way or the typical technique that you
 would employ when sort of testing

0:09:50.100000 --> 0:09:55.300000
 or utilizing parameter manipulation for authentication
 bypassing the authentication

0:09:55.300000 --> 0:09:59.900000
 schema. Now, I would like to make it
 clear that this is not an extensive

0:09:59.900000 --> 0:10:05.200000
 list of all vulnerabilities to test for in
 relation to bypassing the authentication

0:10:05.200000 --> 0:10:11.600000
 schema. And we'll explore some of the
 others, including the ones listed

0:10:11.600000 --> 0:10:16.300000
 in these slides in this course, as we
 progress, as well as in other courses.

0:10:16.300000 --> 0:10:19.460000
 So, I just want to let you know that
 this is just really relevant to this

0:10:19.460000 --> 0:10:23.920000
 particular section of the course
 and this course in general.

0:10:23.920000 --> 0:10:28.720000
 But with that being said, in order to
 demonstrate this, we are going to

0:10:28.720000 --> 0:10:31.640000
 utilize a practical live
 lab on the INAE platform.

0:10:31.640000 --> 0:10:33.740000
 So, this video has a lab
 associated with it.

0:10:33.740000 --> 0:10:36.440000
 It's going to be the lab
 just below this video.

0:10:36.440000 --> 0:10:40.680000
 And it's going to provide you with access
 to the target web application,

0:10:40.680000 --> 0:10:42.580000
 Kali Linux system, etc.

0:10:42.580000 --> 0:10:48.440000
 I'm going to fire up my lab and I'll see
 you in there in a couple of seconds.

0:10:48.440000 --> 0:10:54.260000
 All right. So, I'm currently on
 my Kali Linux virtual machine.

0:10:54.260000 --> 0:10:58.620000
 I do apologize. This lab will not provide
 you with access to a pre-configured

0:10:58.620000 --> 0:11:00.520000
 Kali Linux system.

0:11:00.520000 --> 0:11:04.040000
 But the only tool you will need
 is a web browser and burp suite.

0:11:04.040000 --> 0:11:07.260000
 Even that, you know, burp suite
 is not really recommended.

0:11:07.260000 --> 0:11:10.300000
 But again, for the purpose of this demonstration,
 I'm going to be using

0:11:10.300000 --> 0:11:15.680000
 burp. So, starting the lab will provide
 you with access to a URL to the

0:11:15.680000 --> 0:11:17.340000
 target web application.

0:11:17.340000 --> 0:11:28.900000
 So, I'm just going to fire up the URL
 of the, let me paste that and go,

0:11:28.900000 --> 0:11:34.560000
 the URL that I was provided, or at least
 the URL that I got for my lab,

0:11:34.560000 --> 0:11:36.100000
 or when I started my lab.

0:11:36.100000 --> 0:11:39.180000
 So, this is the name of
 the web application.

0:11:39.180000 --> 0:11:43.400000
 It looks to be an airline booking system.


0:11:43.400000 --> 0:11:55.420000
 And in this particular case, I'm going
 to open up burp suite and I'm going

0:11:55.420000 --> 0:11:59.080000
 to be automated proxying so that
 I don't have to worry about that.

0:11:59.080000 --> 0:12:03.660000
 But this is a fairly simple bypass and
 you'll just see how dangerous this

0:12:03.660000 --> 0:12:09.620000
 can be or how or rather the reason you
 should focus on parameter modification,

0:12:09.620000 --> 0:12:12.880000
 at least as you're getting started.

0:12:12.880000 --> 0:12:19.260000
 But I'll open up the browser here and
 we'll give it a few seconds to start

0:12:19.260000 --> 0:12:20.600000
 up. I do apologize.

0:12:20.600000 --> 0:12:26.160000
 My VM is a bit slow but not an issue.

0:12:26.160000 --> 0:12:27.200000
 So, there we go.

0:12:27.200000 --> 0:12:28.280000
 We can see that there.

0:12:28.280000 --> 0:12:31.440000
 I don't think I have intercept
 enabled, which is fine.

0:12:31.440000 --> 0:12:33.320000
 That's exactly what we want.

0:12:33.320000 --> 0:12:34.180000
 So, there we are.

0:12:34.180000 --> 0:12:37.980000
 Now, the bypass is all tied to the admin.


0:12:37.980000 --> 0:12:41.000000
 So, let me just zoom
 in a little bit here.

0:12:41.000000 --> 0:12:46.140000
 So, we click on the admin menu item
 on the sidebar right over here.

0:12:46.140000 --> 0:12:49.200000
 And now the bypass is fairly simple.

0:12:49.200000 --> 0:12:53.940000
 So, the way it works is what I'm going
 to do is I'm just going to enable

0:12:53.940000 --> 0:12:56.560000
 intercept because we do need it.

0:12:56.560000 --> 0:12:59.360000
 And I'm now going to reload the page.

0:12:59.360000 --> 0:13:03.680000
 And if we go into the, we can
 see that request there.

0:13:03.680000 --> 0:13:05.480000
 So, intercept, there we go.

0:13:05.480000 --> 0:13:07.300000
 That's a get request.

0:13:07.300000 --> 0:13:09.420000
 And you may be asking yourself,
 well, what's the trick?

0:13:09.420000 --> 0:13:10.360000
 What are we doing here?

0:13:10.360000 --> 0:13:14.240000
 Well, the only thing we need to do
 for this vulnerability is just add

0:13:14.240000 --> 0:13:18.380000
 in a cookie that tells the web application
 or lies to the web application

0:13:18.380000 --> 0:13:23.780000
 and tells them that, hey, we are authenticated
 and authenticated as admin.

0:13:23.780000 --> 0:13:26.980000
 Now, more information about this
 vulnerability can be found.

0:13:26.980000 --> 0:13:31.680000
 I think if we use Search Exploit
 here, I say airline.

0:13:31.680000 --> 0:13:38.680000
 Let's see airline booking system.

0:13:38.680000 --> 0:13:41.960000
 There we are. So, we can actually,
 I'll just go into my desktop here,

0:13:41.960000 --> 0:13:44.920000
 copy user share.

0:13:44.920000 --> 0:13:51.020000
 I'll just copy that to my desktop
 user share exploit DB exploits.

0:13:51.020000 --> 0:13:54.560000
 And the path is right over here.

0:13:54.560000 --> 0:13:57.000000
 So, I'll just copy that there.

0:13:57.000000 --> 0:13:58.820000
 And I'll paste that in here.

0:13:58.820000 --> 0:14:02.480000
 Let me increase my font size so
 you can see what I'm doing.

0:14:02.480000 --> 0:14:12.140000
 So, I'm just copying that DxD or that
 exploit looks like it has multiple

0:14:12.140000 --> 0:14:13.200000
 vulnerabilities.

0:14:13.200000 --> 0:14:16.340000
 The one we're interested in
 is authentication bypass.

0:14:16.340000 --> 0:14:18.680000
 So, this is actually pretty cool.

0:14:18.680000 --> 0:14:21.280000
 So, I'm just going to cat it out again.

0:14:21.280000 --> 0:14:24.620000
 So, the vulnerability exists in the
 admin panel authentication mechanism

0:14:24.620000 --> 0:14:30.960000
 due to the use of cookie logged in as
 the cookie variable can be manipulated

0:14:30.960000 --> 0:14:35.720000
 by user. So, any user can log into
 the admin panel without knowing the

0:14:35.720000 --> 0:14:37.020000
 use name or password.

0:14:37.020000 --> 0:14:43.500000
 And the way this is performed is by
 specifying cookie is equal to sorry

0:14:43.500000 --> 0:14:46.300000
 cookie logged in is equal
 to yes right over here.

0:14:46.300000 --> 0:14:52.840000
 So, that's all we need to add to the
 request to the get request remember.

0:14:52.840000 --> 0:14:57.000000
 So, we need to add it a request header
 and it'll let us log in supposedly.

0:14:57.000000 --> 0:15:00.540000
 So, let's actually test
 this out right now.

0:15:00.540000 --> 0:15:06.100000
 So, what I'm going to do is think you
 can see this a little bit clearly.

0:15:06.100000 --> 0:15:11.080000
 So, we can add it anywhere really but
 I'll add it after user actually

0:15:11.080000 --> 0:15:16.740000
 after accept. Let me just
 add it after here.

0:15:16.740000 --> 0:15:23.040000
 So, I'll just say paste in there and
 we'll hit forward and now if we go

0:15:23.040000 --> 0:15:25.760000
 there let's see.

0:15:25.760000 --> 0:15:34.780000
 Okay, let me go back into and just say
 forward there we need to pass it

0:15:34.780000 --> 0:15:37.960000
 there we are. Okay, so not
 logged in interesting.

0:15:37.960000 --> 0:15:41.400000
 All right, so let me just
 disable intercept.

0:15:41.400000 --> 0:15:54.540000
 So, I'll go back to admin and I will
 now enable and let's just put it

0:15:54.540000 --> 0:15:56.800000
 anywhere in here.

0:15:56.800000 --> 0:16:02.180000
 So, cookie logged in is yes.

0:16:02.180000 --> 0:16:07.240000
 So, let's go ahead and
 forward that there.

0:16:07.240000 --> 0:16:10.840000
 And we have the cookie set
 there not really sure.

0:16:10.840000 --> 0:16:14.300000
 I mean we probably have to
 add it in here as well.

0:16:14.300000 --> 0:16:17.880000
 Maybe, maybe not but let's see.

0:16:17.880000 --> 0:16:22.880000
 So, forward let's see
 you're not logged in.

0:16:22.880000 --> 0:16:25.660000
 So, let's refresh this again.

0:16:25.660000 --> 0:16:27.960000
 Let's add this in here.

0:16:27.960000 --> 0:16:30.940000
 Add in the cookie forward.

0:16:30.940000 --> 0:16:33.140000
 There we are. We're able to bypass it.

0:16:33.140000 --> 0:16:37.140000
 So, it's actually the subsequent request
 that we needed to insert the

0:16:37.140000 --> 0:16:42.340000
 cookie into and we're now logged in as
 admin and we can add flights here.

0:16:42.340000 --> 0:16:44.700000
 So, let me disable intercept.

0:16:44.700000 --> 0:16:48.300000
 Okay, so it looks like for every request
 we need to add the cookie there

0:16:48.300000 --> 0:16:51.900000
 which is, you know, this point is probably
 wise to just create a cookie

0:16:51.900000 --> 0:16:56.120000
 here using cookie manager
 or cookie editor.

0:16:56.120000 --> 0:17:00.720000
 So, let's just see the
 cookies for this site.

0:17:00.720000 --> 0:17:02.880000
 So, we can add one here.

0:17:02.880000 --> 0:17:10.280000
 We can just call it, you know, logged
 in is, you know, just call it logged

0:17:10.280000 --> 0:17:12.960000
 in is equal to yes.

0:17:12.960000 --> 0:17:16.180000
 Let's see if that works out.

0:17:16.180000 --> 0:17:19.700000
 And I'm just going to refresh this.

0:17:19.700000 --> 0:17:23.200000
 Yeah, it does work.

0:17:23.200000 --> 0:17:26.260000
 So, you can just manually set the cookie
 using a cookie manager or cookie

0:17:26.260000 --> 0:17:28.280000
 editor. But that's pretty much it.

0:17:28.280000 --> 0:17:31.660000
 That was an example or a demonstration of
 what a, you know, broken authentication

0:17:31.660000 --> 0:17:34.560000
 looks like and how dangerous it can be.

0:17:34.560000 --> 0:17:38.100000
 And you can see that we didn't have
 to specify any credentials, anything

0:17:38.100000 --> 0:17:40.980000
 into the, you know, anything.

0:17:40.980000 --> 0:17:44.140000
 So, we didn't have to log in, perform
 a brute force, a dictionary attack,

0:17:44.140000 --> 0:17:45.560000
 play around with anything.

0:17:45.560000 --> 0:17:52.320000
 That's why or how, you know, authentication
 bypass vulnerability, just

0:17:52.320000 --> 0:17:54.020000
 how dangerous they can be.

0:17:54.020000 --> 0:17:58.040000
 With that being said, that brings us to
 the end of the practical demonstration

0:17:58.040000 --> 0:18:00.520000
 section of this video.

0:18:00.520000 --> 0:18:04.600000
 All right. So, that was bypassing authentication
 schema through parameter

0:18:04.600000 --> 0:18:08.540000
 manipulation. As I said, we'll be exploring
 some of the other, you know,

0:18:08.540000 --> 0:18:12.420000
 broken authentication, slash authentication
 bypass techniques as we progress

0:18:12.420000 --> 0:18:14.420000
 in this course, as well as others.

0:18:14.420000 --> 0:18:18.800000
 They come in different shapes and sizes
 or in different forms, I should

0:18:18.800000 --> 0:18:21.840000
 say. But with that being said, that
 brings us to the end of this video

0:18:21.840000 --> 0:18:24.280000
 and the end of this section
 of the course.

0:18:24.280000 --> 0:18:29.060000
 And the next testing session management.

0:18:29.060000 --> 0:18:32.100000
 So, you know, session management vulnerabilities,
 which are slightly different

0:18:32.100000 --> 0:18:35.180000
 now because we've tested authentication
 quite a bit.

0:18:35.180000 --> 0:18:39.300000
 We've looked at pretty much, I would
 say most of the tests in the WSDG

0:18:39.300000 --> 0:18:41.660000
 or at least the ones that
 are relevant or important.

0:18:41.660000 --> 0:18:44.560000
 But with that being said, that brings
 us to the end of this video and

0:18:44.560000 --> 0:18:47.700000
 this section. I said in the next section,
 we're getting into session management