We use cookies on our website to ensure we provide you with the best experience on our website. By using our website, you agree to the use of cookies for analytics and personalized content.This website uses cookies. More Information
It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Web Application Firewall

Cookie Replay Attack

  • Last updated on


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

Host: www.social-site.com

Cookie: SESSION-ID=User-abc-logged-in-2341785645




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

Host: www.another-social-site.com

Cookie:LOGINID =1322015-zbkmacdfqssu




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.

Last updated on