A cookie replay attack occurs when an attacker steals a valid cookie of a user, and reuses it to impersonate that user to perform fraudulent or unauthorized transactions/activities.
Once an attacker steals a cookie, he can effectively impersonate the user as long as the cookie remains valid. The attacker can do anything that the user can within his or her account.
Cookies can be stolen in transmit or at the client endpoints. The former is usually the case when SSL is not being used and a man-in-the-middle is able to snoop on the traffic. Cookies can also be stolen directly from the client machines using a secondary vector like XSS, malware etc.
There are many ways session hijacking can be performed:
Example 1: Using the session cookies issued to the user by the server.
For example, if there is a social networking site with a valid user logged-in, and the server has issued a session cookie “SESSION-ID” to the user. If the SESSION-ID is the cookie that identifies the session of the user, the attacker can use the SESSION-ID cookie value to login as the valid user.
The attacker can perform a cross-site scripting or other technique to steal the cookie from the victim’s browser. Let’s assume the attacker steals the cookie SESSION-ID=User-abc-logged-in-2341785645. Now, he can use the cookie with the following request to post a status (I am hacked!!!!!!) in the victim’s home page:
POST /home/post_status.php HTTP/1.1
Status=I am hacked!!!!!!&Submit=submit
The attacker uses the cookie issue to the authorized user, and gains control on the user’s session.
In this example, the server failed to check the client IP address and browser information in the request, which led to cookie and session hijacking.
Example 2: Guessing the cookie values of users if a complicated algorithm is not used for the cookie generation
For example, consider a social networking website (www.socialnetworking-site.com) uses an algorithm to generate cookies for the users. If the user name is “John”, then the cookie generated for the user could be “LOGINID=1322015-iknpgimo”. In this case, the algorithm used to generate the cookie can be as follows: first part of the cookie is the date i.e. 13/2/2015, and second part is the combination of the previous and following alphabet letter for each letter of the username “John” (i.e., the previous letter for J is “I” and the following letter is “k”). If the attacker is able to crack the algorithm, he could guess the cookie of users and hack their session.
If the hacker plans to hack the session of Albert, he can create a cookie as LOGINID =1322015-zbkmacdfqssu, login to Albert’s session and post a status on his account.
POST /Status/post.asp HTTP/1.1
Todays_status=I am hacked!!!!!!&Submit=submit
To mitigate cookie 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.
- Have a mechanism to detect when a cookie is seen from multiple clients
You can prevent cookie replay attacks by configuring "Cookie Protection" policies on the Barracuda Web Application Firewall. Among other things, it can also detect when a cookie is seen from multiple IP addresses and allows mitigating controls when this happens.