Cookie Poisoning

Cookie poisoning attacks involve the modification of the contents of a cookie (personal information stored in a Web user's computer) in order to bypass security mechanisms. Using cookie poisoning attacks, attackers can gain unauthorized information about another user and steal his identity.

Detailed Description
Many Web applications use cookies to save information (user IDs, passwords, account numbers, time stamp, etc.). The cookies stored on a user's hard drive maintain information that allows the applications to authenticate the user identity, speed up transactions, monitor behavior, and personalize content presented to the user based on identity and preferences. For example, when a user logs into a Web site that requires authentication, a login CGI validates his username and password and sets a cookie with a numerical identifier in the user's browser. When the user browses to another page, another CGI (say, preferences.asp) retrieves the cookie and displays personalized content according to the values contained in the cookie.

Cookie poisoning is in fact a Parameter Tampering attack, where the parameters are stored in a cookie. In many cases cookie poisoning is more useful than other Parameter Tampering attacks because programmers store sensitive information in the allegedly invisible cookie. For example, consider the following request:GET /store/buy.asp?checkout=yes HTTP/1.0 Host: www.onlineshop.com Accept: */* Referrer: http://www.onlineshop.com/showprods.asp Cookie: SESSIONID=570321ASDD23SA2321; BasketSize=3; Item1=2892; Item2=3210; Item3=9942; TotalPrice=16044;

In this example, the dynamic page requested by the browser is called buy.asp and the browser sends the parameter checkout to the Web server with a yes value, indicating that the user wants to finalize his purchase. The request includes a cookie that contains the following parameters: SESSIONID, which is a unique identification string that associates the user with the site, BasketSize (how many items are in the purchase), the price of each item and the TotalPrice. When executed by the Web server, buy.asp retrieves the cookie from the user, analyzes the cookie's parameters and charges the user account according to the TotalPrice parameter. An attacker can change, for example, the TotalPrice parameter in order to get a "special discount".
Since programmers rely on cookies as a location for storing parameters, all parameter attacks including SQL Injection, Cross-Site Scripting, and Buffer Overflow can be executed using cookie poisoning.

Cookie Poisoning Attack Prevention
Solution....................................................Blocks cookie poisoning?
Imperva SecureSphere.......................YES
Firewalls...................................................No
Intrusion Detection Systems......................No
Intrusion Prevention Systems....................No

Detection of cookie poisoning attacks involves compound HTTP statefulness. The intrusion prevention product must trace down cookies "set" commands issued by the Web server. For each set command the product should store important information such as the cookie name, the cookie value, the IP address and the session to which that cookie was assigned as well as the time it was assigned. Next the product needs to intercept each HTTP request sent to the Web server, retrieve the cookie information out of it and check it against all stored cookies. If the attacker changes the content of a cookie the product should be able to identify that using the information it stores on the specific user. The product must trace application-level sessions and not just IP addresses in order to provide accurate results.

Intrusion Detection and Prevention Systems which are not Web application oriented simply do not provide this functionality. These products are unable to trace users by the application session and are unable to store information on each specific user currently logged into the Web application.