Monday, 29 November 2010

Cookie Poisoningla






Subjected to Defend Hackers
 Cookie Poisoning
Guys ..today we gonnna discuss about Web Application Security..!!
As I think u people Would Kno The Diff between Web n Network Security..
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.

Details
Many Web applications use cookies to save information (user IDs, passwords, account numbers, time stamps, 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;



Add Yield Manager (DefendHackers)
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.

Prevention

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. 



A Scenario From Use Case Model Tool(Defend Hackers)

Intrusion Detection and Prevention Systems which are not Web application oriented simply do not provide this functionality.
Researchers Working Around this flaw and Often Tools are available Google it ..!! 
Like It..Drop Comments..!!

No comments:

Post a Comment