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 their identity.
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.
The Imperva SecureSphere Web Application Firewall (WAF) can block cookie poisoning attacks while solutions such as network firewalls, intrusion prevention, and intrusion detection systems are not effective.
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.