Learn what to look for while penetration testing session management using OWASP principles including brute-forcing, taking advantage of poorly implemented session fixation, and POST and GET requests implemented incorrectly to find weak spots.
Poorly implemented session management can allow an attacker to exploit poor controls and gain access to sensitive information. In Web Application Penetration Testing: Session Management Testing, you’ll learn how to find those vulnerabilities before the bad guys do. First, you'll explore cookies, what to look for during a pen-test, and how you can brute force your way passed the login prompt. Next, you'll learn how easy it can be to hijack someone else's session with session fixation. Finally, you’ll discover what session puzzling is and how to leverage it as an attacker. When you’re finished with this course, you'll have a solid understanding of what to look for while penetration testing session management.
Clark holds an Offensive Security Certified Professional (OSCP) certification and is currently part of the uTest.com security team and is part of Synack.com's red team, participating in finding security vulnerabilities.
Section Introduction Transcripts
Section Introduction Transcripts
Course Overview Hi everyone. My name is Clark Voss, and welcome to my course, Web Application Penetration Testing: Session Management Testing. I'm a security researcher and bug hunter. I'm currently part of UTest's security team, and part of Synack's Red Team participating in finding security vulnerabilities in everything from websites to mobile applications, and even the Internet of Things. 2017 was a record high for security vulnerabilities found in web applications. This trend is only going to increase in 2018. That's why Pen Testing is so important. Penetration testing can assess the overall security of a web application before the attackers do. In this course we are going to go over techniques I employ during Pen testing, and what I look for while testing against session management. Some of the major topics that we will cover include Brute-force attacks, session fixation attacks, exposed session variables, cross-site request forgery attacks. By the end of this course you'll have an understanding of how I use OWASP's principles on session management as a checklist to ensure I fully test a website's session management. I hope you'll join me in this journey to learn Pen testing techniques I use when pen testing web applications with a Web Application Penetration Testing: Session Management Testing course at Pluralsight.
Course Introduction Hello everyone. My name is Clark Voss. I'm a security researcher, bug hunter, and an offensive security certified professional. Welcome to my course, Web Application Penetration Testing: Session Management Testing. In this course we are going to look at how I test against session management when conducting a pen test. In a very true to life scenario we are going to pretend we have been contracted by Globomantics to test their web application. We will be doing black box testing with a very limited scope. We are only allowed to test the session management, and the session management only. I've been on a multitude of Pen tests exactly like this where the scope is very limited, and when it comes to black box testing I normally don't get a username or password, I may only get a URL, even an IP address, and I have to bypass the authentication altogether. In this course we're going to have to remind ourselves to think like an attacker. This course isn't geared towards the developer or potentially the system admin. This course, in particular, is geared towards the pen tester, the bug hunter, those kind of individuals, and so in turn, we have to remind ourselves to think like an attacker because that's what we're going to be doing, going on the offensive.
Testing for Exposed Session Variables Hi. This is Clark Voss. Welcome to my module, Testing for Exposed Session Variables. Remember HTTP? Well, it's still being used, and sometimes so is HTTPS, on the same website, so we're going to take a look at that. We're going to see if the website handles HTTP and HTTPS, and I've seen that on more than one occasion where just by removing HTTPS you've downgraded it to HTTP, and you're able to use that on a login page, and it happens, unfortunately, more often than you would think. Next, we're going to see what happens when you log in, log out, and log in again. Do you get a different token, and what's so different about it? We're going to take a look at session and local storage. We're going to see what gets put into the session and local storage when you log in. What happens when you log out? Does it stay there? And, whatever is in there, can you manipulate it, can you change it, and what happens when you do? Next, we're going to change the POST to a GET and see what happens. So when you log in can you do a GET? I've actually seen websites where if you change the POST to a GET instead of logging in your get a list of users. I know, hard to believe, but it's actually happened, and we're going to check hidden fields. This one I found hidden usernames, full hidden portions to websites that should only be accessed by administrators. I've also unhidden internal directories, internal IP addresses, just a wealth of knowledge just by un-hiding fields and seeing what's there. We're going to give it a try.
Testing for Cross-site Request Forgery Hi. This is Clark Voss. Welcome to my module, Testing for Cross-Site Request Forgery. So I'm sure you've seen something similar in other places, how an HTML form is submitted, so the client requests a page from the server, the server responds with an HTML form, and then the client sends form data. The user fills out the HTML form and submits it. The server authenticates and authorizes the user. If success, it performs the requested action. I'm often asked how this attack normally plays out in the real world. So an attack would coerce the victim to submit the attacker's form data to the victim's web server, and so I'm asked, how do I find and test cross-site request forgeries? Well, normally, I look at the login page, and I look at parts of the site that perform an action. Next, I create a user on the site, and log in. Then I create the HTML page, then I open the HTML page that I created to see if the desired action is taken, and if so, then we have a cross-site request forgery. This happens more often in the Forgot Password. It can also happen when you're logged in as the user and you're performing, let's say, adding users or you are changing your password. Those kind of things are where I find it the most. Here is an example of an HTML form that I generally create for most cross-site request forgery. Now we're going to create something a little bit different for our cross-site request forgery, and in fact, we're going to leverage cross-site scripting in order to deliver it, and we've found this particular cross-site scripting earlier in one of the other modules.
Testing for Logout Functionality Hi. This is Clark Voss. Welcome to this module, Testing for Logout Functionality. In this module we're going to test the Logout interface. For one, we're going to check to see if a logout interface even exists, and I know that sounds funny, but I've actually tested web applications that didn't have a way to log out, and I know that doesn't sound quite right, but that has been the case, and initially I thought it was a one off when I first had seen it, but then I realized that this actually happens. There are some web applications that the developer, for whatever reason, decided to not add a logout function. So the first part is is we're going to check the logout function, see how it works. Next, we're going to see if the server-side session actually terminates, and believe it or not, in some cases it doesn't. I know that seems hard to believe, but again, I know I sound like a broken record that this stuff actually does happen. We're going to test to see if when we log in, and we log out, can we log back in not just with the same token or session ID, but does it actually get terminated on the server? Can you reuse that and is that session still valid? We'll explore that, and then we're going to test session timeout, and what that entails is is actually validating that the session does time out. I have tested multiple web applications that say they're going to time out in a certain period of time, and then they'll last a a considerably longer time period longer than that, and so in some cases that's not so bad, but in other cases you want it to time out when you say it's going to time out, and also, I've tested web applications that say they have a timeout, and don't timeout at all. It's always good to validate, and that's what we're going to check.
Testing Session Timeout Hi. This is Clark Voss. Welcome to my module, Testing Session Timeout. In this module we're going to test the Logout function to ensure that it effectively destroys all session tokens, and if it doesn't destroy them, at least renders them unusable. Next, we're going to see if the server performs proper checks on session states. What we're looking for is ensuring that the server disallows an attacker to replay the previously destroyed session. We want to make sure that you can't take a session that's been used before and just use it again, and lastly, we're going to check to see if there is a timeout that's enforced, and if it is enforced, is it properly enforced. If the server uses and expiration time that is read from a session token, we're going to validate to see if that really is the case.
Testing Session Puzzling Hi. This is Clark Voss, and welcome to my module, Testing for Session Puzzling. So you ask, what is session puzzling? Well, it's where the application level vulnerabilities can be exploited by overriding session attributes. Alright, sounds good. So I've included this one because it is something that I turned in quite some time ago. It was early on in my testing, but it's still something that I think is important to look for, and I still do look for it on every single pen test. I use the OWASP version four checklist, and this is still incorporated in it, so I still look for it. What kind of attacks can you do with puzzling? You can do authentication bypass, you can do puzzling impersonation, puzzling flow bypass, puzzling privilege escalation, puzzling content theft, and puzzling indirect traditional attacks. So we're going to explore places to look for puzzling attacks, the Login page, Registration, Contact forms, any Test pages, specifically that's what I look for, and modules that store values, and those could be, well, almost anything really. Thinking of other examples, a very simple example would be a password reset functionality, and we're going to look for identifying information, such as username or the email address, and we're going to test that functionality.