Cuppa CMS is prone to a session fixation attack.
Description: Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim’s browser use it.
Enter the wrong username and password to generate dummy session tokens
Copy the non-authenticated session tokens and insert it into another browser(chrome) in the victim machine.
Enter the valid credential to log in to the application.
Once you login to the application go back to the attacker browser and refresh the URL.
An attacker is able to access the victim session successfully.
Session Values Before Login: Attacker Machine
Session Values Before Login: Victim Machine
Session token once fix the victim Machine
Session Values after Login: Victim Machine
Session Values for the attacker - Just refresh the browser
Mitigation:
The application should always first invalidate the existing session ID before authenticating a user, and if the authentication is successful, provide another session.
The text was updated successfully, but these errors were encountered:
Cuppa CMS is prone to a session fixation attack.
Description: Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim’s browser use it.
Steps to Reproduce:
Session Values Before Login: Attacker Machine

Session Values Before Login: Victim Machine

Session token once fix the victim Machine

Session Values after Login: Victim Machine

Session Values for the attacker - Just refresh the browser

Mitigation:
The application should always first invalidate the existing session ID before authenticating a user, and if the authentication is successful, provide another session.
The text was updated successfully, but these errors were encountered: