WEBVTT 0:00:03.720000 --> 0:00:05.980000 Hello everyone and welcome. 0:00:05.980000 --> 0:00:09.080000 In this video we're going to be taking a look at session hijacking and 0:00:09.080000 --> 0:00:10.600000 session fixation. 0:00:10.600000 --> 0:00:14.860000 Again, this is still part of session management testing. 0:00:14.860000 --> 0:00:19.520000 You know, I sort of had two minds about whether or not to cover these 0:00:19.520000 --> 0:00:24.760000 two vulnerabilities and you may be asking why are you covering them together 0:00:24.760000 --> 0:00:30.620000 or as a pair? Well, the reason for that is one that I think is quite important, 0:00:30.620000 --> 0:00:34.920000 especially when I was learning about each of these two vulnerabilities, 0:00:34.920000 --> 0:00:40.000000 namely session hijacking and fixation, is that I always treated them as 0:00:40.000000 --> 0:00:45.340000 separate in the beginning, but as time passed, I sort of realized that 0:00:45.340000 --> 0:00:50.620000 that was the incorrect way of approaching these two because again, these 0:00:50.620000 --> 0:00:58.900000 are both session management or very closely related, right? 0:00:58.900000 --> 0:01:02.640000 And, you know, separating them from each other is important in terms of, 0:01:02.640000 --> 0:01:07.000000 you know, classification, contextualization, but they are quite similar 0:01:07.000000 --> 0:01:10.560000 in many ways. You just need to understand the difference between the two 0:01:10.560000 --> 0:01:13.220000 and this is very important. 0:01:13.220000 --> 0:01:16.600000 Understanding the difference between the two will help you understand 0:01:16.600000 --> 0:01:20.360000 each of them individually a whole lot better. 0:01:20.360000 --> 0:01:25.780000 And so, this particular video is going to be, you know, sort of, I should 0:01:25.780000 --> 0:01:30.860000 say, an improved explanation or an explanation that I wish I had gotten 0:01:30.860000 --> 0:01:33.700000 when I was learning about these vulnerabilities because they could be 0:01:33.700000 --> 0:01:38.180000 quite confusing, maybe to some of you, maybe to some of you, it really 0:01:38.180000 --> 0:01:42.680000 isn't. But hopefully this particular presentation will explain things 0:01:42.680000 --> 0:01:47.100000 a whole lot better than I had them explain to me when I got started, which 0:01:47.100000 --> 0:01:49.440000 was quite a while back. 0:01:49.440000 --> 0:01:55.160000 Anyway, there will also be a practical section to this video or aspect 0:01:55.160000 --> 0:01:58.560000 to this video, which we'll get to at the end, where I'll cover session 0:01:58.560000 --> 0:02:00.160000 fixation primarily. 0:02:00.160000 --> 0:02:04.240000 And you'll sort of understand why I'm covering one over the other by the 0:02:04.240000 --> 0:02:06.080000 end of the theoretical section. 0:02:06.080000 --> 0:02:11.280000 Anyway, you know, you're not here to listen to me, you know, just speak 0:02:11.280000 --> 0:02:17.620000 on the meta, you know, aspect of vulnerabilities. 0:02:17.620000 --> 0:02:19.340000 So, let's dive straight into it. 0:02:19.340000 --> 0:02:24.540000 So, first things first, what is session hijacking and what is session 0:02:24.540000 --> 0:02:27.820000 fixation? Well, let's start off with session hijacking. 0:02:27.820000 --> 0:02:31.860000 Now, as simply as I can explain it, in the context of session management 0:02:31.860000 --> 0:02:38.020000 testing, and web application penetration testing generally, session hijacking 0:02:38.020000 --> 0:02:43.280000 or cookie theft occurs when an attacker, which I'm assuming is going to 0:02:43.280000 --> 0:02:48.760000 be you, steals an active session token, allowing them or allowing the 0:02:48.760000 --> 0:02:53.460000 attacker to impersonate the legitimate user whose token was stolen. 0:02:53.460000 --> 0:02:57.720000 All right. Now, the bottom line is that once you as the pen tester or 0:02:57.720000 --> 0:03:02.220000 attacker are in possession of this session token that you have stolen 0:03:02.220000 --> 0:03:07.160000 that belongs to another user, then you can perform actions as the authenticated 0:03:07.160000 --> 0:03:09.500000 user whose token you stole. 0:03:09.500000 --> 0:03:14.400000 So, what this essentially means is that you have other users on a web 0:03:14.400000 --> 0:03:18.940000 application that all have their own unique session IDs, let's say, and 0:03:18.940000 --> 0:03:23.680000 if somehow you were to get that session ID, well, you can just impersonate 0:03:23.680000 --> 0:03:28.740000 that user because you can assume that session ID and, you know, you don't 0:03:28.740000 --> 0:03:33.340000 need the, you know, the users credentials, you just get the session ID 0:03:33.340000 --> 0:03:43.260000 and you're able to, you know, pretty much and really, in this case, what 0:03:43.260000 --> 0:03:47.880000 you're trying for ideally is to get, you know, an important user session 0:03:47.880000 --> 0:03:52.540000 ID. So, think of an admin, but that's as simple as I can explain it. 0:03:52.540000 --> 0:03:55.860000 We'll dive into this in detail, you know, as to what the attack looks 0:03:55.860000 --> 0:04:02.280000 like and how you, how exactly you steal or intercept an active session 0:04:02.280000 --> 0:04:08.320000 token. But let's turn our attention to section to session fixation now. 0:04:08.320000 --> 0:04:13.800000 So, session fixation attacks involve an attacker or pen tester tricking 0:04:13.800000 --> 0:04:19.120000 a user, another user on the same web application that has an account presumably 0:04:19.120000 --> 0:04:25.220000 into using a session ID that you, the attacker or the pen tester controls 0:04:25.220000 --> 0:04:30.680000 or knows about. What this does is it allows the attacker to gain access 0:04:30.680000 --> 0:04:32.860000 once the user authenticates. 0:04:32.860000 --> 0:04:37.440000 So, what this is as simply as I can put it using an example is let's say 0:04:37.440000 --> 0:04:41.180000 you have an account on a web application and you being the attacker or 0:04:41.180000 --> 0:04:44.840000 pen tester and you're testing for session fixation, right? 0:04:44.840000 --> 0:04:53.140000 So, the way you can do this is you can, you can take your session ID or 0:04:53.140000 --> 0:05:08.400000 let's say another session ID and you can essentially essentially, you 0:05:08.400000 --> 0:05:12.480000 know, you essentially prompt the user to authenticate or to use that session 0:05:12.480000 --> 0:05:16.640000 ID and this allows you to gain access once the, you know, that particular 0:05:16.640000 --> 0:05:18.040000 user authenticates. 0:05:18.040000 --> 0:05:23.660000 So, the best way to sort of explain session fixation because, you know, 0:05:23.660000 --> 0:05:27.380000 that explanation may have confused you a little bit as it did to me here 0:05:27.380000 --> 0:05:30.780000 because I usually like using a couple of examples which I've laid out 0:05:30.780000 --> 0:05:34.720000 in the slides. But, you know, I just wanted to explain that. 0:05:34.720000 --> 0:05:38.640000 Now, diving a little bit deeper into both of these, you know, session 0:05:38.640000 --> 0:05:42.320000 vulnerabilities or attacks, let's start at the top again with session 0:05:42.320000 --> 0:05:47.020000 hijacking and when it's typically done or when it can be done. 0:05:47.020000 --> 0:05:54.460000 So, session hijacking is typically done after the target user has authenticated. 0:05:54.460000 --> 0:05:59.000000 That's very important and the attacker then steals this legitimate session 0:05:59.000000 --> 0:06:07.560000 token. The session token is so you need to have an authenticated session 0:06:07.560000 --> 0:06:10.040000 token in order for this to work. 0:06:10.040000 --> 0:06:12.580000 Otherwise, you know, if you're just using it, if you're just stealing 0:06:12.580000 --> 0:06:16.580000 an anonymous session token, you know, it's not going to be much help. 0:06:16.580000 --> 0:06:22.420000 So, with that in mind, a session hijacking attack occurs, and again, I'm 0:06:22.420000 --> 0:06:27.460000 repeating this with that in mind, a session hijacking attack occurs when 0:06:27.460000 --> 0:06:32.280000 an attack against unauthorized access to a user's active session by stealing 0:06:32.280000 --> 0:06:38.340000 the session ID. With this stolen session ID, the attacker can impersonate 0:06:38.340000 --> 0:06:41.480000 the user and interact with the application as if they were authenticated 0:06:41.480000 --> 0:06:44.240000 as that user. Okay? 0:06:44.240000 --> 0:06:47.000000 So, let's just, you know, keep that as it is. 0:06:47.000000 --> 0:06:49.040000 Let's move on to session fixation. 0:06:49.040000 --> 0:06:53.680000 So, session fixation is slightly different in that. 0:06:53.680000 --> 0:06:57.800000 It occurs before authentication. 0:06:57.800000 --> 0:07:03.200000 All right. Now, in this case, the attacker predefining the session ID, 0:07:03.200000 --> 0:07:10.080000 which the user, the target user then unknowingly uses in order to log 0:07:10.080000 --> 0:07:15.480000 in. All right. So, explaining that a little bit, a session fixation attack 0:07:15.480000 --> 0:07:21.620000 happens when an attacker assigns a specific session ID to a user before 0:07:21.620000 --> 0:07:26.020000 they log in. Now, how you assign this or how you get the target user to 0:07:26.020000 --> 0:07:29.720000 use that session ID is something we'll explore shortly. 0:07:29.720000 --> 0:07:35.560000 But somehow you get that user to use that session ID before they log in, 0:07:35.560000 --> 0:07:39.160000 and you're essentially prompting them to log in somehow using that session 0:07:39.160000 --> 0:07:44.540000 ID. Now, the vulnerability is caused when the web application does not 0:07:44.540000 --> 0:07:49.240000 change the session ID upon logging in. 0:07:49.240000 --> 0:07:56.360000 The attacker can use the same ID to hijack the user's session after they've 0:07:56.360000 --> 0:08:01.860000 authenticated. So, the bottom line is you get them to authenticate, you 0:08:01.860000 --> 0:08:04.880000 know, with a specific session ID. 0:08:04.880000 --> 0:08:09.700000 So, let's say you say session ID 1000, you get them to authenticate. 0:08:09.700000 --> 0:08:17.180000 And once they've done that, that session ID, if it is unchanged, is essentially 0:08:17.180000 --> 0:08:21.960000 associated with the authenticated session of the target user, which means 0:08:21.960000 --> 0:08:27.560000 because you know that session ID that is now authenticated, you can essentially 0:08:27.560000 --> 0:08:29.760000 use that session ID. 0:08:29.760000 --> 0:08:34.300000 And at that point, because the server has associated the web application 0:08:34.300000 --> 0:08:39.540000 has associated that session ID with a specific user and has authenticated 0:08:39.540000 --> 0:08:45.800000 or is marked as authenticated, then you all of a sudden simply by the 0:08:45.800000 --> 0:08:50.880000 virtue of using that session ID are essentially authenticated, if that 0:08:50.880000 --> 0:08:56.420000 makes sense. And you're going to be authenticated as the user that essentially 0:08:56.420000 --> 0:09:02.240000 used that session ID, you know, for authentication or before authentication, 0:09:02.240000 --> 0:09:07.000000 essentially turning it into an authenticated session ID after the authenticate 0:09:07.000000 --> 0:09:12.280000 successfully. So, again, I need to use a couple of more examples here. 0:09:12.280000 --> 0:09:16.340000 So, we'll dive now deeper into session hijacking firstly, to understand 0:09:16.340000 --> 0:09:18.900000 exactly how this would work. 0:09:18.900000 --> 0:09:25.140000 So, I've sort of broken down what a typical session hijacking attack looks 0:09:25.140000 --> 0:09:29.680000 like, you know, from a procedure perspective. 0:09:29.680000 --> 0:09:33.860000 So, you know, step one, the user logs into the web app, the server generates 0:09:33.860000 --> 0:09:36.840000 a session ID, the session ID sent to the user. 0:09:36.840000 --> 0:09:42.560000 Now, from that point, as the attacker, you're pretty much trying to find 0:09:42.560000 --> 0:09:46.680000 a way of intercepting that session ID or getting it somehow. 0:09:46.680000 --> 0:09:52.220000 All right. Once you've gotten it, you can then, you can then impersonate 0:09:52.220000 --> 0:09:57.280000 that user using that session ID that you're able to intercept or to steal. 0:09:57.280000 --> 0:10:02.500000 And then you can perform unauthorized actions with that access. 0:10:02.500000 --> 0:10:08.360000 It's unauthorized because you logically speaking, you shouldn't have that 0:10:08.360000 --> 0:10:11.300000 session ID, but somehow you're able to get it. 0:10:11.300000 --> 0:10:15.460000 And now it looks like, from, you know, defensive security perspective, 0:10:15.460000 --> 0:10:19.500000 if you did anything malicious with that access, it would look like the 0:10:19.500000 --> 0:10:24.760000 user to whom the session ID was intended is actually doing it. 0:10:24.760000 --> 0:10:26.540000 So, you know, quite dangerous. 0:10:26.540000 --> 0:10:31.980000 So, in order to understand it, you know, the flow chart is very helpful, 0:10:31.980000 --> 0:10:36.320000 but I've also broken down the phases so that you understand exactly what's 0:10:36.320000 --> 0:10:41.120000 going on. So, we all start with, it all starts with session establishment, 0:10:41.120000 --> 0:10:46.300000 right? So, this is when a user, a target user logs into a web application, 0:10:46.300000 --> 0:10:49.620000 the server generates a session ID and assigns it to the user. 0:10:49.620000 --> 0:10:53.700000 This ID is usually stored in a cookie, usually typically, right? 0:10:53.700000 --> 0:10:57.080000 Or a URL parameter or an HTTP header. 0:10:57.080000 --> 0:11:03.180000 Okay. So, that's the first step, which is sort of encapsulated, um, sort 0:11:03.180000 --> 0:11:06.000000 of these three phases or steps here. 0:11:06.000000 --> 0:11:09.260000 Then you have the interceptions or the session ID interception. 0:11:09.260000 --> 0:11:15.220000 So, the attacker obtains the session ID using one of the following methods. 0:11:15.220000 --> 0:11:20.460000 The first method is sniffing, of course, where you captured unencrypted 0:11:20.460000 --> 0:11:24.760000 network traffic to extract the session ID. 0:11:24.760000 --> 0:11:27.520000 You then have man in the middle attacks, where you intercept communications 0:11:27.520000 --> 0:11:30.700000 between the user and the server. 0:11:30.700000 --> 0:11:33.440000 You also have cross-site scripting, where you inject malicious scripts 0:11:33.440000 --> 0:11:36.040000 into the web application to steal cookies. 0:11:36.040000 --> 0:11:38.800000 So, if you know, if you're dealing with a stored cross-site scripting 0:11:38.800000 --> 0:11:42.800000 vulnerability, you can actually come up with a cookie stealer that steals 0:11:42.800000 --> 0:11:47.100000 the cookies when any user within the web application or any user using 0:11:47.100000 --> 0:11:51.320000 that web application visits that page, because the cookies are stored 0:11:51.320000 --> 0:11:55.280000 locally through JavaScript, you can set up a cookie stealer, which is 0:11:55.280000 --> 0:12:00.060000 a small piece of code that steals the cookie from your browser or from 0:12:00.060000 --> 0:12:06.380000 the authenticated, from, you know, an authenticated session, and it then 0:12:06.380000 --> 0:12:10.280000 sends it to you, a donor remote server, you know, whatever. 0:12:10.280000 --> 0:12:14.120000 And at that point, you can then hijack it, right? 0:12:14.120000 --> 0:12:18.620000 The other technique is through predictable session IDs, where you exploit 0:12:18.620000 --> 0:12:23.260000 weak algorithms that were used to generate session IDs, or are used by 0:12:23.260000 --> 0:12:25.500000 the web application to generate session IDs. 0:12:25.500000 --> 0:12:29.500000 So, for example, if the session IDs are being generated using a formula 0:12:29.500000 --> 0:12:33.760000 that you can sort of decode or reverse engineer, maybe a sequential one, 0:12:33.760000 --> 0:12:38.700000 then you're able to, you know, you're able to predict, you know, session 0:12:38.700000 --> 0:12:43.180000 IDs, and as a result, you're through some testing, you're able to, you 0:12:43.180000 --> 0:12:47.460000 know, correctly correlate the session ID of, you're able to correctly 0:12:47.460000 --> 0:12:52.120000 correlate a session ID to a user account, and if you're able to do that, 0:12:52.120000 --> 0:12:56.060000 be able to guess or to predict session IDs, then you can pretty much hijack 0:12:56.060000 --> 0:13:01.320000 any of those sessions whose, whose IDs you're able to predict. 0:13:01.320000 --> 0:13:07.100000 We then have the last two steps within the flow chart, which is the session 0:13:07.100000 --> 0:13:10.060000 takeover and the exploitation, right? 0:13:10.060000 --> 0:13:14.400000 So session takeover, so where you impersonate the, the user using the 0:13:14.400000 --> 0:13:19.120000 session ID. So the attacker uses the stolen session ID to impersonate 0:13:19.120000 --> 0:13:20.520000 the legitimate user. 0:13:20.520000 --> 0:13:25.740000 Since the server relies solely on the session ID for authentication, it 0:13:25.740000 --> 0:13:28.820000 cannot differentiate between the attacker and the real user. 0:13:28.820000 --> 0:13:33.220000 And that sort of gives you another idea of what, of the vulnerability 0:13:33.220000 --> 0:13:34.600000 that leads to this. 0:13:34.600000 --> 0:13:39.120000 So if the server does not, or the server relies solely on the session 0:13:39.120000 --> 0:13:45.760000 ID, then at that point, you know, I would recommend that you test for 0:13:45.760000 --> 0:13:46.840000 session hijacking. 0:13:46.840000 --> 0:13:49.360000 That would be one requirement, but you get the idea. 0:13:49.360000 --> 0:13:52.240000 Then the final phase is of course, exploitation, where the attacker can 0:13:52.240000 --> 0:13:55.940000 now perform actions as the legitimate user, such as viewing sensitive 0:13:55.940000 --> 0:14:00.900000 data, making unauthorized transactions, and or altering account settings, 0:14:00.900000 --> 0:14:03.300000 right? So fairly simple to understand. 0:14:03.300000 --> 0:14:07.260000 Then we have session fixation, which I'm going to give a similar treatment 0:14:07.260000 --> 0:14:09.060000 in terms of explaining it to you. 0:14:09.060000 --> 0:14:14.080000 So how does session fixation work? 0:14:14.080000 --> 0:14:19.660000 Well, again, I'm using a flowchart here, a top-down or vertical flowchart 0:14:19.660000 --> 0:14:21.880000 to sort of explain what typically happens. 0:14:21.880000 --> 0:14:26.200000 So usually starts off with the attacker creating or acquiring a session 0:14:26.200000 --> 0:14:34.360000 ID. Once the attacker has acquired or created this session ID, the attacker 0:14:34.360000 --> 0:14:36.940000 then sends the session ID to the victim. 0:14:36.940000 --> 0:14:42.700000 Either using a link, you know, if the session IDs are embedded in a URL, 0:14:42.700000 --> 0:14:47.460000 then you'd send them like a phishing email with a link that contains that 0:14:47.460000 --> 0:14:50.800000 session ID, like let's say prompting them to log in. 0:14:50.800000 --> 0:14:53.200000 That's the most typical use case. 0:14:53.200000 --> 0:14:56.220000 They can set it in a cookie or inject it via JavaScript. 0:14:56.220000 --> 0:15:01.740000 The bottom line is that somehow, you know, through whatever means you 0:15:01.740000 --> 0:15:05.640000 are able to send this to the user or communicate it to them and get them 0:15:05.640000 --> 0:15:12.200000 to click on this link, for example, the use the victim, the recipient 0:15:12.200000 --> 0:15:19.640000 of this link that has that session ID set uses that session ID unknowingly, 0:15:19.640000 --> 0:15:23.280000 of course, and logs in with their credentials, right? 0:15:23.280000 --> 0:15:28.080000 The bottom line is that the web application associates that session ID 0:15:28.080000 --> 0:15:35.020000 that you sent them using that link where that session ID is set explicitly, 0:15:35.020000 --> 0:15:40.340000 the web application associates that session ID with the victim's session 0:15:40.340000 --> 0:15:42.620000 after authentication. 0:15:42.620000 --> 0:15:46.540000 So what that means is that session ID that you sent them, that you, the 0:15:46.540000 --> 0:15:52.280000 attacker or pen tester, sent the victim that you know of is now considered 0:15:52.280000 --> 0:15:56.640000 authenticated. And if that's the case, the attacker after authentication 0:15:56.640000 --> 0:16:02.420000 is completed by the victim can now use that session ID and essentially 0:16:02.420000 --> 0:16:05.060000 hijack that victim's session. 0:16:05.060000 --> 0:16:11.020000 So again, quite similar, both of these attacks session hijacking fixation, 0:16:11.020000 --> 0:16:15.620000 but it's very important that you understand where they where they differ. 0:16:15.620000 --> 0:16:19.300000 Now, I've sort of broken down each of these phases. 0:16:19.300000 --> 0:16:24.000000 And this particular slide deals with what is highlighted here, where you 0:16:24.000000 --> 0:16:27.760000 first need to set the session ID as the pen tester or attacker. 0:16:27.760000 --> 0:16:32.900000 So the attacker creates or acquires a valid session ID, for example, by 0:16:32.900000 --> 0:16:35.500000 initiating a session with a target web application. 0:16:35.500000 --> 0:16:39.600000 So what that means is you can use your own session ID, or you can guess 0:16:39.600000 --> 0:16:42.360000 a predictable session ID. 0:16:42.360000 --> 0:16:47.360000 The attacker being you, then sends this session ID to the victim through 0:16:47.360000 --> 0:16:53.940000 methods like embedding it in a URL, if session IDs can be supplied or 0:16:53.940000 --> 0:16:55.800000 can be specified in the URL. 0:16:55.800000 --> 0:16:59.240000 So this, you know, all depends on how the web application is configured. 0:16:59.240000 --> 0:17:03.800000 So this would be an example where you have example.com login session IDs 0:17:03.800000 --> 0:17:05.800000 equal to ABC 123. 0:17:05.800000 --> 0:17:09.260000 So in this case, you know, you would send it to the user, you know, through 0:17:09.260000 --> 0:17:12.260000 an email, for example, saying login to your account here. 0:17:12.260000 --> 0:17:17.040000 Remember, we're not using a fictitious URL or a phishing website. 0:17:17.040000 --> 0:17:20.480000 We're just telling them, hey, this is the real link to the website. 0:17:20.480000 --> 0:17:24.360000 Please log in, we can tell them, let's say you need to log in to verify 0:17:24.360000 --> 0:17:26.440000 something or something like that. 0:17:26.440000 --> 0:17:28.500000 The bottom line is within the URL. 0:17:28.500000 --> 0:17:32.720000 This is one example, we specify the session ID that we know of, or that 0:17:32.720000 --> 0:17:36.000000 belongs to our account, for example. 0:17:36.000000 --> 0:17:40.140000 And the bottom line is that if the web application, you know, uses or 0:17:40.140000 --> 0:17:44.700000 does not create a new session ID for every user when they authenticate 0:17:44.700000 --> 0:17:49.220000 and uses the one specified, which we have specified for them, then this 0:17:49.220000 --> 0:17:56.020000 session ID on the server side is now treated or it is now considered authenticated. 0:17:56.020000 --> 0:18:00.420000 So at that point, you as the attacker can now use that session ID, which 0:18:00.420000 --> 0:18:06.460000 you yourself sent to the victim and by using it or impersonating it, you're 0:18:06.460000 --> 0:18:08.740000 able to get an authenticated session. 0:18:08.740000 --> 0:18:11.800000 So very, very simple to understand what's going on there. 0:18:11.800000 --> 0:18:17.380000 So stage two and three refers to this aspect of the workflow here or the 0:18:17.380000 --> 0:18:21.360000 attack flow. So step two is, you know, the victim logs in using the attacker 0:18:21.360000 --> 0:18:25.200000 session ID. So the victim unknowingly uses the attacker supplied session 0:18:25.200000 --> 0:18:28.020000 ID to log into the web application. 0:18:28.020000 --> 0:18:32.600000 Once logged in, the application associates the session ID with authenticated 0:18:32.600000 --> 0:18:34.980000 session, which I mentioned. 0:18:34.980000 --> 0:18:36.800000 And finally, the attacker gains access. 0:18:36.800000 --> 0:18:40.400000 So since the attacker already knows the session ID, they can use it to 0:18:40.400000 --> 0:18:45.580000 access the victim session without needing the victim's login credentials. 0:18:45.580000 --> 0:18:49.460000 So, you know, it's once you see it this way, it really is very simple 0:18:49.460000 --> 0:18:52.420000 to understand and more importantly, understand the difference between 0:18:52.420000 --> 0:18:57.260000 the two. I've also sort of used a horizontal flow chart to sort of give 0:18:57.260000 --> 0:18:59.220000 you a better view of what's going on. 0:18:59.220000 --> 0:19:03.860000 And this particular section options just refer to exactly that different 0:19:03.860000 --> 0:19:10.160000 options you can use in terms of how you know, you, you get the victim 0:19:10.160000 --> 0:19:14.460000 to utilize the a specific session ID. 0:19:14.460000 --> 0:19:16.380000 So hopefully that makes sense. 0:19:16.380000 --> 0:19:18.040000 You can always refer to this in the slides. 0:19:18.040000 --> 0:19:24.060000 Now, one final thing that I want to touch on with regards to session fixation 0:19:24.060000 --> 0:19:29.260000 vulnerabilities is what causes them because I think you're probably asking 0:19:29.260000 --> 0:19:31.000000 yourself that question. 0:19:31.000000 --> 0:19:35.040000 Like, you know, what, you know, how to perform the attack, but what should 0:19:35.040000 --> 0:19:36.560000 we be looking for? 0:19:36.560000 --> 0:19:41.020000 Well, firstly, a failure to regenerate session IDs upon login. 0:19:41.020000 --> 0:19:46.660000 So, many web applications reuse the same session ID after a user authenticates. 0:19:46.660000 --> 0:19:52.300000 Now, if the session ID was known or controlled by an attacker before authentication, 0:19:52.300000 --> 0:19:54.640000 the attacker can hijack the session. 0:19:54.640000 --> 0:20:00.300000 Or if you use one that the attacker supplies to you, in this case, in, 0:20:00.300000 --> 0:20:04.860000 you know, when talking about session fixation, and you know, any user 0:20:04.860000 --> 0:20:11.180000 re-authenticating or logging in does not get a new session ID. 0:20:11.180000 --> 0:20:14.820000 And in fact, they use the one that you specified through the, let's say, 0:20:14.820000 --> 0:20:20.320000 URL that has the session ID set explicitly, then, you know, an attacker 0:20:20.320000 --> 0:20:26.260000 simply by knowing the session ID will just be able to hijack your session. 0:20:26.260000 --> 0:20:29.900000 And they'll be able to do that because you've already authenticated, which 0:20:29.900000 --> 0:20:33.620000 means that session ID is treated as authenticated. 0:20:33.620000 --> 0:20:37.160000 So the second is insecure session ID assignment. 0:20:37.160000 --> 0:20:42.140000 So if the application allows session IDs to be set through URL parameters, 0:20:42.140000 --> 0:20:46.180000 which I mentioned, I didn't say it's a bad, I didn't mention at that point 0:20:46.180000 --> 0:20:48.280000 that this was the actual vulnerability. 0:20:48.280000 --> 0:20:52.000000 But generally speaking, if a web application allows you to specify a session 0:20:52.000000 --> 0:20:54.720000 ID in the URL, that's not a good thing. 0:20:54.720000 --> 0:20:59.280000 Or through cookies or hidden form fields, an attacker can manipulate these 0:20:59.280000 --> 0:21:02.100000 to assign their own session ID to the user. 0:21:02.100000 --> 0:21:06.060000 And then of course, we have stuff like weak or predictable session ID 0:21:06.060000 --> 0:21:10.300000 generation where session IDs that are guessable or sequential can make 0:21:10.300000 --> 0:21:15.380000 it easier for attackers to create valid session IDs. 0:21:15.380000 --> 0:21:20.680000 You then have session IDs in URLs, which I've mentioned here, but now 0:21:20.680000 --> 0:21:22.560000 I want to speak specifically about it. 0:21:22.560000 --> 0:21:28.220000 So when session IDs are passed in the URL, for example, example.com, parameter 0:21:28.220000 --> 0:21:32.400000 session IDs equal to the value, which is the session ID, they are vulnerable 0:21:32.400000 --> 0:21:41.000000 to interception through methods like refer ahead as logs or a lack of 0:21:41.000000 --> 0:21:43.080000 secure flags on cookies. 0:21:43.080000 --> 0:21:48.140000 So if session cookies are not marked with the secure HTTP only or same 0:21:48.140000 --> 0:21:51.660000 site attributes, they are more vulnerable to interception or manipulation, 0:21:51.660000 --> 0:21:54.500000 which is very true and important. 0:21:54.500000 --> 0:21:58.100000 And then finally, and this is one of the most important, this is something 0:21:58.100000 --> 0:22:03.380000 that's very common even today, is there's a lack of expiry or timeout 0:22:03.380000 --> 0:22:05.200000 for session IDs. 0:22:05.200000 --> 0:22:10.280000 And this is very important because again, it doesn't really matter how 0:22:10.280000 --> 0:22:15.500000 an attacker gets to know your session ID. 0:22:15.500000 --> 0:22:20.340000 The bottom line is that a lot of these attacks can be sort of nullified 0:22:20.340000 --> 0:22:27.360000 or minimized, the impact can be minimized if the session ID expires when 0:22:27.360000 --> 0:22:31.980000 you log out, you know, or a new one is created when you log in that will 0:22:31.980000 --> 0:22:35.900000 that really mitigates session fixation specifically. 0:22:35.900000 --> 0:22:39.980000 But you know, in many cases, for various reasons web applications, you 0:22:39.980000 --> 0:22:45.960000 know, have session IDs that do not expire or that do not expire for, you 0:22:45.960000 --> 0:22:50.320000 know, overly long lifetimes or have overly long lifetimes, which again, 0:22:50.320000 --> 0:22:53.040000 increase the risk of exploitation. 0:22:53.040000 --> 0:22:56.800000 All right, so hopefully I was able to explain these two vulnerabilities 0:22:56.800000 --> 0:22:57.880000 as best as possible. 0:22:57.880000 --> 0:23:02.500000 What I'm going to now going to do is going to give you a practical demonstration 0:23:02.500000 --> 0:23:08.340000 as to what session fixation looks like using a the medium of a phishing 0:23:08.340000 --> 0:23:12.060000 email. And we're going to be using the deliberately vulnerable web application 0:23:12.060000 --> 0:23:17.120000 called webgoat. So this is a practical session, which means this video 0:23:17.120000 --> 0:23:20.100000 has a lab associated with it, which you can actually access. 0:23:20.100000 --> 0:23:22.940000 So the lab is just going to be below this video. 0:23:22.940000 --> 0:23:26.600000 You will not be provided with access to a calilinix system, just a link 0:23:26.600000 --> 0:23:28.320000 to the target web application. 0:23:28.320000 --> 0:23:33.300000 So the only tools you require really is going to be burp suite, fundamentally 0:23:33.300000 --> 0:23:35.540000 speaking. So you don't need your own VM. 0:23:35.540000 --> 0:23:38.320000 If you have burp suite installed on Windows, Linux, Mac, you should be 0:23:38.320000 --> 0:23:42.140000 good to go. With that being said, I'm going to fire up my lab environment, 0:23:42.140000 --> 0:23:49.520000 and I'll see you on my calilinix virtual machine in a few seconds. 0:23:49.520000 --> 0:23:54.240000 All right. So I'm back on my calilinix VM and I've started out the lab. 0:23:54.240000 --> 0:23:58.980000 As I said, you will only be provided with a link or a URL to the target 0:23:58.980000 --> 0:24:00.040000 web application. 0:24:00.040000 --> 0:24:01.380000 And in this case, it's webgoat. 0:24:01.380000 --> 0:24:04.080000 We've used webgoat before in this course. 0:24:04.080000 --> 0:24:07.580000 The reason I'm using webgoat is again this vulnerability session fixation 0:24:07.580000 --> 0:24:11.980000 to be more specific can be very difficult to show you practically. 0:24:11.980000 --> 0:24:16.360000 And I think webgoat does a phenomenal job at explaining exactly what a 0:24:16.360000 --> 0:24:17.640000 typical attack is going to be like. 0:24:17.640000 --> 0:24:23.800000 So I've currently opened it up, opened up the webgoat in the burp suite 0:24:23.800000 --> 0:24:26.000000 browser. So I have it running already. 0:24:26.000000 --> 0:24:27.400000 It's not going to be that important. 0:24:27.400000 --> 0:24:31.200000 But what I'm going to do is just log in as a guest. 0:24:31.200000 --> 0:24:34.640000 You can log in with admin if you want. 0:24:34.640000 --> 0:24:40.820000 There we are. And we're going to navigate to the session management vulnerabilities 0:24:40.820000 --> 0:24:48.020000 section. So in the previous, you know, the previous use case when we did 0:24:48.020000 --> 0:24:51.860000 use webgoat was when we were dealing with authentication flaws, if you 0:24:51.860000 --> 0:24:57.620000 remember. I believe it was authentication flaws. 0:24:57.620000 --> 0:24:59.000000 Maybe, maybe not. 0:24:59.000000 --> 0:25:04.400000 But if we go into session management flaws, you can see there's a lesson 0:25:04.400000 --> 0:25:09.420000 or a we can essentially learn how to hijack a session. 0:25:09.420000 --> 0:25:12.000000 So that's what we want to click on now. 0:25:12.000000 --> 0:25:16.700000 This can be very confusing if you look at it, you know, for the first 0:25:16.700000 --> 0:25:20.480000 time. But what is going on here? 0:25:20.480000 --> 0:25:22.000000 Let me see hijack. 0:25:22.000000 --> 0:25:24.640000 Sorry, session fixation is what I wanted to cover. 0:25:24.640000 --> 0:25:29.000000 So the way this works, and this is something that I really, really like 0:25:29.000000 --> 0:25:33.040000 in terms of how webgoat implemented it. 0:25:33.040000 --> 0:25:38.220000 So remember that when we're talking about session fixation or hijacking, 0:25:38.220000 --> 0:25:43.640000 you're really dealing with not just yourself and your activity, but with 0:25:43.640000 --> 0:25:46.680000 a target, a user's activity, right? 0:25:46.680000 --> 0:25:53.180000 And in this particular case, the scenario is, as listed over here, is 0:25:53.180000 --> 0:25:57.300000 broken down into stages, very similar to the way I outlined it in the 0:25:57.300000 --> 0:26:01.220000 slides, you know, in the flow chart or attack flow. 0:26:01.220000 --> 0:26:05.680000 So stage one essentially tells you that you are hacker Joe. 0:26:05.680000 --> 0:26:07.320000 So you're the pen tester, right? 0:26:07.320000 --> 0:26:10.260000 And you want to steal the session from Jane. 0:26:10.260000 --> 0:26:12.440000 Jane is another user on the system. 0:26:12.440000 --> 0:26:16.140000 You just know that, you know, their account or username is called Jane. 0:26:16.140000 --> 0:26:16.880000 That's pretty much it. 0:26:16.880000 --> 0:26:19.660000 You maybe also know their email, right? 0:26:19.660000 --> 0:26:26.700000 So the means through which we're going to deliver this URL with the, with 0:26:26.700000 --> 0:26:29.680000 a specific session ID is through an email. 0:26:29.680000 --> 0:26:33.560000 So we're going to send a prepared email to the victim, which looks like 0:26:33.560000 --> 0:26:35.380000 an official email from the bank. 0:26:35.380000 --> 0:26:38.500000 So it's a phishing email for all intents and purposes. 0:26:38.500000 --> 0:26:41.640000 Now, a template message has been prepared below. 0:26:41.640000 --> 0:26:45.820000 You will need to add a session ID in the link inside the email, all to 0:26:45.820000 --> 0:26:49.760000 the link to include an a session ID. 0:26:49.760000 --> 0:26:54.480000 So over here, you can see sort of simulating, you know, an email being 0:26:54.480000 --> 0:26:59.060000 sent where the recipient is Jane dot plane at ousp.org. 0:26:59.060000 --> 0:27:04.660000 And we are using or we are spoofing the admin at web goat financial.com. 0:27:04.660000 --> 0:27:07.920000 The title of the email is check your account, right? 0:27:07.920000 --> 0:27:09.280000 So dear Mrs. Plain. 0:27:09.280000 --> 0:27:10.040000 This is the body. 0:27:10.040000 --> 0:27:10.860000 Dear Mrs. Plain. 0:27:10.860000 --> 0:27:13.760000 During the last week, we have had a few problems with our database. 0:27:13.760000 --> 0:27:18.000000 We have received many complaints regarding incorrect account details. 0:27:18.000000 --> 0:27:20.440000 Please use the following link to verify your account. 0:27:20.440000 --> 0:27:23.820000 So exactly what you'd expect in a phishing email. 0:27:23.820000 --> 0:27:29.620000 And we need to modify this URL here to essentially contain the session 0:27:29.620000 --> 0:27:34.880000 ID that let's say we know off or that we are using for this attack. 0:27:34.880000 --> 0:27:41.000000 It can be our own session ID, although that's really not that clever. 0:27:41.000000 --> 0:27:45.320000 It can be a session ID, you know, for another account we have on the web 0:27:45.320000 --> 0:27:49.580000 application, but preferably not this one because again, if we're already 0:27:49.580000 --> 0:27:52.740000 signed in, we will need to log out and that, you know, can mess things 0:27:52.740000 --> 0:27:57.320000 up. Anyway, the bottom line is the link we're sending them to is just 0:27:57.320000 --> 0:28:00.420000 going to be the same link of this particular challenge page. 0:28:00.420000 --> 0:28:05.780000 However, we need to append a session ID to this URL, because in this case, 0:28:05.780000 --> 0:28:11.780000 the vulnerability is caused by the fact that the A, the session IDs are 0:28:11.780000 --> 0:28:17.340000 not changed when a user logs in and B, the session IDs are passed in or 0:28:17.340000 --> 0:28:21.640000 passed via the URL as well. 0:28:21.640000 --> 0:28:27.160000 So if we take a look at Burp here and just take a look at, you know, login 0:28:27.160000 --> 0:28:28.820000 right over here. 0:28:28.820000 --> 0:28:33.160000 If we take a look at the response, you can see, you know, it sets a set 0:28:33.160000 --> 0:28:35.020000 cookie J session ID. 0:28:35.020000 --> 0:28:40.660000 So that's the session ID here for our, you know, for our session. 0:28:40.660000 --> 0:28:42.320000 That's typically how it does it. 0:28:42.320000 --> 0:28:47.220000 So through the, the actual body of the response and likewise, it'll now 0:28:47.220000 --> 0:28:51.200000 be included, you know, as a cookie in every request we make, but it can 0:28:51.200000 --> 0:28:57.220000 also be used or specified via the URL or as a URL parameter, if you will. 0:28:57.220000 --> 0:29:02.020000 So the first thing we need to do is modify the URL to point to this specific 0:29:02.020000 --> 0:29:04.260000 page within the web application. 0:29:04.260000 --> 0:29:08.760000 This is just for the attack again in the real world. 0:29:08.760000 --> 0:29:11.840000 You'll probably send them to the login page of the web application you're 0:29:11.840000 --> 0:29:13.900000 targeting, for example. 0:29:13.900000 --> 0:29:17.660000 But in this case, we can see that we don't have web goat as a prefix. 0:29:17.660000 --> 0:29:20.820000 So we want to get rid of that there, cause again, in this case, web goat 0:29:20.820000 --> 0:29:23.380000 is installed in the root of the web server. 0:29:23.380000 --> 0:29:25.240000 So start MVC attack. 0:29:25.240000 --> 0:29:29.840000 And then this value here is the screen, the screen parameter and then 0:29:29.840000 --> 0:29:35.260000 the menu parameter in order to append the session ID, which for the purpose 0:29:35.260000 --> 0:29:38.120000 of this demo can be anything in the world that you want. 0:29:38.120000 --> 0:29:41.900000 It's not really important that this session ID exists. 0:29:41.900000 --> 0:29:48.040000 We can just say ampersand sid is equal to, let's say, a thousand. 0:29:48.040000 --> 0:29:49.640000 So the session ID of a thousand. 0:29:49.640000 --> 0:29:51.820000 I'm not saying this session ID exists. 0:29:51.820000 --> 0:29:53.420000 It really doesn't matter. 0:29:53.420000 --> 0:29:58.160000 The bottom line is that once Jane gets this email, clicks on the link, 0:29:58.160000 --> 0:30:02.740000 authenticates with this session ID, consequently associating this session 0:30:02.740000 --> 0:30:05.220000 ID with her authenticated session. 0:30:05.220000 --> 0:30:10.720000 We can then hijack or use this session ID and will be logged in as Jane 0:30:10.720000 --> 0:30:12.920000 pretty much. That's what the attack is. 0:30:12.920000 --> 0:30:16.200000 So we can now say send, send mail. 0:30:16.200000 --> 0:30:18.080000 Okay. And there we are. 0:30:18.080000 --> 0:30:19.680000 So this is very important. 0:30:19.680000 --> 0:30:23.580000 Now we are assuming the role of Jane. 0:30:23.580000 --> 0:30:28.120000 So in order for me to demo this, and this is the awesome thing about web 0:30:28.120000 --> 0:30:30.320000 goat. So we're now on stage two. 0:30:30.320000 --> 0:30:34.460000 Now we are the victim Jane who has received the email below. 0:30:34.460000 --> 0:30:38.120000 If you point on the link with your mouse, you will see that there is an 0:30:38.120000 --> 0:30:41.260000 sid included. Click on it to see what happens. 0:30:41.260000 --> 0:30:43.680000 Now, obviously, this is not displayed to Jane. 0:30:43.680000 --> 0:30:48.420000 What Jane will see is when she opens her inbox is, ah, we have an email 0:30:48.420000 --> 0:30:50.360000 from admin at WebGood Financial. 0:30:50.360000 --> 0:30:52.380000 That's my bank. Dear Mrs. 0:30:52.380000 --> 0:30:56.060000 Plain, during the last week, we had a few problems with our database. 0:30:56.060000 --> 0:30:58.880000 And yeah, sure, let me verify my account. 0:30:58.880000 --> 0:30:59.640000 That's quite important. 0:30:59.640000 --> 0:31:03.660000 So this is the link that we embedded in the email with the session ID. 0:31:03.660000 --> 0:31:06.300000 And you can see that it's actually included. 0:31:06.300000 --> 0:31:11.040000 If you look at the bottom of my screen here, where the URL is annotated, 0:31:11.040000 --> 0:31:14.140000 let's click on it and let's see what happens. 0:31:14.140000 --> 0:31:18.420000 Okay. So that particular link, as we would in a real attack, you know, 0:31:18.420000 --> 0:31:22.800000 takes the user to the login page of the legitimate web application. 0:31:22.800000 --> 0:31:27.580000 The only thing we have done is set the session ID to something that we 0:31:27.580000 --> 0:31:29.460000 want or that we know. 0:31:29.460000 --> 0:31:34.320000 So now it says stage three, we're still acting as the user Jane. 0:31:34.320000 --> 0:31:35.960000 So Jane is not yet signed in. 0:31:35.960000 --> 0:31:38.980000 So the bank has asked you to verify your data login to see if your details 0:31:38.980000 --> 0:31:41.100000 are correct. And it gives us Jane's credentials. 0:31:41.100000 --> 0:31:46.600000 Because of course Jane, Jane would know her password or username and password. 0:31:46.600000 --> 0:31:50.100000 So Jane says, ah, yeah, okay, let me log in. 0:31:50.100000 --> 0:31:51.460000 There we go. I've logged in. 0:31:51.460000 --> 0:31:55.520000 And now stage four, we are now back from the perspective of the hacker 0:31:55.520000 --> 0:32:00.180000 or pen test. And it says it is time to steal the session now. 0:32:00.180000 --> 0:32:03.040000 Use the link to reach GoTills financial. 0:32:03.040000 --> 0:32:07.280000 So at this point, the only thing we would need to do pretty much is use 0:32:07.280000 --> 0:32:09.420000 the link that we sent Jane. 0:32:09.420000 --> 0:32:12.200000 In most cases, so there we go. 0:32:12.200000 --> 0:32:13.820000 We click on that. 0:32:13.820000 --> 0:32:18.060000 And over here, so it's time to steal the session now. 0:32:18.060000 --> 0:32:22.360000 Use the following link and no valid session and we can set the session 0:32:22.360000 --> 0:32:25.260000 to 1000. And there we are. 0:32:25.260000 --> 0:32:31.680000 So the bottom line is that once Jane authenticated with the session ID 0:32:31.680000 --> 0:32:36.040000 set to 1000, that again, we center. 0:32:36.040000 --> 0:32:40.260000 At any point, we can just set our session ideas, the attacker to 1000 0:32:40.260000 --> 0:32:47.640000 and we'll assume the session will assume Jane's authenticated session. 0:32:47.640000 --> 0:32:50.240000 So there we are. 0:32:50.240000 --> 0:32:51.820000 It says you have completed the session. 0:32:51.820000 --> 0:32:53.900000 We can now see her details right over here. 0:32:53.900000 --> 0:32:58.460000 So this, I thought was a really, really well developed exercise to show 0:32:58.460000 --> 0:33:00.280000 you exactly what it would look like. 0:33:00.280000 --> 0:33:02.520000 And at the end, what you're able to achieve. 0:33:02.520000 --> 0:33:05.140000 And hopefully you're able to understand it. 0:33:05.140000 --> 0:33:08.400000 With that being said, that brings us to the end of the practical demonstration 0:33:08.400000 --> 0:33:10.700000 section of this video. 0:33:10.700000 --> 0:33:16.060000 All right. So that was session hijacking and session fixation. 0:33:16.060000 --> 0:33:19.500000 I hope you found this particular video helpful. 0:33:19.500000 --> 0:33:23.860000 And I would highly recommend that you go through or use WebGoat to not 0:33:23.860000 --> 0:33:32.080000 only go through the demo or the example that I used within WebGoat. 0:33:32.080000 --> 0:33:35.880000 Specifically, the session fixation attack, but also take a look at the 0:33:35.880000 --> 0:33:40.180000 session hijacking exercise because one does exist. 0:33:40.180000 --> 0:33:43.940000 But I think that this is sort of the best way to learn or to understand 0:33:43.940000 --> 0:33:50.140000 both at a technical level, but also practically not just what these vulnerabilities 0:33:50.140000 --> 0:33:54.480000 are and what causes them, but actually how it would, what it would look 0:33:54.480000 --> 0:33:55.740000 like in the real world. 0:33:55.740000 --> 0:33:59.840000 And I think the email simulation or the phishing email simulation that 0:33:59.840000 --> 0:34:04.380000 WebGoat afforded us was really, really nice. 0:34:04.380000 --> 0:34:08.880000 I think it really grounds this technique in the real world and allows 0:34:08.880000 --> 0:34:12.980000 us to turn what we covered in the slides, which at that point you might 0:34:12.980000 --> 0:34:15.920000 have said, yeah, I understand these two vulnerabilities. 0:34:15.920000 --> 0:34:19.240000 But now when you see it practically happen, again, aligned with what I 0:34:19.240000 --> 0:34:22.720000 laid out in the slides, you can actually see each of those phases. 0:34:22.720000 --> 0:34:26.540000 And hopefully you understand exactly what's going on. 0:34:26.540000 --> 0:34:29.340000 But with that being said, that brings us to the end of this video. 0:34:29.340000 --> 0:34:31.520000 And I will be seeing you in the next video.