Session Replay attack occurs when an attacker steals a valid session ID of a user, and reuses it to impersonate as an authorized user to perform fraudulent transactions/activities. A user becomes a victim of session replay attack when session ID’s have no session expiration time set, or the session data is stored in unencrypted form. Web applications that allow reusing old session ID’s or session credentials for authorization are vulnerable to session replay attack.
A session ID is a unique number assigned to identify a user accessing a web application. The session ID can be in the form of cookies or IDs in the parameter values. Once the user is authorized to access a web application, a session ID is created for that user. The session IDs confidentiality should be maintained so that other users or attackers do not use it to access the same account. Some web applications allow replaying (reusing) the old session ID to access the resources, without re-authenticating the user. If the session ID is stolen, the attacker uses it to masquerade as an authorized user.
If the session ID is stolen, the attacker can:
- Use the session ID to keep track of the users.
- View the user’s account details.
- View the user’s account and perform fraudulent transaction/activity.
The following parameters should be sanitized properly before processing the request:
- Form Parameters (GET and POST method)
Web applications using session ID as parameter in the request:
For example, if a web application maintains a session of the user based on the parameter in the request, then the attacker can append any value to that parameter and make a valid user to login. Once the user starts the session with appended value, the attacker gains access to the web application.
If the web application uses the SESSIONID parameter in the URL, i.e. http://vulnerable.com/home/show.php?SESSIONID=MYSESSION , in this the SESSIONID value is MYSESSION and if the user logs in with his credentials, then a SESSION called MYSESSION is started.
If the attacker makes a valid user to click on a URL like: http://vulnerable.com/home/show.php?SESSIONID=ATTACKER-SESSION , the valid user would be asked to provide credentials. If the user enters the credentials and logs in, then a session called ATTACKER-SESSION will be started by the server to the valid user. Now, the attacker can directly access the session of that user with just the URL http://vulnerable.com/home/show.php?SESSIONID=ATTACKER-SESSION .
To mitigate session replay attacks,
- A web application should invalidate a session after it exceeds the predefined idle timeout, and after the user logs out.
- Set the lifespan for the session to be as short as possible.
- Encrypt the session data.
You can prevent the session replay attacks by configuring Session Timeout for web applications and cookie security on the Barracuda Web Application Firewall.