10-cookie-security.pptVIP

FF3: most specific cookie sent first * SOP: same as server-side read/write * RFC 2109 (cookie RFC) has an option for including domain, path in Cookie header, but not supported by browsers. * Both LSID and GAUSR are “secure” cookies; Alice visits automatically due to phishing filter * * * * * All these shopping carts stored data on browser non-keyed checksums (e.g. CRC) are sufficient for this purpose !! * * FF2, Chrome: HttpOnly cookie can be overwritten to by script (but cannot be read) 3rd party cookies often used for session management. Consider . It is a 1st party when accessing from but a 3rd party when accessing from yahoo.co.uk * 3rd party becomes first party by doing: Set document.local = “3rd party address”, Set cookie Set document.location back to original value (obtained from the referer header) * Cookie Same Origin Policy Dan Boneh CS 142 Winter 2009 Monday: session management using cookies Same origin policy: “high level” Review: Same Origin Policy (SOP) for DOM: Origin A can access origin B’s DOM if match on (scheme, domain, port) Today: Same Original Policy (SOP) for cookies: Generally speaking, based on: ([scheme], domain, path) optional scheme://domain:port/path?params scope Setting/deleting cookies by server Delete cookie by setting “expires” to date in past Default scope is domain and path of setting URL Browser Server GET … HTTP Header: Set-cookie: NAME=VALUE ; domain = (when to send) ; path = (when to send) secure = (only send over SSL); expires = (when expires) ; HttpOnly (later) if expires=NULL: this session only Scope setting rules (write SOP) domain: any domain-suffix of URL-hostname, except TLD example: host = “” ? can set cookies for all of .  but not for another site or TLD Problematic for sites like . path: can be set to anything allowed domains . disallowed domains .com Cookies are identified by (name,domain,path) Both cookies stored in browser’s