Web Application Session Auditing Part 1: Intro
Web application session handling is one of the most difficult things to do right. As we move more and more towards standard web frameworks (django, rails, etc.) to handle the basic functionality of a custom web application, this becomes a smaller issue. Unfortunately, there are engineers and developers that insist on going it alone in this realm. There are also legacy applications that require backward compatibility and then there are just plain old out of date applications that still serve publicly.
Web Application Session Auditing Part 2: Recon
One of the best things you can do is take time to understand how the authentication system works on your target site. How is the session stored? In a cookie? In the URL? What happens when you fuzz or substitute random values for the session ID value? How does the application react in different scenarios? That's what we're going to talk about in-depth with some actual steps on how to find out.
Web Application Session Auditing Part 3: Exploitation
The idea here is to determine your goals. Typically in our web app assessment engagements, our primary goal is to identify all the weaknesses in the application. While this isn't necessarily the goal of a malicious attacker, it is helpful to our clients. Attackers will typically stop at the first found vulnerability that they can exploit to achieve their goals. Remember that time, motivation and resources are determined by the attacker or the attacker's clients. I'll try to cover most of the interesting attack vectors, but the primary goal for a web app session attack is to gain control of that session and hopefully completely compromise the user's account.
Web Application Session Auditing
Web application session handling is one of the most difficult things to do right. As we move more and more towards standard web frameworks (django,rails, etc.) to handle the basic functionality of a custom web application, this becomes a smaller issue. Unfortunately, there are engineers and developers that insist on going it alone in this realm. There are also legacy applications that require backward compatiblility and then there are just plain old out of date applications that still serve publicly.