Back to startpage CookieSecurity


Attack scenarios

1. Cookie Poisoning

Cookie Poisoning is a method to inject "poisoned" script code or manipulated data into a cookie. This attack can be performed on persistent cookies as well as on session cookies. An attack of this kind is just possible if a web application writes URL parameters directly in a cookie without any input filtering. When the cookie is read out and the content is displayed on a website without former Output Encoding, the injected code will be executed. Generally, Javascript is used for such attacks.

This provides an opportunity for easy cookie manipulation not only to the application users but also to external attackers, which could mislead users to execute malicious URL calls. Depending on the severity of the application's vulnerability, such attacks could lead to XSS, stealing of cookies, and session hijacking.

Example:

We assume there is an online shop providing the possibility to put data in a shopping cart. If the user finished his purchase he clicks a button to get the bill. In this example URL encoding is left out for the reason of better understanding.

There is a webapplication which directly writes the price down into a cookie. The URL is:

http://myApp.de/shop/calcbill

The prices are transferred from the server via an URL parameter to the client:

http://myApp.de/shop/calcbill?price=11.95+22.95

The content of the parameter "price" is directly written down in a cookie. Because there is no input filtering it's possible to inject malicious script code:

http://myApp.de/shop/calcbill?price=11.95+<script>alert('ATTACK')</script>

At this time nothing happened at all. But an attacker would send this URL e.g. in an Email to the victim and would hope that the victim executes the malicious URL. After calling the page the victim could automatically be forwarded to the bill where the poisoned script code will be executed.

http://myApp.de/shop/showbill

Usually the page just reads out the cookie and shows the different prices on the bill. This is just possible because the domain and the path saved in the cookie are the same as the web server's URL. In this example only a harmless script is executed but in reality an attacker could steal cookies and hijack sessions.

2. Manipulation

Cookies which are transmitted via HTTP are usually unencrypted and will be sent via the HTTP header. Also they will be stored unencrypted in a simple text file on the user's local hard drive. So each user can easily open the text file to look at the cookie's content and manipulate it. This kind of manipulation is only useful if sensitive data is stored in the cookie, of which manipulation a user can have advantages. To manipulate a cookie you don't need any special computer program - you just need a simple text editor and the knowledge about the directory, where the cookie text file is saved.

Example:

This example shows an E-Shop application. It is possible for the attacker to manipulate a cookie set by the application. Because this cookie contains information about the prices the total price on the bill can be lowered.

  • Step 1: In an E-Shop application a user can put different products in his shopping cart. This products and their price are saved in a cookie

  • Step 2: The attacker opens the cookie in a text editor or with other tools and sees the following content:

    item1_ID=1276&item1_pr=22.95&item2_ID=2234&item2_pr=11.95

  • Step 3: The attacker modifies the cookie for his advantage. He loweres the price.

    item1_ID=1276&item1_pr=2.95&item2_ID=2234&item2_pr=1.95

  • Step 4: The attacker calls the site where the bill is displayed. Insted of 34.90 the attacker would only have to pay 4.90.
< Previous page Next page >




Copyright © 2006 SAP AG. All rights reserved.
Legal Notice