100 likes | 336 Views
Cookies. Bill Chu. 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
E N D
Cookies Bill Chu
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 cookies • User visits portal.com and clicks on a banner ad, shoe.com, hosted by advts.com • 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 • User visits a banner ad on shoe.com, vacation.com, also hosted by advts.com • 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. • User visits a banner ad on vacation.com, skii.com, also hosted by advts.com • 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) © Bei-Tseng Chu Aug 2000