Cookie
Manipulation
HTTP is a stateless protocol. In 1994, Netscape invented a mechanism called a “cookie” as a method for session tracking. A cookie is a small piece of information usually created by the Web server and stored in the Web browser. Each time the user contacts the Web server, this data is passed back to the server. The cookie contains information used by Web applications to persist and pass variables back and forth between the browser and the Web application.
There are two types of client-side cookies:
● Persistent cookies: which are stored in a file on the client until an expiry date.
● Session cookies: which are kept in the memory of the client until the session is ended.
As a result of the cookie structure and their usage, all data stored in a client-side cookie could be easily read and manipulated. The risk of tampering with data and even information disclosure is very high. Due to the fact that many cookies are Base64 encoded, no cryptographic protection is offered. The best practice to avoid cookie manipulation is to be suspicious of data stored in cookies.
Example Code (Cookies sent by the server, the first one being persistent)
HTTP/1.1 200 OK |
Example Code (Cookie sent by the client)
POST /index.epx HTTP/1.1 |
Session tracking mechanisms within Java development on the SAP NetWeaver platform follow the Java EE standard. There is no additional support from the SAP NetWeaver platform with regard to improving security beyond the general recommendations of the Java EE standard (see next section).
...
1. Store all data in the HttpSession object.
The HttpSession object of the Java EE standard allows you to track sessions with an object residing on the server side. It solves the problem of session tracking when the user has disabled the cookies mechanism in his or her Web browser on the client side.

Example Code (Using HttpSession)
import javax.http.servlet.HttpSession; |
For more information, see the J2EE Session Tracking API:
java.sun.com/products/servlet/2.2/javadoc/index.html
2. Do not store ANY data in a client cookie, unless you absolutely have to. Hackers can easily manipulate client-side cookies. Cookies should be used for the following purpose only:
○ To maintain session IDs.
○ To persist certain information on the browser.
3. Dealing with cookies, the following security considerations have to be taken into account:
○ Use the session management that the SAP NetWeaver platform provides. Do not create your own.
○ Never store any confidential data in a cookie, such as the non-public IP addresses of target servers, host names, or system IDs.
If information of this type is important for control, you should use a hash procedure for one-way encryption of the data.
○ Use idle timeouts for applications that expose private data or that may cause identity theft if left open.
○ Offer a logout mechanism to the user, to manually shorten the time until a session timeout will automatically end the session.
Sometimes cookies may contain personal information, if programmers do not follow the advice never to store any confidential data in a cookie. The extent of cookie manipulation ranges from session tokens to arrays that make authorization decisions. Cookie poisoning can even lead to vulnerabilities such as SQL injection and cross-site scripting.
Original Cookie:
Cookie: lang=en-us; ADMIN=no; y=1; time=10:30GMT; |
Cookie Modified by an Attack
Cookie: lang=en-us; ADMIN=yes; y=1; time=12:30GMT; |
Shopping carts used to store pricing information in cookies.
Part of a Shopping Cart Application’s Cookie:
item1_ID=12369&item1_pr=27,95&item2_ID=10334&item2_pr=19,95 > Total Amount: $47,90 |
Manipulated Cookie
item1_ID=12369&item1_pr=0,95&item2_ID=10334&item2_pr=1,95 > Total Amount: $2,90 |
● OWASP Guide Version 2.0.1 (Pages 147 – 160)

surfnet.dl.sourceforge.net/sourceforge/owasp/OWASPGuide2.0.1.pdf
● Writing Secure Web Applications (Slides 50 – 51)

www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/events/sap-teched-04/Writing%20Secure%20Web%20Applications.pdf
● J2EE Session Tracking API

java.sun.com/products/servlet/2.2/javadoc/index.html