Cookies

Bill Chu

© 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

© 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

© 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

© 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

© Bei-Tseng Chu Aug 2000

Elements of a cookie (cont) Secure

Whether to send cookies only in encrypted connections

© Bei-Tseng Chu Aug 2000

Digital foot print with cookies1. User visits portal.com and clicks on a banner ad, shoe.com, hosted

by advts.com2. 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.

© 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.

© 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

© 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)