Client State Tracking with Netscape Cookies
What's all the fuss about?
- Cookies are becoming a buzzword, despite some conceptual drawbacks
- They actually CAN be useful
- Some high-profile services are being built around them
Highlights of our little chat
- Why do I care? Good question, have another beer.
- Move over, toasters: Flying Cookies in HTTP
- That's the way the cookie crumbles: Structure of Cookies
- Sample recipes: Some Real-World Applications
Stateless Protocol seeks State
Advantages of cookies vs. embedded URL tokens
- invisible, transparent
- less subject to tampering
- don't interfere w/bookmarking
What are cookies good for?
- Presenting useful "virtual session" information after an arbitrary delay
- Building up state interactively
- Exchanging non-user-friendly info between server & client
- Minimal "security through obscurity"
Presenting "virtual session" info
- Users love to be recognized, hate logging in
- Users love customization, hate retyping
- Session tracking supports customization
- are you a frequent user?
- what's new since you last visited?
- were you in the middle of something when you left?
Building up state interactively
- Establishing one-time preferences via a dialogue, for later compression into a single state
- custom page layout services, such as MSN
- Cumulative choice applications
- online mall "shopping cart" model
Exchanging non-user-friendly info
- Big hairy numbers
- customer id
- license info
- compressed state tokens
- Machine-gathered data
- how many times you logged in
- how long ago
- what you did last time you were here
Minimal "security through obscurity"
- Messing with cookies requires slightly more ingenuity than messing with embedded tokens
- User has to go to the effort of watching cookies rather than seeing tokens fly by in the URL
- Passing encoded or tokenized "ascii-armored" blocks can be done in cookies, thus wrapping your state data in a protected envelope
What browsers support cookies?
- Enhanced Mosaic 2.10.35 Win16 FTP Software Spyglass 35
- GNNworks v1.2.0
- Mozilla (ie Netscape, all CURRENT versions)
- NetCruiser V3.0
- NetManage Chameleon WebSurfer 5.0 (mixed, 2 OK, 1 No)
- OmniWeb 2.0.3 OWF 1.0
- Pueblo 1.1, Microsoft Windows NT 4.0, Intel Pentium, Winsock 12.0, 20.0, a (mixed, 2 OK, 2 bad values)
- STBWeb 0.20 (mixed, 1 OK, 1 No)
- Spyglass Mosaic 2.11 Win32 Spyglass 5
History of term "cookie"
- The Netscape preliminary spec says it was chosen "for no compelling reason
- No need to quote the Jargon File/New Hacker's Dictionary
- MIT ITS machines (and others!) "cookie monster" programs
- MIT-MAGIC-COOKIE in X-Windows probably first large-scale usage
Other systems using cookies
- In a sense, anything using a lock file to denote a resource in use (file's existence is the cookie)
Netscape cookie spec
- "preliminary" spec only
- circa early 1995
- still an evolving system
What's a cookie?
- Text in a file OR
- an HTTP response header field
- subject to standard HTTP Response Header constraints
- subject to cookie constraints
HTTP Response Header constraints
charset = "US-ASCII" | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3" | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6" | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR" | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8" | token
Specific cookie constraints
- 4K size limit
- 300 simultaneous instantiations
- 20 simultaneous instantiations per FQDN
Where do they live?
- short answer is "a magic file"
- better answer is "kinda sorta in memory and also in a magic file"
- file location, accessibility, is implementation specific
How do I get cookies?
- point your browser to www.girlscouts.org
- yes, this is a real URL
- no, they don't sell the cookies online
- why? because the revenue goes 100% to the local group and it would compete with their own groups
- we now return you to your regularly scheduled presentation
How do I get Netscape cookies?
- from a Netscape server, in your HTTP return transaction, from a "Set-Cookie: " response header returned to you
Here's where the fun begins...
HTTP Request: Client
- Ask for http://www.foobar.com/my/url.html
- Browser parses URL
- Browser compares URL FQDN against all known cookies
- Browser compares URL path against path attribute of matching FQDN or DN cookies
- Browser does DNS lookup of FQDN
- Browser sends HTTP Request to IP address obtained, including an HTTP Response Header of the form "Cookie: a=VALUE ; name3=VALUE ...."
HTTP Response: Server
- Server gets Browser request
- Server URL presumably can make use of cookie, since Browser got it from Server in first place at some point in the dim past
- overall wrapper set in magnus.conf file may do something with cookie)
- URL may be a CGI that will do something with cookie
- Server replies with content to Browser; content probably includes a Set-Cookie header
- Browser handles Cookie
HTTP Response: Client
- Browser snags incoming data, parses
- Browser takes first Set-Cookie header, looks for domain field matches
- Browser does reverse lookup on IP address where data originated, gets FQDN
- Browser modifies stored cookies matching FQDN with applicable updates from the Set-Cookie header
- Do until bored, or out of cookies
- Display data to patient user
What is likely to blow up? (security concerns)
- DNS & Spoofing Attacks
- Resource Allocation
- User Idiocy
DNS & Spoofing
- cookies rely VERY heavily on DNS info being correct
- reverse lookups used to “authorize” cookie destructive refresh/rewrite
- forward lookups used to determine which cookies proffered to server in request
- see CERT advisories on BIND vulnerability, IP spoofing; relatively easy to do and becoming more widespread
- silent failures due to too many cookies per FQDN, or too-big cookies;
- spec handwaves on correct behaviors for allocation and GCing of cookies
- behavior of truncated cookies not addressed in spec
- 4096 limit is really NAME/VALUE; truncation is in spec for other parts
- if path trunc'd will they match all or none?
- ditto FQDN truncation
- what is REAL limit of cookie, not name/val limit?
- applications ignoring resource allocations detailed above, esp. number of cookies per FQDN
- cookies are sent in cleartext unless marked secure; just because the user can’t *see* his credit card number going out in ASCII...
- users assuming that because they *can* edit their cookies file, they will accomplish something useful by doing so
Fine Structure of Cookies
- Set-Cookie: name=VALUE; [expires=GMT_DATE_STRING;] [path=PATH;] [domain=FQDN;] [secure]
- spec indicates that browsers fill in optional fields from requesting URL
- restricted chars: colon, semicolon, whitespace
- also HTTPD resp header restrictions
- that ol' 4096 again
- defaults to "this session"
- implementation specific-- window or program close ends session?
prelim spec documents Netscape 1.1 bug, only / path cookies properly saved between sessions
- default is FQDN of rev lookup of URL response
- tail matching FQDN for wildcarding
- only Set-Cookie from foo.com can affect foo.com cookies
- default is path of URL response
- TEST: how does attribute affect, if at all?
- path only eval'd once FQDN checked
- if on, cookie only transmitted to secure servers
- what is "secure", https urls or port 443?
- How are they checking?
What services out there are using cookies?
- Microsoft Network custom pages
- New Netscape Personal Workspace
- Your Name Here :-)
Cookies in the Real World: SiteTrack
- server add-on to Netscape API
- master wrapper library
- intercepts cookies and does database stuff on them
- transparent to users and to webmaster
- doctors server output to put session tracking cookies in
A Few Cookie Pointers
- Andy’s Netscape HTTP Cookie Notes
- http://www.illuminatus.com/cookie_pages/TasteTest.html (Cookie test & set CGI)
- Results of Form Test: Cookie Support
- Strata's Cookie Page
- http://www.virtual.net/Projects/Cookies/ (a collection of other links, coming soon)
All the links in this presentation are
M. Strata Rose,
all rights reserved.