A short tale of Session Fixation.

Kanchan Singh Yadav
3 min readFeb 12, 2019

Hey guys,

Welcome again.

Let’s start the post with this

why we actually needed sessions in the first place?

In the early days of the Internet, everything was simple, just static pages lying around on the internet. No fancy graphics, no dynamic data, no personalized Content, everything was simple but boring.

boring

Then we came into the modern era of the Internet where everything is dynamic, every website gives the content to the user on the basis of their choice, we got n number of applications ranging from games to education, travel to health. Every website or I should say every web application need a different account to work for you specifically.

So accounts were created but there was a problem,

problem!!!

HTTP(hypertext markup protocol) is a stateless protocol that means it doesn’t know the difference between you and your neighbour(let’s say, John), so the question is how to differentiate between you and John. For example, if you add something to your cart on Amazon, it won’t get added to John’s cart or in another case you will never be pleased to know that your facebook messages were read by John, intentionally or accidentally.

To deal with all these problems some smart guy came up with the concept of Sessions.

The Smart guy

So the session is the one thing that won’t let things go messy. A session is activated as soon as you get logged in a web application and expires as you log out, Session can be maintained in the form of a cookie or a session id. Session id or cookie is sent using Set cookie header in http response by Server.

So enough for background let’s move to the actual story

I was working on a website, this website just got some normal functionality for navigation, searching content and all other normal stuff.
I started mapping the web application. After a while trying to exploit the web application for basic attacks like XSS, IDOR, Information Disclosure etc.
I almost completed the application map but didn’t get anything interesting so I thought why not go for the session. The web application was using a Session ID to maintain session throughout the application.

I tried to break the session cookie, thinking it was ECB or CBC, tried tests for randomness using burp suite but nothing works, I thought maybe they got really tight security so can’t find any vulns.
With a heavy heart, I logged out. I was staring at my computer screen and by mistake, I pressed alt + ← and…
I was inside the account again and I was like wooooow

so I fired up burp again and check for the session cookie and log out for the account and again logged in with the same account and to my surprise, it was the same cookie that is used for the session earlier that means session cookie was not expiring even after you log out.

There was one more problem, the website was actually giving you the Session id once you entered your credentials without even noticing that you were successfully logged in or not.
So used the basic technique for username enumeration

using the forget password functionality, got the list and you are smart enough to guess what is next.

Moral of the story

Do not always settle for bugs inside the application try to break the entry points of any web application

Advice:
if you get time read about EBC and CBC ciphers, If I got time will write about it.

Till then
keep learning,keep hacking

like it then clap, if not comment down.

--

--