WEBVTT 0:00:03.660000 --> 0:00:09.300000 Hello everyone and welcome to the session management section of this course. 0:00:09.300000 --> 0:00:14.620000 To kick things off before we actually get into session management testing, 0:00:14.620000 --> 0:00:17.260000 we need to understand a couple of important things. 0:00:17.260000 --> 0:00:21.620000 Again, this is stuff that you should already be familiar with and that 0:00:21.620000 --> 0:00:27.140000 we've covered before in the WPT learning path or certification. 0:00:27.140000 --> 0:00:32.340000 But nonetheless, I think it's important to revisit it before we get into 0:00:32.340000 --> 0:00:36.700000 the actual session testing, session management testing process. 0:00:36.700000 --> 0:00:41.840000 And we will go through the tests outlined in the WSDG to essentially serve 0:00:41.840000 --> 0:00:43.620000 as a general methodology. 0:00:43.620000 --> 0:00:48.320000 Now, we've already covered session management within this course specifically 0:00:48.320000 --> 0:00:58.640000 in an earlier session management, but sort of diving a little bit deeper 0:00:58.640000 --> 0:01:05.580000 into it and more specifically into session IDs, which I think are very 0:01:05.580000 --> 0:01:11.440000 important or at least understanding how session IDs relate to session 0:01:11.440000 --> 0:01:17.760000 management. So to kick things off, let's just again very quickly revisit 0:01:17.760000 --> 0:01:20.420000 session management in the event you've forgotten. 0:01:20.420000 --> 0:01:24.880000 So in the context of web application, session management is the process 0:01:24.880000 --> 0:01:29.780000 of creating, maintaining and securing a user session after they authenticate, 0:01:29.780000 --> 0:01:33.980000 right? And a session represents a temporary continuous interaction between 0:01:33.980000 --> 0:01:38.740000 the user and the application, allowing the user to access resources and 0:01:38.740000 --> 0:01:42.720000 maintain an active state without re -authenticating on each request. 0:01:42.720000 --> 0:01:48.820000 Now, since HTTP, which is the protocol used by web applications, is stateless, 0:01:48.820000 --> 0:01:52.220000 session management is essential to track and maintain user identity across 0:01:52.220000 --> 0:01:53.420000 multiple requests. 0:01:53.420000 --> 0:01:56.800000 And remember the analogy I gave you when we covered session management 0:01:56.800000 --> 0:02:03.580000 earlier in this course, the analogy being the ticket gate at a concert 0:02:03.580000 --> 0:02:10.100000 and how the wristband that is put onto you is sort of a session ID, if 0:02:10.100000 --> 0:02:13.740000 you will. And the fact that, you know, I also emphasized in that analogy 0:02:13.740000 --> 0:02:19.720000 the temporary nature, the concert through the same gate you came in, the 0:02:19.720000 --> 0:02:24.780000 wristband is, you know, cut off your finger, not your finger, your wrist 0:02:24.780000 --> 0:02:28.280000 with a pair of scissors and you can get back in. 0:02:28.280000 --> 0:02:33.360000 But again, that was kind of a pedantic analogy, but hopefully it made 0:02:33.360000 --> 0:02:36.260000 sense. So, you know, just wanted to revisit it. 0:02:36.260000 --> 0:02:41.460000 And of course, I outlined this same diagram or flow chart to sort of show 0:02:41.460000 --> 0:02:42.200000 you what happened. 0:02:42.200000 --> 0:02:46.040000 So, we have you, the user, the web app and then the database, the backend 0:02:46.040000 --> 0:02:49.680000 database, which is typically required, not really referring to the type, 0:02:49.680000 --> 0:02:55.460000 it can be a SQL database or, sorry, a relational database or a NoSQL database 0:02:55.460000 --> 0:02:57.120000 doesn't really matter. 0:02:57.120000 --> 0:03:00.140000 The bottom line is every web application that, again, has authentication 0:03:00.140000 --> 0:03:05.080000 needs a backend that stores credentials, but more importantly, a backend 0:03:05.080000 --> 0:03:08.680000 that is actually queryable, which means, you know, that the web app can 0:03:08.680000 --> 0:03:11.220000 actually fetch all verified data anyway. 0:03:11.220000 --> 0:03:14.860000 So, you log in with your credentials, your credentials are then verified, 0:03:14.860000 --> 0:03:16.960000 you know, against what is in the database. 0:03:16.960000 --> 0:03:21.700000 If they exist, authentication is successful if not, authentication fails, 0:03:21.700000 --> 0:03:25.220000 and you know, the user ID fails to match or the password or whatever, 0:03:25.220000 --> 0:03:28.780000 you know, you're not able to log in successfully. 0:03:28.780000 --> 0:03:32.920000 But if it is successful or your credentials do exist and they are valid, 0:03:32.920000 --> 0:03:36.420000 then authentication is successful and then your web application creates 0:03:36.420000 --> 0:03:39.540000 a session ID and stores it in a cookie or token. 0:03:39.540000 --> 0:03:45.380000 Now, we'll be exploring token-based authentication in the upcoming section 0:03:45.380000 --> 0:03:48.780000 of this particular course. 0:03:48.780000 --> 0:03:51.880000 But before we do that, we also have to touch on cookies. 0:03:51.880000 --> 0:03:54.700000 So, we're starting off with session IDs in the next video, cookies, then 0:03:54.700000 --> 0:03:58.900000 we'll get into session management testing, then after that, we'll get 0:03:58.900000 --> 0:04:02.340000 into token-based authentication and, you know, sort of apply the same 0:04:02.340000 --> 0:04:07.140000 methodology, authentication testing as well as session management testing, 0:04:07.140000 --> 0:04:10.000000 but now, you know, with a focus on tokens because I think they are quite 0:04:10.000000 --> 0:04:13.880000 important. So, bottom line is a session ID is created and then it sends 0:04:13.880000 --> 0:04:16.000000 it to you or your browser. 0:04:16.000000 --> 0:04:21.740000 And then when you make a request, your session ID is included and then, 0:04:21.740000 --> 0:04:24.560000 you know, there's some validation that goes on with it. 0:04:24.560000 --> 0:04:28.620000 If the cookie let's say is still valid or your session ID is still valid, 0:04:28.620000 --> 0:04:31.580000 then you're able to browse the, you know, the web application of the web 0:04:31.580000 --> 0:04:36.980000 page for a temporary amount of time until the cookie is invalidated for 0:04:36.980000 --> 0:04:40.440000 whatever reason, either through logging out or, you know, whatever. 0:04:40.440000 --> 0:04:43.360000 But, you know, the bottom line is you're able to pretty much navigate 0:04:43.360000 --> 0:04:44.800000 around the web application. 0:04:44.800000 --> 0:04:47.700000 So, my key focus in this video was the session IDs. 0:04:47.700000 --> 0:04:51.820000 But before we get into that, I want to sort of go over technically speaking 0:04:51.820000 --> 0:04:55.580000 or technically the session creation and management process. 0:04:55.580000 --> 0:05:02.160000 So, again, we cover this to a sort of minimal extent in the first section 0:05:02.160000 --> 0:05:04.960000 of the course when we are looking at session management. 0:05:04.960000 --> 0:05:06.980000 But I want to revisit it with a bit of detail. 0:05:06.980000 --> 0:05:10.980000 So, when we talk about session creation, which is usually after authentication, 0:05:10.980000 --> 0:05:13.000000 successful authentication, that is. 0:05:13.000000 --> 0:05:15.940000 So, this is, you know, when a user accesses a web application for the 0:05:15.940000 --> 0:05:19.480000 first time and the server generates a unique session. 0:05:19.480000 --> 0:05:23.820000 Now, that's the case if the web application is configured to create a 0:05:23.820000 --> 0:05:27.140000 session for unauthenticated users as well, right? 0:05:27.140000 --> 0:05:32.480000 So, the typical requirement or the use case for that is, let's say, web 0:05:32.480000 --> 0:05:39.280000 websites that require or have the, provide the user the ability to modify, 0:05:39.280000 --> 0:05:43.880000 you know, the accessibility of the website or modify preferences, et cetera. 0:05:43.880000 --> 0:05:47.560000 But the session stores the user's data such as preferences, login state 0:05:47.560000 --> 0:05:49.900000 or access levels in a secure way. 0:05:49.900000 --> 0:05:52.420000 Or, I should say, ideally a secure way. 0:05:52.420000 --> 0:05:56.280000 And then, you know, the server then assigns a unique identifier known 0:05:56.280000 --> 0:05:58.180000 as a session ID to the session. 0:05:58.180000 --> 0:05:59.840000 So, fairly simple. 0:05:59.840000 --> 0:06:02.660000 I think you probably understand that by this point. 0:06:02.660000 --> 0:06:05.820000 But then we have the session management with cookies, right? 0:06:05.820000 --> 0:06:08.160000 And we'll be looking at cookies in the next video. 0:06:08.160000 --> 0:06:12.040000 But for now, you know, cookies play a major role in managing sessions, 0:06:12.040000 --> 0:06:14.680000 major majors we saw in the previous video. 0:06:14.680000 --> 0:06:18.600000 But after generating a session ID, the server sends this ID back to the 0:06:18.600000 --> 0:06:21.220000 client's browser in the form of a cookie, right? 0:06:21.220000 --> 0:06:24.840000 For subsequent requests, the browser automatically includes this session 0:06:24.840000 --> 0:06:28.300000 cookie allowing the server to identify and authenticate the user across 0:06:28.300000 --> 0:06:33.640000 multiple pages or actions without requiring them to log in repeatedly. 0:06:33.640000 --> 0:06:35.820000 Again, I've gone over this. 0:06:35.820000 --> 0:06:39.700000 And then, of course, you know, we're not pretty sure we're familiar with 0:06:39.700000 --> 0:06:42.240000 this, but we then have cookie flags, right? 0:06:42.240000 --> 0:06:43.960000 Or attributes, if you will. 0:06:43.960000 --> 0:06:48.140000 But the cookie is also configured with security attributes like HTTP only, 0:06:48.140000 --> 0:06:52.520000 secure and same site to enhance the session security will be exploring 0:06:52.520000 --> 0:06:57.920000 what those flags or attributes are and what they're used for and how this 0:06:57.920000 --> 0:07:00.800000 affects you as a web app dentist in the next video. 0:07:00.800000 --> 0:07:05.720000 But for now, just know that the process of securing the cookie or how 0:07:05.720000 --> 0:07:11.000000 it's used or how it can be used is determined primarily by the attributes, 0:07:11.000000 --> 0:07:15.020000 right? And that's something that's very important as I'm sure you're beginning 0:07:15.020000 --> 0:07:16.800000 to become aware of. 0:07:16.800000 --> 0:07:19.360000 We then have the role of session IDs, right? 0:07:19.360000 --> 0:07:23.600000 So the session ID is the main link between the client and the server side 0:07:23.600000 --> 0:07:28.300000 session data. So it should be unpredictable and securely stored often 0:07:28.300000 --> 0:07:30.500000 within the cookie. 0:07:30.500000 --> 0:07:35.320000 And we'll talk a little bit about that securely stored or what that means. 0:07:35.320000 --> 0:07:39.540000 But a secure session ID minimizes the risk of unauthorized access and 0:07:39.540000 --> 0:07:44.760000 mitigates threats like session hijacking where an attacker tries to steal 0:07:44.760000 --> 0:07:49.660000 or reuse the session ID. 0:07:49.660000 --> 0:07:53.260000 So I just wanted to go over that process, session creation management 0:07:53.260000 --> 0:07:58.360000 as well as show you the link between session management and the session 0:07:58.360000 --> 0:08:00.980000 ID. So hopefully that's become clearer. 0:08:00.980000 --> 0:08:05.000000 Now, I've not really described session IDs within this course. 0:08:05.000000 --> 0:08:07.680000 So I think it's a good time to introduce it in now. 0:08:07.680000 --> 0:08:11.520000 If you're not familiar with them already, session IDs are unique, identifies 0:08:11.520000 --> 0:08:15.700000 assigned to a user session when they interact with a web application. 0:08:15.700000 --> 0:08:19.920000 And these IDs help the application recognize a user across multiple requests 0:08:19.920000 --> 0:08:24.240000 and maintain continuity in their experience on the web application or 0:08:24.240000 --> 0:08:25.660000 as they're browsing, right? 0:08:25.660000 --> 0:08:29.460000 Now a well secured session ID is essential for preventing unauthorized 0:08:29.460000 --> 0:08:34.920000 access to user sessions and reducing vulnerabilities such as session hijacking 0:08:34.920000 --> 0:08:37.300000 fixation, which I touched on. 0:08:37.300000 --> 0:08:40.260000 Now comes the important part. 0:08:40.260000 --> 0:08:44.900000 And remember in the previous, I think the last two slides back, I mentioned 0:08:44.900000 --> 0:08:49.220000 that cookies are one of the ways of implementing session IDs. 0:08:49.220000 --> 0:08:51.360000 And that's typically how it's done today. 0:08:51.360000 --> 0:08:56.680000 But again, if you're familiar with JWTs or JSON web tokens and token based 0:08:56.680000 --> 0:09:02.860000 authentication, again let's not conflate both of these because again, 0:09:02.860000 --> 0:09:11.680000 I think I have an idea of what you're just keeping to session IDs, right? 0:09:11.680000 --> 0:09:17.040000 Cookies are typically the most common form or way session IDs are implemented 0:09:17.040000 --> 0:09:19.240000 in terms of session management. 0:09:19.240000 --> 0:09:23.180000 But there are also others, which again, not really that common, maybe 0:09:23.180000 --> 0:09:24.940000 in older web applications. 0:09:24.940000 --> 0:09:28.840000 But I think it's important that I go over them with you so that you're 0:09:28.840000 --> 0:09:34.540000 aware of just how robust session management can be in terms of its implementation. 0:09:34.540000 --> 0:09:40.400000 Firstly, we have the most popular, most widely employed or widely used 0:09:40.400000 --> 0:09:44.480000 implementation of session IDs, which is cookie based session IDs. 0:09:44.480000 --> 0:09:47.860000 So this is where the session ID stored in a cookie and sent back to the 0:09:47.860000 --> 0:09:51.720000 server with each request, as we've seen again throughout this particular 0:09:51.720000 --> 0:09:55.320000 course. This is the most common form of session management and cookies 0:09:55.320000 --> 0:09:57.180000 can be set with security flags. 0:09:57.180000 --> 0:10:01.340000 These have already elaborated, so HTTP only secure same site to prevent 0:10:01.340000 --> 0:10:06.540000 theft via cross site scripting or CSRF cross site request forgery attacks. 0:10:06.540000 --> 0:10:11.000000 We then have URL based session IDs where the session IDs are appended 0:10:11.000000 --> 0:10:12.780000 to the URL as a parameter. 0:10:12.780000 --> 0:10:19.380000 So URL parameter, not within the, you know, within any specific headers 0:10:19.380000 --> 0:10:24.680000 within the request, more specifically the URL is where it's included. 0:10:24.680000 --> 0:10:27.600000 So this is an example where the site or domain is example.com. 0:10:27.600000 --> 0:10:34.480000 There's a dashboard and then session IDs set or appended to the URL as 0:10:34.480000 --> 0:10:37.760000 a parameter. So session IDs, the parameter and then the value of the session 0:10:37.760000 --> 0:10:41.200000 ID or the session ID itself is the value. 0:10:41.200000 --> 0:10:45.340000 So URL based session IDs are considered insecure because they can easily 0:10:45.340000 --> 0:10:49.680000 be exposed in browser history, server logs and shared URLs, which is true, 0:10:49.680000 --> 0:10:51.340000 which is correct, right? 0:10:51.340000 --> 0:10:55.920000 We then have token based sessions, which is why I brought it up earlier. 0:10:55.920000 --> 0:11:00.560000 So tokens such as JSON web tokens, JWTs are increasingly used for session 0:11:00.560000 --> 0:11:04.040000 management in it, you know, with APIs and modern web applications. 0:11:04.040000 --> 0:11:05.940000 They're, you know, becoming quite common. 0:11:05.940000 --> 0:11:09.240000 And we're not getting into tokens right now. 0:11:09.240000 --> 0:11:15.940000 This course has its own session dedicated, uh, section dedicated to JWTs 0:11:15.940000 --> 0:11:17.360000 and token based authentication. 0:11:17.360000 --> 0:11:20.660000 But for the purpose of this video and sort of explaining it to you right 0:11:20.660000 --> 0:11:25.140000 now, tokens contain encoded information about the user that can be stateless. 0:11:25.140000 --> 0:11:27.540000 So not requiring server storage. 0:11:27.540000 --> 0:11:31.960000 They either stored in cookies or local storage and are passed with each 0:11:31.960000 --> 0:11:35.140000 request header. I'll leave it at that for now. 0:11:35.140000 --> 0:11:39.120000 But then we have the session ID in the headers, which is slightly different 0:11:39.120000 --> 0:11:43.720000 in that some application, some application store the session ID in custom 0:11:43.720000 --> 0:11:46.840000 headers, particularly restful APIs. 0:11:46.840000 --> 0:11:50.220000 This makes session management slightly more secure since the session ID 0:11:50.220000 --> 0:11:52.400000 is in part of the URL or cookies. 0:11:52.400000 --> 0:11:57.000000 And that's sort of what you would consider the second most popular, most 0:11:57.000000 --> 0:12:01.660000 common implementation, generally speaking, when it comes to APIs, you're 0:12:01.660000 --> 0:12:03.760000 going to have JWTs primarily. 0:12:03.760000 --> 0:12:06.960000 So important to keep that in mind now. 0:12:06.960000 --> 0:12:11.860000 From the WSDG or the OAS web security testing guide, I've sort of highlighted 0:12:11.860000 --> 0:12:16.820000 some of the, not all of the tests related to session management testing, 0:12:16.820000 --> 0:12:21.080000 but some of the key ones, you know, that will be exploring to a certain 0:12:21.080000 --> 0:12:24.440000 extent, I would say, at least in this, in the session management testing 0:12:24.440000 --> 0:12:28.980000 section. So the first is, of course, testing for session management schema. 0:12:28.980000 --> 0:12:32.460000 So this is where, you know, you're essentially verifying that the session 0:12:32.460000 --> 0:12:37.040000 identifies are stored in a secure way and can be easily retrieved or guessed 0:12:37.040000 --> 0:12:41.320000 by an attacker. And then we have the cookie attributes. 0:12:41.320000 --> 0:12:47.760000 So this is different from the, you know, request parameter modification 0:12:47.760000 --> 0:12:51.500000 or tampering that we explored in the previous section. 0:12:51.500000 --> 0:12:55.000000 But in this case, you know, we're checking the cookie security setting. 0:12:55.000000 --> 0:13:00.820000 So specific flags, attributes like HTTP only secure, same site to essentially 0:13:00.820000 --> 0:13:04.740000 prevent cookie theft through attacks like cross-site scripting. 0:13:04.740000 --> 0:13:06.460000 We then have session hijacking and fixation. 0:13:06.460000 --> 0:13:11.280000 I didn't include hijacking because again, I generally, or at least in 0:13:11.280000 --> 0:13:14.920000 this course, we'll cover them sort of a combined or use a combined approach, 0:13:14.920000 --> 0:13:19.360000 but session fixation for now just to define it or to sort of outline what 0:13:19.360000 --> 0:13:20.840000 this test pertains to. 0:13:20.840000 --> 0:13:26.820000 This is, you know, essentially the process of assessing or an attacker 0:13:26.820000 --> 0:13:30.780000 assessing whether, you know, you can predict a session ID before the user 0:13:30.780000 --> 0:13:33.660000 logs in forcing them to use it. 0:13:33.660000 --> 0:13:35.720000 So again, I'll not dive into that. 0:13:35.720000 --> 0:13:39.820000 You should be familiar with session hijacking and fixation, but if you're 0:13:39.820000 --> 0:13:42.060000 not, don't worry, we will cover this. 0:13:42.060000 --> 0:13:44.580000 And then we have testing for session expiration. 0:13:44.580000 --> 0:13:48.060000 So this ensures that sessions expire after, you know, a period of inactivity 0:13:48.060000 --> 0:13:52.720000 when the user logs out to prevent unauthorized access, which is, you know, 0:13:52.720000 --> 0:13:53.320000 quite important. 0:13:53.320000 --> 0:13:56.660000 If you think about it, you need to have some sort of expiration criteria 0:13:56.660000 --> 0:14:01.800000 to ensure that your session ID is not just some golden key to the kingdom 0:14:01.800000 --> 0:14:06.700000 where, you know, you can wear your wristband, you know, you can, your 0:14:06.700000 --> 0:14:11.140000 concert wristband is not, is not taken away from you. 0:14:11.140000 --> 0:14:15.360000 You can imagine just how problematic that can end up being unless you 0:14:15.360000 --> 0:14:18.200000 sort of have, you know, access for a year or something like that. 0:14:18.200000 --> 0:14:21.940000 Anyway, apologies for that tangent or for me going on that tangent. 0:14:21.940000 --> 0:14:24.180000 We then have testing for session timeouts, right? 0:14:24.180000 --> 0:14:27.400000 So this evaluates if sessions are configured to terminate after a reasonable 0:14:27.400000 --> 0:14:30.760000 period, reducing risk from abandoned sessions. 0:14:30.760000 --> 0:14:36.340000 This is sort of part of the same thing, but sort of now testing, testing 0:14:36.340000 --> 0:14:40.860000 for or checking whether there is indeed a standardized timeout where, 0:14:40.860000 --> 0:14:42.100000 you know, you're logged out. 0:14:42.100000 --> 0:14:44.440000 And this is something that you've probably experienced before, where certain 0:14:44.440000 --> 0:14:48.460000 websites, for some reason, will log you out after, let's say, just 24 0:14:48.460000 --> 0:14:52.680000 hours, right, which is quite strict or quite harsh because you have to 0:14:52.680000 --> 0:14:54.020000 log in every day. 0:14:54.020000 --> 0:14:56.900000 But yeah, that's what you're testing for. 0:14:56.900000 --> 0:15:03.140000 Not, not whether it's happening, but also what are the, what is the criteria? 0:15:03.140000 --> 0:15:07.380000 What's the, the configuration? 0:15:07.380000 --> 0:15:09.880000 So, you know, is there any standardization? 0:15:09.880000 --> 0:15:12.520000 Is it 12 hours, 24 hours a week, et cetera? 0:15:12.520000 --> 0:15:17.660000 Is, are there any other, are there any other environmental factors that 0:15:17.660000 --> 0:15:19.300000 affect the timeout? 0:15:19.300000 --> 0:15:23.760000 So, you know, is it different for admins, for example, that's a poor example, 0:15:23.760000 --> 0:15:29.240000 but just, I'm sort of giving you the, I'm giving you a look into just 0:15:29.240000 --> 0:15:32.800000 how dynamic this can be, but that's what that test entails. 0:15:32.800000 --> 0:15:35.420000 With that being said, that's going to be it for this video. 0:15:35.420000 --> 0:15:39.360000 In the next video, I want to touch a little bit on cookies and the cookie 0:15:39.360000 --> 0:15:44.440000 attributes of flags and how, and sort of, I'm going to explain the relevance 0:15:44.440000 --> 0:15:48.200000 to session management, session security, if you will, but more specifically 0:15:48.200000 --> 0:15:52.900000 to the session management testing process and methodology, and why you'll 0:15:52.900000 --> 0:15:55.160000 sort of see why that's important. 0:15:55.160000 --> 0:15:57.920000 But with that being said, that's going to be it for this video, and I'll 0:15:57.920000 --> 0:15:59.700000 be seeing you in the next video.