Web Hacking: Become a Pentester – Lecture 16: Intro to Session Management
french text to speech
In this video I introduce how session management should normally work in web applications, before we go and exploit them.
This is a preview lecture from my online web hacking training called Web Hacking: Become a Pentester.
Check out the full course: http://aetherlab.net/y/ho
My blog: http://aetherlab.net
All my traingings: http://hackademy.aetherlab.net
Transcript:
Hi
In this section we are going to learn attacks against the session management of the application. For that first we have to understand how session management usually works. And this is what this lecture is about. I you are a web developer, you are probably already familiar with this, but it might be good to refresh.
So first of all as I mentioned in the lecture about HTTP, it is a stateless protocol. This means that if you send two request to the same server it has no idea that they came from the same person. The webserver will see that they come from the same IP address but that absolutely doesn't mean anything. If you are browsing the Internet in a café then you will use the same IP as eveybody else there. This is a pretty big problem for modern web applications.
[draw]
To solve this, the idea of a session came along. The session is basically just an object kept in memory by the web application. For each user when he first opens the page it creates a new session. The session is identified by a unique hopefully random session id. This session id then transferred to the user, usually as a cookie, and whenever a request comes from that user it will contain the session id, and with that the webserver know who sent that request. When the session id is associated with a user then the web application can easily lookup the username and further data, such as what he has in his shopping cart. One important point is that the session id has to be protected. If you are logged in and somebody can steal or guess your session id, then he can hijack your session because the server will think it is you.
[example with atherlab.net]
Let's talk a little about how cookies work. When the server send a cookie in an HTTP response, it t can specify the domain, the PATH the cookie is valid for and timeframe. Cookies are only valid in the same domain as the one issued it. It is important because the browser will attach the cookies automatically to requests. For instance if you get a cookie from facebook.com, the browser will store it and attach it to every request sent to facebook.com automatically. If the server sets a path, then only request to that path or subpath will be sent. Also if you set a cookie a specific domain, that means that it will be sent to all subdomains as well. (. Or no .)
So after you login on a page you will have a session cookie, which will be sent with each request, that is why the server know it is you. Of course the cookie are the core of user tracking and marketing, but that is another story.
So let's see how this works on the voice of the emperor. Make sure that burp is running and delete the cookie in the browser, so that we start with a fresh system. Now load the page.
If you look at the first request you will see that there is no cookie. Then if you look at the response then you will see the set cookie header. It contains the anchorcms cookie and sets some attributes. If you look at the nex request or any furter request, then you will see that the all contain the same cookie. This way the server can identify you.
If we go back to the browser and check the cookies in the developer tool then you will see the cookie there. Cookie can be session based which is deleted when you close the browser or permanent which will be saved to disk when you close the browser and reloaded when you open it again.
Many applications use a lot of cookies for various reason. For us it is always important to identify which cookie is the session cookie. You can do that by logging in and sending requests but always deleting a cookie. Usually when you get the authentication error, then that was the session cookie.
Let's recap this lecture. We learned that web applications use session objects to identify users in the stateless HTTP protocol. There is always a session ID which is sent to the user and mostly stored as a cookie in the browser. The cookie is automatically attached to each request sent to its issuing domain.
If you want a little exercise, you can extend the whoisyourdaddy.php to create a session and store the submitted username in the session, and if there is already a stored username use that automatically when the page is loaded.
If you are ready you can post it in the comments below.
In The next lecture we will learn more about the session as we test various attacks. So see you there.
2017-12-17 15:30:00
source
Gloss