| وَكَانَ فَضْلُ اللَّهِ عَلَيْكَ عَظِيمًا

The Story

"While recon session on a self-hosted web application , I normally start with mapping authentication flow to identify if app works with cookie session , jwt or other mechanism.

I noticed That the server manages the session through

Cookie: PHPSESSID=abcdefgh ....

That all things appeared work normally , after hours of testing , sign-ins / logouts , while i was testing a request on repeater i noticed that i had seen that cookie session before , asking question : The same cookie — across every login and logout ?!. That shouldn't be possible.

i returned back to early requests was initiated through the session to confirm that cookie session is the same, and that was correct !

i logged out The session token was temporary deactivated, But Once login Again, the session reactivated again ..

i then tried to enable 2fa , logout , login and proceed 2fa the session stay the same !!!

i tried change password , change email , stayed the same … What !!!!

i noticed a request that make GET request to endpoint like :

   GET /webapi/dashboard/get-jwt
   Host: api.example.com
   Cookie: PHPSESSID=abcdefgh ....

that respond with JSON with jwt token , refresh token. That used in further critical operations & functions.

i tried to set the session manually with custom token with same length. The server accepted it and assigned it as active session When i logged in as a normal user. "

What's Session Fixation ?

• when user initiate a request with server , the server set a unique token that sent forth and back between the client and server that keep the identity. Like as a formal deal that cannot share sensitive information with you without raising your ID , That SESSIONID is what answer the server question : Who are you , To serve you with suitable sources ?!
• The expected safe way that server set new token with expiry Time for that token based on certain situation. After that it must be invalidated and new one issued. Also After critical actions like 2FA enable/disable, password/email change or Logout It must be validated and new one issued with new session. But here The server trusts client side stored sessionid and re-validate as it was temporary deactivated once user logged again. That let the Hacker to manually set token and hijack Victim session via various ways.

Impact

• The Attacker could hijack session via fixate it either through shared device , MITM or potential XSS on any part of the app.
• Once the attacker hijack the session, The victim has no way to kick the attacker out , As the attacker can regain session any time user logged in.
• The Attacker could access API level critical functions , as he could get valid jwt from endpoint just by hijacked session.

TimeLine

• 18 Mar 26 → Report sent
• 26 Mar 26 → Final decision [Duplicated]

#BugBounty #CyberSecurity #EthicalHacking #Pentesting #SecurityResearch #BugHunter #InfoSec #AppSec #ResponsibleDisclosure