1. Cookies Bill Chu

2. © Bei-Tseng Chu Aug 2000 Definition A cookie is a TEXT object of max 4KB sent from a web server to a browser It is intended for the server to maintain session information on top of the basic http protocol It can be used for Remember longin and passwords, e.g. Yahoo mail Keep track of items in an online shopping cart Maintain a user profile, e.g. interested news categories

3. © Bei-Tseng Chu Aug 2000 Operation A cookie is always created by the server, typically a program e.g. CGI script or servelet It is “pushed” from the server to the browser When the browser connects back to the server, the server can retrieve all its cookies from the browser

4. © Bei-Tseng Chu Aug 2000 Elements of a cookies Comment Domain A server can only read cookies that are set by a server of the same domain. (servers for bali.vacation.com and mexico.vacation.com can both read cookies set for vacation.com, but not for cookies set for travel.com) Age Life time limit of the cookies If the again is negative, then the cookies is only good as long as the browser is active. When the browser is closed, such cookies are destroyed A cookie of again greater than one will be saved to the disk by the browser

5. © Bei-Tseng Chu Aug 2000 Elements of a cookie (continued) Name Value The name and value pair contains information that is most relevant for applications using cookies Path Similar to domain, path limits the visibility of cookies based on the URL path. For example cookies sent by http://ecommerce.site.com/toys/special.htm is visible to http://ecommerce.site.com/toys/bikes/bg.htm but not to http://ecommerce.site.com/cds/classical.htm http://ecommerce.site.com/toys/special.htm http://ecommerce.site.com/toys/bikes/bg.htm

6. © Bei-Tseng Chu Aug 2000 Elements of a cookie (cont) Secure Whether to send cookies only in encrypted connections

7. © Bei-Tseng Chu Aug 2000 Digital foot print with cookies 1. User visits portal.com and clicks on a banner ad, shoe.com, hosted by advts.com 2. advts.com pushes a cookies to the browser: portal.com::shoe.com, it then directs the user to shoe.com, passing that path information to shoe.com 3. User visits a banner ad on shoe.com, vacation.com, also hosted by advts.com 4. advts.com reads cookies from the browser, updates the cookie to: portal.com::shoe.com::vacation.com, it then directs the user to vacation.com, passing that path information to vacation.com. 5. User visits a banner ad on vacation.com, skii.com, also hosted by advts.com 6. advts.com reads cookies from the browser, updates the cookie to: portal.com::shoe.com::vacation.com::skii.com, it then directs the user to skii.com, passing that path information to skii.com.

8. © Bei-Tseng Chu Aug 2000 Possible acts of privacy violation advts.com could attach a unique number to each digital foot print it tracks Supposed our user bought a pair of shoes from shoe.com, suppose the id associated with this digital foot print is 1234. When vacation.com gets the info from advts.com that our user has just visited shoe.com, vacation.com could contact shoe.com and ask what did browser session 1234 buy? If our user has bought a pair of hiking shoes, then vacation.com can high light vacation packages for the mountains.

9. © Bei-Tseng Chu Aug 2000 Possible Security Risks for cookies Cookie poisoning: Cookie information has been modified by malicious users E.g. e-shoplifting, e-identity theft

10. © Bei-Tseng Chu Aug 2000 Cookie authentication guidelines Use SSL for username/password authentication Do not store plain text or weakly encrypted password in a cookie The cookie should not be re-used or re-used easily by another person Password or other confidential info should not be able to be extracted from the cookie Cookie authentication credential should NOT be valid for an over extended length of times Set up “booby trapped” session tokens that never actually get assigned but will detect if an attacker is trying to brute force a range of tokens. (Whenever possible) Tie cookie authentication to an IP address (part or all of the IP address) Adding “salt” to your cookie (e.g. hashed http header of a particular browser, MAC address) Re-authenticate whenever critical decisions are made Over write tokens upon logout. Consider using server side cache to store session information, only retain an index to the cache on the client side (also use ‘booby trapped’ indices)