Hello guys 😄
Today I'm really excited to share my first write-up ever 🔥 I hope you like it, and I'd really appreciate your feedback ❤️
This vulnerability was discovered during testing on a private program (let's call it affected.com since it's confidential 😉). At first glance it looked simple… but the impact was huge — Full Account Takeover without knowing the password.
The Discovery
While reviewing the login flow carefully, I noticed something interesting. When a user opens the login page, the system generates a sessionId directly in the URL before authentication even happens. After the user logs in successfully, that same sessionId becomes associated with their account.
That alone was suspicious… but the real issue was deeper.
The session validation mechanism was primarily bound to the User-Agent header only, without strong additional validation controls. There was no proper session regeneration after login, no IP binding, and no strict verification logic.
Exploitation Scenario 🔥
To reproduce this issue, we need two separate sessions:
One for the attacker One for the victim
First, the attacker needs to obtain the victim's User-Agent string. This can be done easily via social engineering, a malicious webpage that captures headers, or any technique that reveals HTTP request information.
Next, the attacker opens Burp Suite and goes to Proxy → Match and Replace, then creates a rule to replace their own User-Agent header with the victim's User-Agent.
From this point forward, all outgoing requests from the attacker's browser will impersonate the victim's exact User-Agent.
After configuring that, the attacker visits:
Once the page loads, a parameter appears in the URL such as sessionId=ABC123.
The attacker saves this sessionId value.
Then, the attacker copies the full login URL including the sessionId parameter and sends it to the victim.
The victim opens the link and logs in normally.
Here is the critical moment — the application binds that attacker-controlled sessionId to the victim's authenticated account.
Now the attacker goes back to their browser, opens Developer Tools, replaces their current sessionId cookie with the previously captured sessionId value, and refreshes the page.
And just like that…
The attacker becomes authenticated as the victim — without ever knowing the password.
Impact 🎯
This vulnerability allows an attacker to take over any user account completely. By controlling the session fixation flow and abusing weak session binding mechanisms, the attacker gains full unauthorized access to victim accounts.
Full Account Takeover.
Root Cause
The issue exists because the sessionId is generated before authentication. The session is not regenerated after login. The session is weakly bound only to User-Agent. There is no strong verification logic preventing fixation attacks.
Final Thoughts ❤️
As this is my first write-up, I really hope it was clear and helpful 🙏
Always pay close attention to session handling logic. Sometimes the smallest flaw in authentication flow can lead to massive impact.
Happy Hunting 😈🔥