WEBVTT

0:00:03.880000 --> 0:00:08.920000
 Hello everyone and welcome to the session
 management testing section of

0:00:08.920000 --> 0:00:14.800000
 this course. To begin with, we're going
 to be exploring one of the first

0:00:14.800000 --> 0:00:20.320000
 tests, or I should say the first test
 within this particular category

0:00:20.320000 --> 0:00:28.360000
 in the OSWSDG, and that is, again, to
 be more specific testing the session

0:00:28.360000 --> 0:00:34.920000
 management schema, and what we're going
 to be exploring primarily as a

0:00:34.920000 --> 0:00:39.600000
 technique in this video practically
 is going to be cookie tampering, or

0:00:39.600000 --> 0:00:45.120000
 essentially analyzing, you know, collecting,
 analyzing, or reverse engineering

0:00:45.120000 --> 0:00:49.820000
 cookies, and then, of course, tampering
 with them to try and see whether

0:00:49.820000 --> 0:00:57.520000
 we're able to, you know, we're able to
 bypass authentication, for example,

0:00:57.520000 --> 0:01:03.060000
 but more importantly, or I should say,
 the underlying objective for this

0:01:03.060000 --> 0:01:10.200000
 particular video is going to be focused
 on giving you a better feel for,

0:01:10.200000 --> 0:01:16.240000
 you know, cookies, or, you know, essentially
 giving you tacit experience

0:01:16.240000 --> 0:01:18.320000
 with cookies or practical
 experience with cookies.

0:01:18.320000 --> 0:01:23.600000
 So, you know, you start familiarizing
 yourself with how they usually set,

0:01:23.600000 --> 0:01:27.640000
 how to reverse engineer them to a certain
 extent, of course, but to begin

0:01:27.640000 --> 0:01:33.120000
 with, I just want to introduce
 you to this particular test.

0:01:33.120000 --> 0:01:40.820000
 Again, this is sort of based on the
 WSDG, so the ID is WSDG, S-E-W-S-0

0:01:40.820000 --> 0:01:48.940000
-1. So, the Testing for Session Management
 schema test in the OAS web security

0:01:48.940000 --> 0:01:53.080000
 testing guide focuses on assessing
 the security of session management

0:01:53.080000 --> 0:01:55.020000
 in web applications.

0:01:55.020000 --> 0:01:58.680000
 This test ensures that session management
 mechanisms are implemented correctly

0:01:58.680000 --> 0:02:02.440000
 without exposing vulnerabilities that
 attackers could exploit to hijack,

0:02:02.440000 --> 0:02:06.300000
 manipulate, or misuse user sessions.

0:02:06.300000 --> 0:02:09.980000
 So, the primary objective of this test is
 to validate the design and robustness

0:02:09.980000 --> 0:02:14.260000
 of session management schema, the session
 management schema within, you

0:02:14.260000 --> 0:02:18.420000
 know, web application, which will obviously
 include session IDs and cookies,

0:02:18.420000 --> 0:02:22.540000
 which is why I sort of had to have
 that recap before getting to this,

0:02:22.540000 --> 0:02:25.760000
 where, you know, introduced you to
 session IDs and cookies and cookie

0:02:25.760000 --> 0:02:31.080000
 attributes. So, specifically, it examines
 or, you know, it allows you

0:02:31.080000 --> 0:02:35.140000
 to provide you the methodological way
 of examining how securely a web

0:02:35.140000 --> 0:02:39.920000
 application manages user sessions by
 analyzing things like these, you

0:02:39.920000 --> 0:02:42.780000
 know, session token creation, maintenance,
 and, of course, determination

0:02:42.780000 --> 0:02:48.080000
 process. But, you know, looking at
 it a bit more specifically, this is

0:02:48.080000 --> 0:02:53.540000
 derived from the actual, you know, the
 actual test description from the

0:02:53.540000 --> 0:02:57.260000
 WSDG, hence the reference there.

0:02:57.260000 --> 0:03:03.360000
 But the main steps of the attack pattern
 will revolve around cookie collection.

0:03:03.360000 --> 0:03:07.780000
 So, you know, collection of a sufficient
 number of cookie samples, cookie

0:03:07.780000 --> 0:03:11.920000
 reverse engineering, where you analyze
 the cookie generation algorithm,

0:03:11.920000 --> 0:03:15.900000
 the cookie generation algorithm, pardon
 me, cookie manipulation, where

0:03:15.900000 --> 0:03:19.400000
 you forge a valid cookie in
 order to perform the attack.

0:03:19.400000 --> 0:03:24.800000
 The last up of the attack might require
 a large number of attempts, so

0:03:24.800000 --> 0:03:28.760000
 depending on how the cookie is created,
 so, you know, this could be considered

0:03:28.760000 --> 0:03:31.020000
 a cookie brute force attack.

0:03:31.020000 --> 0:03:34.920000
 Now, the abridged version of the objectives
 within this particular test

0:03:34.920000 --> 0:03:39.220000
 revolve around, you know, gathering
 session tokens, so, you know, for

0:03:39.220000 --> 0:03:44.540000
 the same user and for different users
 where possible analyzing, and, you

0:03:44.540000 --> 0:03:48.500000
 know, analyze and ensure that enough
 randomness exists to stop session

0:03:48.500000 --> 0:03:50.020000
 forging attacks.

0:03:50.020000 --> 0:03:56.380000
 What that means is you generally start
 looking for, you generally start

0:03:56.380000 --> 0:04:07.780000
 testing, you know, there's a lack of
 randomness that sort of infers that

0:04:07.780000 --> 0:04:13.440000
 you are able to predict, let's say
 session IDs, which can help in, you

0:04:13.440000 --> 0:04:17.100000
 know, brute force attacks, or, you know,
 it can essentially help in forging

0:04:17.100000 --> 0:04:21.200000
 session IDs, etc.

0:04:21.200000 --> 0:04:24.420000
 And then, of course, modifying cookies
 that are not signed and contain

0:04:24.420000 --> 0:04:26.540000
 information that can be manipulated.

0:04:26.540000 --> 0:04:28.880000
 So, that's sort of an abridged version.

0:04:28.880000 --> 0:04:33.380000
 Now, diving deep, you know, diving
 deeper into the objectives and, you

0:04:33.380000 --> 0:04:37.180000
 know, providing you with a bit more
 depth here, we obviously have the

0:04:37.180000 --> 0:04:40.980000
 pros of identifying weaknesses in session
 in the session token structure.

0:04:40.980000 --> 0:04:44.900000
 So, you evaluate if the session token,
 which is usually going to be in

0:04:44.900000 --> 0:04:48.160000
 the form of a cookie, is predictable
 or contains patterns that could be

0:04:48.160000 --> 0:04:51.820000
 exploited to hijack or bypass sessions.

0:04:51.820000 --> 0:04:56.680000
 Then you test if the encoding, the encoding
 hashing or encryption methods

0:04:56.680000 --> 0:05:01.120000
 for session tokens are sufficiently robust
 to prevent reverse engineering,

0:05:01.120000 --> 0:05:04.200000
 which is going to be, you know, one aspect
 of the practical demonstration

0:05:04.200000 --> 0:05:05.880000
 that we'll walk through.

0:05:05.880000 --> 0:05:09.140000
 Secondly, ensure secure session handling.


0:05:09.140000 --> 0:05:12.480000
 So, confirm that session tokens are
 generated and managed according to

0:05:12.480000 --> 0:05:16.740000
 best practices, you know, including
 the regeneration of session tokens

0:05:16.740000 --> 0:05:20.840000
 upon login and logout to prevent
 session fixation attacks.

0:05:20.840000 --> 0:05:24.920000
 So, basically, you know, what I'm giving
 you here is I'm sort of giving

0:05:24.920000 --> 0:05:30.940000
 you or describing the tests, you know,
 you may think of it from a defensive

0:05:30.940000 --> 0:05:34.680000
 point of view, but there's a good reason
 for this, because at the end,

0:05:34.680000 --> 0:05:39.660000
 I sort of mentioned the attack or the
 vulnerability for each of these

0:05:39.660000 --> 0:05:40.800000
 objectives, let's say.

0:05:40.800000 --> 0:05:44.220000
 So, when it comes down to the token
 structure, the primary thing you're

0:05:44.220000 --> 0:05:48.720000
 going to do is try and reverse engineer
 a session ID or a token.

0:05:48.720000 --> 0:05:54.680000
 In the case of secure session handling,
 you're really going to be testing

0:05:54.680000 --> 0:05:58.060000
 for fixation session fixation
 attacks, right?

0:05:58.060000 --> 0:06:02.460000
 And then moving on, testing for
 authorization control failures.

0:06:02.460000 --> 0:06:06.820000
 So, you're essentially trying to identify
 sensitive informational rules.

0:06:06.820000 --> 0:06:10.860000
 For example, user privileges are embedded
 within cookies in an accessible

0:06:10.860000 --> 0:06:12.580000
 or modifiable format.

0:06:12.580000 --> 0:06:17.400000
 So, what you're trying to do here, you
 know, is, you know, in this case,

0:06:17.400000 --> 0:06:20.640000
 ensure that the server does not rely solely
 on client-side cookie information

0:06:20.640000 --> 0:06:25.500000
 for access control decisions and enforces
 authorization checks on the

0:06:25.500000 --> 0:06:31.600000
 server side. Then you have evaluation of
 the session expiration and invalidation

0:06:31.600000 --> 0:06:35.240000
 mechanism. So, you ensure that sessions
 expire after a reasonable period

0:06:35.240000 --> 0:06:39.020000
 of inactivity and that they're, you
 know, they're invalidated on logout

0:06:39.020000 --> 0:06:43.080000
 or session timeout and the key things
 you're going to be focusing on here

0:06:43.080000 --> 0:06:47.740000
 is the presence or the lack thereof
 of cookie parameters or attributes

0:06:47.740000 --> 0:06:52.520000
 like max age, expires, HTTP only secure,
 which we explored in the previous

0:06:52.520000 --> 0:06:55.140000
 video and of course, same site.

0:06:55.140000 --> 0:06:58.340000
 So, you know, checking for their presence
 and then seeing whether they're

0:06:58.340000 --> 0:07:02.180000
 appropriately configured or looking for
 vulnerabilities or misconfigurations

0:07:02.180000 --> 0:07:07.440000
 with their configuration of,
 you know, values as it were.

0:07:07.440000 --> 0:07:11.520000
 And then of course, the tests that you typically
 perform here or the vulnerabilities

0:07:11.520000 --> 0:07:16.580000
 are going to be, you know, session
 hijacking, cross-site scripting.

0:07:16.580000 --> 0:07:19.400000
 And of course, verifying the
 secure cookie transmission.

0:07:19.400000 --> 0:07:22.620000
 So, you confirm that session cookies
 are transmitted only over secure

0:07:22.620000 --> 0:07:26.920000
 channels. It's pretty clear what cookie
 attribute you're going to be looking

0:07:26.920000 --> 0:07:32.480000
 for. That's going to be the HTTP only,
 which not only applies to, you

0:07:32.480000 --> 0:07:39.920000
 know, the actual security of cookies
 in transit, but more so, you know,

0:07:39.920000 --> 0:07:44.080000
 this also is quite relevant when you're
 talking about cross-site scripting

0:07:44.080000 --> 0:07:51.240000
 attacks, right? So, I've now listed
 or I've sort of broken the previous

0:07:51.240000 --> 0:07:55.660000
 three slides down into a table that'll
 help you understand what exactly

0:07:55.660000 --> 0:07:58.780000
 you're doing or testing for
 and the vulnerability.

0:07:58.780000 --> 0:08:02.340000
 So, firstly, we have a
 predictable session ID.

0:08:02.340000 --> 0:08:05.660000
 So, you analyze the randomness of session
 tokens to see whether they are

0:08:05.660000 --> 0:08:09.040000
 indeed random, which is a good thing
 or whether they can be, let's say,

0:08:09.040000 --> 0:08:12.880000
 reverse engineered or they
 can be forged, if you will.

0:08:12.880000 --> 0:08:16.440000
 So, attackers could guess or generate
 valid session tokens.

0:08:16.440000 --> 0:08:18.920000
 That's what the vulnerability
 typically is there.

0:08:18.920000 --> 0:08:20.540000
 You then have session fixation.

0:08:20.540000 --> 0:08:25.960000
 So, you know, attackers can fix a session
 ID and take over the session

0:08:25.960000 --> 0:08:27.620000
 after the user authenticates.

0:08:27.620000 --> 0:08:29.780000
 Then you have session expiration
 and termination.

0:08:29.780000 --> 0:08:33.580000
 This is, you know, where you verify if
 the session expires after a specific

0:08:33.580000 --> 0:08:35.700000
 timeout and log out.

0:08:35.700000 --> 0:08:39.680000
 And of course, the vulnerability there
 is that if sessions that do not

0:08:39.680000 --> 0:08:42.760000
 expire or terminate can be
 reused by the attackers.

0:08:42.760000 --> 0:08:44.260000
 Session hijacking.

0:08:44.260000 --> 0:08:48.400000
 So, you know, you replay session cookies
 from different devices or locations

0:08:48.400000 --> 0:08:50.180000
 or from different users.

0:08:50.180000 --> 0:08:54.740000
 And attackers can essentially hijack
 sessions if the tokens are not bound

0:08:54.740000 --> 0:08:57.760000
 to user specific attributes.

0:08:57.760000 --> 0:09:02.200000
 We then have the session
 cookie security flags.

0:09:02.200000 --> 0:09:06.860000
 So, you know, checking for cookie attributes
 specific to session security

0:09:06.860000 --> 0:09:13.680000
 if you, if that makes sense.

0:09:13.680000 --> 0:09:18.260000
 And the point here is all the vulnerability
 that typically occurs specifically

0:09:18.260000 --> 0:09:21.980000
 with in regards to this test is that,
 you know, missing flags or attributes

0:09:21.980000 --> 0:09:25.740000
 make cookies vulnerable to cross-site
 scripting, cross-site request forgery

0:09:25.740000 --> 0:09:29.820000
 and of course, man in the middle
 attacks or interception attacks.

0:09:29.820000 --> 0:09:32.960000
 Then we have the session timeout testing
 where you test for, you know,

0:09:32.960000 --> 0:09:35.240000
 proper idle session expiration.

0:09:35.240000 --> 0:09:38.720000
 So, long-lived sessions increase the
 risk of session reused by attackers.

0:09:38.720000 --> 0:09:39.780000
 That's the vulnerability.

0:09:39.780000 --> 0:09:42.920000
 And then of course, session
 token exposure in URL.

0:09:42.920000 --> 0:09:46.640000
 So, you ensure the session tokens
 are not present in the URLs.

0:09:46.640000 --> 0:09:50.120000
 And of course, the vulnerability there
 is tokens in URLs can be exposed

0:09:50.120000 --> 0:09:54.160000
 through referrer, headers,
 logs and browser history.

0:09:54.160000 --> 0:09:57.740000
 Now, that brings us to, you know, cookie
 reverse engineering and tampering,

0:09:57.740000 --> 0:10:02.900000
 which is sort of the objective of this
 video, the technique that we'll

0:10:02.900000 --> 0:10:06.360000
 be focusing on. So, what is
 cookie reverse engineering?

0:10:06.360000 --> 0:10:10.340000
 So, cookie reverse engineering and
 manipulation in this case refers to

0:10:10.340000 --> 0:10:14.480000
 analyzing and modifying session cookies
 to identify potential vulnerabilities

0:10:14.480000 --> 0:10:17.440000
 in the application's session management.

0:10:17.440000 --> 0:10:22.480000
 This technique aims to understand how
 session cookies are structured,

0:10:22.480000 --> 0:10:26.700000
 encoded and protected, and whether manipulating
 these cookies could bypass

0:10:26.700000 --> 0:10:30.280000
 security controls or gain
 unauthorized access.

0:10:30.280000 --> 0:10:33.820000
 So, in terms of the cookie structure
 and encoding, which is typically

0:10:33.820000 --> 0:10:38.460000
 what, you know, we would consider reverse
 engineering, you know, before

0:10:38.460000 --> 0:10:41.700000
 we actually get into that reverse engineering,
 if you're not familiar

0:10:41.700000 --> 0:10:45.620000
 with it, involves examining the
 structure of session cookies.

0:10:45.620000 --> 0:10:49.360000
 And in this case, the description is
 set to match or to be in alignment

0:10:49.360000 --> 0:10:52.880000
 with reverse engineering cookies.

0:10:52.880000 --> 0:10:56.180000
 So, reverse engineering involves examining
 the structure of session cookies

0:10:56.180000 --> 0:11:00.520000
 to determine if they contain any predictable
 patterns encoded information

0:11:00.520000 --> 0:11:05.600000
 or identifiable user attributes, such
 as the username session ID or roles,

0:11:05.600000 --> 0:11:09.860000
 which we've explored previously when
 we were, you know, when we created

0:11:09.860000 --> 0:11:15.480000
 that cookie and set the value to logged
 in is equal to yes in one of the

0:11:15.480000 --> 0:11:16.680000
 previous videos.

0:11:16.680000 --> 0:11:22.620000
 That's really what we would consider
 forging or tampering, if you will.

0:11:22.620000 --> 0:11:26.980000
 But the bottom line is that encoding scheme
 such as base 64 or URL encoding

0:11:26.980000 --> 0:11:29.720000
 often used for readability
 or storage efficiency.

0:11:29.720000 --> 0:11:33.740000
 However, decoding these cookies can
 reveal sensitive information if they

0:11:33.740000 --> 0:11:37.420000
 aren't properly encrypted, exposing data
 that could help attackers identify

0:11:37.420000 --> 0:11:40.940000
 vulnerabilities or help you
 identify vulnerabilities.

0:11:40.940000 --> 0:11:43.880000
 We then have the manipulation
 or tampering.

0:11:43.880000 --> 0:11:47.140000
 So, once you've reversed engineer them,
 if you can reverse engineer them,

0:11:47.140000 --> 0:11:51.200000
 you can then modify certain values in
 cookies that indicate user privileges,

0:11:51.200000 --> 0:11:53.440000
 roles or access levels.

0:11:53.440000 --> 0:11:57.540000
 An example of this is if a cookie parameter
 controls user access level,

0:11:57.540000 --> 0:12:01.920000
 so you know, role equals guest or admin
 equals yes, for example, changing

0:12:01.920000 --> 0:12:05.600000
 it to role equals admin might grant unauthorized
 privileges if the application

0:12:05.600000 --> 0:12:08.340000
 fails to validate the role server side.

0:12:08.340000 --> 0:12:14.420000
 So essentially tying the server side
 fails to actually correlate your

0:12:14.420000 --> 0:12:17.960000
 session ID with the roles that
 you're supposed to have.

0:12:17.960000 --> 0:12:20.860000
 You know, you're able to pretty much
 elevate your privileges, if that

0:12:20.860000 --> 0:12:24.500000
 makes sense, or bypass authentication
 all together.

0:12:24.500000 --> 0:12:29.760000
 You then have user, you know, within
 tampering or manipulation, use ID

0:12:29.760000 --> 0:12:31.200000
 and session fixation.

0:12:31.200000 --> 0:12:35.240000
 So if the session cookie includes user
 specific information, like a use

0:12:35.240000 --> 0:12:40.360000
 ID, this is something that will be
 exploring in the session hijack in

0:12:40.360000 --> 0:12:46.400000
 fixation video. But, you know, if the
 session cookie includes user specific

0:12:46.400000 --> 0:12:50.440000
 information like a use ID or username,
 attackers might change these values

0:12:50.440000 --> 0:12:54.520000
 to another user's ID to see if it
 grants access to that account.

0:12:54.520000 --> 0:12:57.840000
 In the case of session hijacking, if
 the session token is predictable

0:12:57.840000 --> 0:13:03.320000
 or reused like a static token, attackers
 may copy or alter it to impersonate

0:13:03.320000 --> 0:13:05.700000
 a legitimate user.

0:13:05.700000 --> 0:13:09.660000
 All right, so with that being said
 now, it's time to sort of show you

0:13:09.660000 --> 0:13:13.480000
 what this looks like or give your
 hands on experience with this.

0:13:13.480000 --> 0:13:18.360000
 And in order to do this, we are going
 to be utilizing a practical lab.

0:13:18.360000 --> 0:13:21.800000
 So, this video has a lab
 associated with it.

0:13:21.800000 --> 0:13:27.440000
 And I'm going to start it up and I'll
 see you there in a couple of seconds.

0:13:27.440000 --> 0:13:32.660000
 All right, so I am currently
 within the lab environment.

0:13:32.660000 --> 0:13:35.960000
 And as you can see, you'll be provided
 with access to a preconfigured

0:13:35.960000 --> 0:13:38.600000
 Kali Linux system within your browser.

0:13:38.600000 --> 0:13:42.020000
 And the great thing is that the target
 web application secure bank, which

0:13:42.020000 --> 0:13:45.880000
 we've actually used before, although
 this is a slightly different version,

0:13:45.880000 --> 0:13:49.160000
 is going to be opened up for
 you in Firefox already.

0:13:49.160000 --> 0:13:53.520000
 So, as you can see, secure bank is
 fairly easy to understand in terms

0:13:53.520000 --> 0:13:54.900000
 of what we are targeting.

0:13:54.900000 --> 0:13:58.800000
 We have a login form with, you know, for
 good password form as well, custom

0:13:58.800000 --> 0:14:01.620000
 ID is, you know, pretty much.

0:14:01.620000 --> 0:14:05.420000
 And we can then, you know,
 try and sign in.

0:14:05.420000 --> 0:14:11.620000
 So, this lab provides you with access
 to the credentials we'll be using

0:14:11.620000 --> 0:14:17.440000
 for this test. The credentials are,
 you know, James at secbank.com, that

0:14:17.440000 --> 0:14:22.460000
 being the email or username, if you
 will, and the password, you know,

0:14:22.460000 --> 0:14:25.040000
 in this particular case, we'll
 just be password one.

0:14:25.040000 --> 0:14:32.120000
 Now, before we do that, I'm going to
 just proxy all my traffic, you know,

0:14:32.120000 --> 0:14:32.820000
 through Burp Suite.

0:14:32.820000 --> 0:14:39.940000
 And I'm going to click on the Foxy proxy
 add-on and just click on do that.

0:14:39.940000 --> 0:14:42.640000
 I mean proxy traffic to
 the Burp Suite proxy.

0:14:42.640000 --> 0:14:46.380000
 So, I'll open up Burp Suite now, and
 I'll give this a couple of seconds

0:14:46.380000 --> 0:14:51.420000
 to start up. So, there we are, just
 going to create a temporary project.

0:14:51.420000 --> 0:14:57.040000
 And so, we'll take a couple
 of seconds here.

0:14:57.040000 --> 0:15:03.880000
 And now, what we want to do is,
 let me close that up there.

0:15:03.880000 --> 0:15:07.740000
 And I'm going to go into user options,
 display, just make this a little

0:15:07.740000 --> 0:15:13.520000
 bit bigger. So, you guys can actually
 see the requests, the detail that

0:15:13.520000 --> 0:15:17.380000
 is deserved. So, we're
 going to the proxy.

0:15:17.380000 --> 0:15:20.660000
 I'm just going to disable intercept
 for a second, and I'm just going to

0:15:20.660000 --> 0:15:22.340000
 refresh the page.

0:15:22.340000 --> 0:15:24.500000
 Just want to get a couple
 of requests in there.

0:15:24.500000 --> 0:15:26.580000
 Let's take a look at the requests.

0:15:26.580000 --> 0:15:34.420000
 HTTP history, we can see there's a few,
 we have a few gets here, so login

0:15:34.420000 --> 0:15:36.320000
 and some JavaScript libraries.

0:15:36.320000 --> 0:15:40.600000
 So, get login, nothing there.

0:15:40.600000 --> 0:15:42.740000
 Let's see what the response looks like.

0:15:42.740000 --> 0:15:44.220000
 This is very important.

0:15:44.220000 --> 0:15:46.940000
 So, you know, I already covered
 this in the cookie.

0:15:46.940000 --> 0:15:51.920000
 Cookie is in cookie attributes video,
 but we can see right over here,

0:15:51.920000 --> 0:15:55.920000
 the general request here,
 do we have any set cookie?

0:15:55.920000 --> 0:15:58.120000
 No, it doesn't look like we do.

0:15:58.120000 --> 0:16:05.060000
 We go in here, response, and
 we don't have any cookie yet.

0:16:05.060000 --> 0:16:10.260000
 Okay, so, go back into intercept,
 enable it now, we'll go in here.

0:16:10.260000 --> 0:16:17.980000
 So, the credentials are james at secbank
.com, and then we use password

0:16:17.980000 --> 0:16:23.800000
 one. Okay, so, just want to
 see what this looks like.

0:16:23.800000 --> 0:16:28.200000
 All right, so in burp, first thing
 we get, or when we click login, we

0:16:28.200000 --> 0:16:34.940000
 can see there's an options request,
 right, which is not that strange,

0:16:34.940000 --> 0:16:37.560000
 but you know, probably pointing, yes.

0:16:37.560000 --> 0:16:41.980000
 So, the host is port 8000, and
 then the referrer is port 5000.

0:16:41.980000 --> 0:16:45.220000
 So, most likely being sent
 to an API endpoint.

0:16:45.220000 --> 0:16:48.300000
 Okay, so, we are just going
 to click on forward.

0:16:48.300000 --> 0:16:51.160000
 Now, before I proceed, it's important
 to know that the credentials that

0:16:51.160000 --> 0:16:54.920000
 I specified, that are specified in
 the lab documentation, or the, you

0:16:54.920000 --> 0:16:59.300000
 know, that I essentially told you that
 being james at secbank.com, and

0:16:59.300000 --> 0:17:00.960000
 password one, are legitimate.

0:17:00.960000 --> 0:17:03.080000
 However, let's forward the options.

0:17:03.080000 --> 0:17:06.680000
 We should have a post, so we can see,
 yeah, the most likely this an API

0:17:06.680000 --> 0:17:10.420000
 endpoint, because we can see
 the curly braces there.

0:17:10.420000 --> 0:17:12.400000
 But really, it doesn't matter.

0:17:12.400000 --> 0:17:18.120000
 If we take a look at the HTTP history
 here, just for a second, for the

0:17:18.120000 --> 0:17:21.960000
 options, no cookie yet.

0:17:21.960000 --> 0:17:26.440000
 This one is still pending, but let's
 go into intercept, and let's just

0:17:26.440000 --> 0:17:30.600000
 forward it. We go back into the web application,
 we can see that, although

0:17:30.600000 --> 0:17:33.860000
 we were able to log in, the objective
 here is to get a flag.

0:17:33.860000 --> 0:17:39.260000
 So, you may be asking, well, how exactly
 are we going to get a flag?

0:17:39.260000 --> 0:17:43.660000
 Well, let's go back into burp suite
 here, and into HTTP history, because

0:17:43.660000 --> 0:17:46.400000
 there's a few things that
 I really want to cover.

0:17:46.400000 --> 0:17:52.580000
 So, if we take a look at the response
 here, for the post request, we send

0:17:52.580000 --> 0:17:55.980000
 that, have the credentials, let me
 just go back here, let me drag that

0:17:55.980000 --> 0:18:02.240000
 there. We can see after authentication,
 and we authenticated successfully,

0:18:02.240000 --> 0:18:06.720000
 the only thing is, you know, we didn't
 get a flag, which is fine, but

0:18:06.720000 --> 0:18:08.660000
 that's not the objective of this video.

0:18:08.660000 --> 0:18:12.660000
 The objective of this video is going
 to be focused on this cookie here

0:18:12.660000 --> 0:18:18.560000
 that gives us a session ID that looks
 quite interesting, and we have the

0:18:18.560000 --> 0:18:23.300000
 path attribute set, which
 is also quite important.

0:18:23.300000 --> 0:18:31.540000
 Now, this particular session ID really
 looks like it's base 64 encoded

0:18:31.540000 --> 0:18:35.840000
 because of the double equal
 sign at the end there.

0:18:35.840000 --> 0:18:43.940000
 Base 64 is an encoding schema or system
 that's fairly easy to decode,

0:18:43.940000 --> 0:18:47.040000
 so we can actually send that to decoder.

0:18:47.040000 --> 0:18:52.200000
 And in here, if I just go and decode
 this as base 64, we can see that

0:18:52.200000 --> 0:18:58.700000
 included in the session ID or the encoded
 session ID, you know, which

0:18:58.700000 --> 0:19:03.360000
 was not actually encrypted or anything,
 it was just encoded base 64.

0:19:03.360000 --> 0:19:08.140000
 For reasons I explained in the slides,
 we can see that logged in is equal

0:19:08.140000 --> 0:19:11.020000
 to true, but admin is equal to false.

0:19:11.020000 --> 0:19:14.720000
 So, I'm sort of, you know, this point,
 I think you're getting the ideas

0:19:14.720000 --> 0:19:16.740000
 to what we're going to be required to do.


0:19:16.740000 --> 0:19:19.720000
 So, this, what we've just done is what
 you would call very basic reverse

0:19:19.720000 --> 0:19:23.320000
 engineering of the cookie.

0:19:23.320000 --> 0:19:28.120000
 And what we've actually been able to
 verify if this was a legitimate pen

0:19:28.120000 --> 0:19:34.020000
 test is that, while, you know, the session
 ID looks quite ambiguous, or

0:19:34.020000 --> 0:19:43.880000
 looks quite secure, if you, you know,
 if you are not really coded, but

0:19:43.880000 --> 0:19:46.680000
 of course that's not really common
 in modern web applications.

0:19:46.680000 --> 0:19:52.740000
 Regardless of the fact that you may
 be sending a session ID in base 64

0:19:52.740000 --> 0:19:57.540000
 and coded format, that's not really,
 the important thing is the bottom

0:19:57.540000 --> 0:20:01.740000
 line is that ideally this should
 have been encrypted.

0:20:01.740000 --> 0:20:06.080000
 You know, only the server should be
 able to decrypt this, because, you

0:20:06.080000 --> 0:20:10.760000
 know, it has your role information, which
 again, I covered in the slides.

0:20:10.760000 --> 0:20:14.660000
 So logged in true is actually
 not that important.

0:20:14.660000 --> 0:20:17.540000
 It's more so admin equals false here.

0:20:17.540000 --> 0:20:19.800000
 So what does that tell us we can do?

0:20:19.800000 --> 0:20:31.320000
 Well, what we can do is, let's
 go ahead and modify this.

0:20:31.320000 --> 0:20:37.060000
 So I'm going to say admin, you know,
 is going to be equal to true, right?

0:20:37.060000 --> 0:20:39.920000
 Obviously, we need to have that there.

0:20:39.920000 --> 0:20:44.100000
 And then we are going to
 encode this as base 64.

0:20:44.100000 --> 0:20:47.560000
 Okay, so that'll be our new
 session ID, if you will.

0:20:47.560000 --> 0:20:50.140000
 So I'm just going to copy this here.

0:20:50.140000 --> 0:20:56.560000
 And now just going to go into leafpad,
 or my text editor, and just keep

0:20:56.560000 --> 0:21:00.620000
 that there ready and handy.

0:21:00.620000 --> 0:21:03.220000
 Okay, so we're going to intercept here.

0:21:03.220000 --> 0:21:05.100000
 Looks like we have some Firefox down.

0:21:05.100000 --> 0:21:06.960000
 Let me just drop the intercept there.

0:21:06.960000 --> 0:21:11.080000
 Let me just drop that particular
 one or disable intercept there.

0:21:11.080000 --> 0:21:23.760000
 What we want to do now, let's enable
 intercept and let's, let's for that,

0:21:23.760000 --> 0:21:27.860000
 let's log out. Okay, so I'm
 going to click on log out.

0:21:27.860000 --> 0:21:31.400000
 Now you can see it still
 maintains the session ID.

0:21:31.400000 --> 0:21:35.140000
 In this particular case, the web app
 doesn't give you a session ID when

0:21:35.140000 --> 0:21:38.320000
 you're on authenticated only gives
 you one once you authenticate.

0:21:38.320000 --> 0:21:45.700000
 Okay, so what we can do actually with
 this request is instead of saying

0:21:45.700000 --> 0:21:55.100000
 log out, because you remember we can
 just set the, instead of saying log

0:21:55.100000 --> 0:22:01.040000
 out, if we go back to the decoder, I
 remember that the path, one second,

0:22:01.040000 --> 0:22:07.900000
 sorry, proxy, HTTP history, we can see
 that the cookie also has the path

0:22:07.900000 --> 0:22:10.740000
 set to just the root of the web server.

0:22:10.740000 --> 0:22:20.420000
 So if we go into intercept here, what
 we can do is just set this, instead

0:22:20.420000 --> 0:22:27.680000
 of saying log out, just set the, we can
 just set the endpoint to the root

0:22:27.680000 --> 0:22:32.320000
 of the web server and then we've modified
 the cookie, we've encoded it

0:22:32.320000 --> 0:22:34.500000
 in base 64 again.

0:22:34.500000 --> 0:22:38.280000
 So now I can just copy this here.

0:22:38.280000 --> 0:22:43.380000
 And what we want to do is modify
 the session ID here.

0:22:43.380000 --> 0:22:48.540000
 Sorry, one second, why can't
 I modify that here?

0:22:48.540000 --> 0:22:54.220000
 There we go. Okay, so I'm just going
 to modify that there to the new one

0:22:54.220000 --> 0:22:58.060000
 that essentially gives
 us admin privileges.

0:22:58.060000 --> 0:23:03.280000
 I don't think we need to
 do anything else really.

0:23:03.280000 --> 0:23:10.660000
 But if we forward this now, in this
 case, it still says no flag for us,

0:23:10.660000 --> 0:23:15.920000
 it actually should have given us a
 flag, let's go into HTTP history.

0:23:15.920000 --> 0:23:17.640000
 When did we have that?

0:23:17.640000 --> 0:23:18.920000
 Does it log out?

0:23:18.920000 --> 0:23:21.300000
 I did a request.

0:23:21.300000 --> 0:23:24.440000
 That's very interesting.

0:23:24.440000 --> 0:23:32.920000
 Log out, intercept.

0:23:32.920000 --> 0:23:42.380000
 Let me just really show going
 to HTTP history, log out.

0:23:42.380000 --> 0:23:45.020000
 Why is it not giving us a response?

0:23:45.020000 --> 0:23:46.160000
 That's very interesting.

0:23:46.160000 --> 0:23:50.460000
 So intercept, we go ahead
 and log out here again.

0:23:50.460000 --> 0:23:54.400000
 So get, I just change that there.

0:23:54.400000 --> 0:24:02.280000
 And then we set the, yeah,
 that should be fine.

0:24:02.280000 --> 0:24:06.280000
 And we just set the cookie.

0:24:06.280000 --> 0:24:15.860000
 Let's go ahead and change this
 again, modify the session ID.

0:24:15.860000 --> 0:24:27.560000
 Once again. Okay, to be that there.

0:24:27.560000 --> 0:24:35.960000
 All right, so we'll probably
 be wise to use the repeater.

0:24:35.960000 --> 0:24:41.240000
 But if we go into the proxy HTTP history,
 log out, we have the response

0:24:41.240000 --> 0:24:45.620000
 now. And there we are, we get the flag
 there with, you know, we're pretty

0:24:45.620000 --> 0:24:48.940000
 much logging out, but really doesn't
 matter if we wanted the flag.

0:24:48.940000 --> 0:24:55.140000
 The bottom line is, you know, if we use
 the cookie, I don't think we have

0:24:55.140000 --> 0:25:00.120000
 a cookie manager here, but let's say,
 you know, just let's just reload

0:25:00.120000 --> 0:25:06.220000
 this again, intercept, and yeah,
 so log in, that's fine.

0:25:06.220000 --> 0:25:08.020000
 We don't need a cookie here.

0:25:08.020000 --> 0:25:16.380000
 Let's go ahead and say, you know,
 James at secbank.com password one.

0:25:16.380000 --> 0:25:18.880000
 And I'm just going to log in now.

0:25:18.880000 --> 0:25:22.900000
 That's the options post over here.

0:25:22.900000 --> 0:25:24.760000
 Let's try and modify it here.

0:25:24.760000 --> 0:25:26.580000
 That would be probably interesting.

0:25:26.580000 --> 0:25:28.940000
 I don't think it should work.

0:25:28.940000 --> 0:25:39.660000
 Let's go ahead and see that, that
 doesn't look like it one here.

0:25:39.660000 --> 0:25:43.960000
 Response here, we got the flag again,
 but yeah, it doesn't look like it's

0:25:43.960000 --> 0:25:47.000000
 displayed within the web application.

0:25:47.000000 --> 0:25:51.500000
 Anyway, the bottom line is all the, you
 know, sort of a highlight of what

0:25:51.500000 --> 0:25:56.580000
 I wanted to show you was the fact that
 cookies and session IDs really

0:25:56.580000 --> 0:25:59.920000
 can be decoded or reverse engineered.

0:25:59.920000 --> 0:26:05.620000
 And if you are able to do that, they can
 have potentially useful parameters

0:26:05.620000 --> 0:26:10.440000
 that you can modify to either, you
 know, bypass authentication, we saw

0:26:10.440000 --> 0:26:17.060000
 previously, or more importantly,
 elevate your privileges.

0:26:17.060000 --> 0:26:20.740000
 The bottom line is that this is,
 you know, highly insecure.

0:26:20.740000 --> 0:26:24.140000
 With that being said, that brings us to
 the end of the practical demonstration

0:26:24.140000 --> 0:26:26.780000
 section of this video.

0:26:26.780000 --> 0:26:31.360000
 All right, so that was the process of
 testing the session management schema,

0:26:31.360000 --> 0:26:35.480000
 more specifically looking at cookie
 tampering or manipulation.

0:26:35.480000 --> 0:26:39.340000
 We also took a look at reverse engineering,
 this very basic, but just

0:26:39.340000 --> 0:26:44.160000
 wanted to use this as a way to introduce
 you to this particular test and

0:26:44.160000 --> 0:26:48.320000
 more importantly, highlight the various
 things that can be done or the

0:26:48.320000 --> 0:26:52.040000
 various, you know, tests or objectives,
 vulnerabilities that you, you

0:26:52.040000 --> 0:26:56.220000
 know, typically find when, again, testing
 the session management schema.

0:26:56.220000 --> 0:26:59.660000
 With that being said, we're going to
 be exploring other techniques in

0:26:59.660000 --> 0:27:05.520000
 the upcoming videos, for example,
 session fixation and hijacking.

0:27:05.520000 --> 0:27:09.000000
 And hopefully through that, you're
 able to get a better understanding

0:27:09.000000 --> 0:27:11.360000
 of all the vulnerabilities
 contained therein.

0:27:11.360000 --> 0:27:14.940000
 So that being said, that brings
 us to the end of this video.

0:27:14.940000 --> 0:27:17.460000
 And I'll be seeing you in the next video.