1. Cookie Poisoning

"Never trust the input" - that's the central principle. That means that you have to check the user input for malicious scripts and data. There are two ways to do that. On the one hand you can do output encoding at the time the cookie is created and on the other hand you can do input filtering when the cookie is read out by the web server. Ideally you use both mechanisms. But we recommend that you do output encoding at all events because the cookie can be modified after creating it. You can find more information about these filtering methods in the XSS and XPath module.

2. Manipulation

To avoid manipulations as seen in the examples and the exercise it's reasonable not to save any sensitive data in a cookie. For example the price of products from a shopping cart should not be stored in a cookie. The best way to solve this problem is just to save a product id in the cookie and later catch the price of this product from a database. The user still can manipulate the cookie, but he won't take advantage of it.

You also should be aware of the fact that the connection and the cookies are unencrypted. If someone uses a network sniffing he can easily fetch your HTTP packages and see and manipulate your cookies. This problem is easy to solve by using a secure HTTPS connection and setting the "Secure" attribute in the cookie so that it's not passed to a server via HTTP connection.

Cookies with Session-IDs

Cookies should not be used to store sensitive data. In reality there exists no good alternative to store data over sessions. But in fact you can store data better than in the cookie directly. The best way as seen in the second part of the exercise is to register the browsers Session-ID on the web server and save user specific attributes on the server. The Session-ID itself is stored in the cookie and passed back every time you request the server. The web server can identify your browser this way. You find more information about this topic in the module Session Management.