- From: Koen Holtman <koen@win.tue.nl>
- Date: Sat, 20 Apr 1996 00:05:12 +0200 (MET DST)
- To: hardie@nasa.gov
- Cc: dmk@allegra.att.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Ted Hardie:
>
>Dave,
>
[...]
>The list of Koen's dimensions for the
>solution space of stateful dialogs, for example, seems to be a useful
>thing for implementors to keep in mind, but I believe that the bullets
>would have to be fleshed out a good bit before someone who has not
>been following the discussion would be sure of what you meant.
Actually, I wrote this list as a checklist for seeing if a stateful
dialog _support_ mechanism (like cookies) is good enough. So the list
is for the http-wg, not for implementers, and can be deleted from the
draft. Fleshing it out is not worth the trouble I think.
[...]
>In Section 8.2, you discuss Cookie spoofing, but I believe that you
>are missing at least one of the possible problems--the way ___domain
>matching is described, it appears that someone from the host sub.tld
>could successfully get or spoof cookies for anyhost.sub.tld .
Eek! I believe you are right, we missed that case. anyhost.sub.tld
would indeed get
Cookie: $Version="1";
session_id="1234";
session_id="1111";
^^^^^No Domain=sub.tld here!
I believe NetScape's original cookie mechanism required a Domain= in
the Set-Cookie header in order for the session_id="1111" cookie set by
sub.tld to get sent to anyhost.sub.tld, but the current rules do not
require this.
We could tweaks the draft to solve this: we could change the following
sentences from Section 4.3.4:
The value for the
___domain attribute must be the value from the Domain attribute, if any, of
the corresponding Set-Cookie response header. Otherwise the attribute
should be omitted from the Cookie request header.
into
The value for the ___domain attribute must be the (default) value of the
Domain attribute of the corresponding Set-Cookie response header, if
this value is not equal to the request-host of the request to be
sent. Otherwise the attribute should be omitted from the Cookie
request header.
But I think the above tweak would not be the best solution (and we do
need to solve this). We could solve this, and better match current
use of ___domain=, and improve the readability of the draft in several
places, if we go for ___domain attributes which always start with a dot:
Set-Cookie: session_id="1111";Domain=".sub.tld".
Only the default ___domain attribute, the request-host, would not start
with a dot.
I include editing instructions which would bring this about below.
Note that there also are two editing instructions which fix a mistake
and an oversight in the draft, these are unconnected to domains
starting with dots.
> Best Regards,
> Ted Hardie
Koen.
--snip--
#2. TERMINOLOGY
#
Rewrite text below:
#Hosts can be specified either as an IP address or a FQHN string.
#Sometimes we compare one host with another. Host A ___domain-matches host
#B if
#
# * both hosts are IP addresses and their host strings match exactly;
# or
#
# * both hosts are FQHN strings and their host strings match exactly;
# or
#
# * both hosts are FQHN strings and host A's string has the form N.B,
# where B is host B's FQHN string, and N is a name string that may |
# have embedded dots, but not leading or trailing dots. If host B |
# has a leading dot, the leading dot is ignored. (So, x.y.com |
# ___domain-matches .y.com.)
#
#Note that ___domain-match is not a commutative operation: a.b.c.com
#___domain-matches c.com, but not the reverse. |
to:
Hosts can be specified either as an IP address or a FQHN string.
Sometimes we compare one host with a ___domain string. Host A
___domain-matches a ___domain B if
* the host is an IP address and equals the ___domain string
exactly;
* the host is an FQHN string and equals the ___domain string
exactly;
* the host is an FQHN string which has the from NB, where
where B is the ___domain string, and N is non-empty string.
(So the host x.y.com ___domain-matches the ___domain .y.com.).
#4.2.2 Set-Cookie Syntax The syntax for the Set-Cookie response header
Rewrite
#Domain=___domain
# Optional. The Domain attribute specifies the host and ___domain name
# for which the cookie is valid.
to
Domain=___domain
Optional. The Domain attribute specifies the ___domain for which
the cookie is valid. The ___domain must always start with a dot.
#4.3.2 Rejecting Cookies
#
#To prevent possible security or privacy
#violations, a user agent rejects a cookie (shall not store its
#information) if any of the following is true:
#
# * The value for the Path attribute is not a prefix of the request-
# URI.
Insert here:
* A value for the Domain attribute was supplied in the
Set-Cookie header, and this value does not start with a dot
#
# * The value for the Domain attribute contains no embedded dots. |
#
# * The value for the request-host does not ___domain-match the Domain *
# attribute.
#
Rewrite text below:
# * The request-host is a name (not IP address), D is the value of the
# Domain attribute, and request-host has the form H.D, where H is a
# string, and H contains one or more dots. |
to:
* The request-host is a name (not IP address), D is the value of
the Domain attribute, and request-host has the form HD,
where H is a string, and H contains one or more dots.
#
#Examples: |
#
# * A Set-Cookie from request-host y.x.foo.com for Domain=foo.com would
# be rejected, because H is y.x and contains a dot. |
Change Domain=foo.com above to Domain=.foo.com
#
# * A Set-Cookie from request-host x.foo.com for Domain=foo.com would |
# be accepted. |
Change Domain=foo.com above to Domain=.foo.com
#
# * A Set-Cookie with Domain=.com, Domain=com., or Domain=.com., will |
# always be rejected, because there is no embedded dot.
Delete `Domain=com., ' above.
#4.3.4 Sending Cookies to the Origin Server
#Domain Selection
# The Domain attribute of the cookie must ___domain-match the origin
# server's fully-qualified host name. *
OOPS!! The above text contains a mistake, it should be rewritten to:
Domain Selection
The origin server's fully-qualified host name must
___domain-match the Domain attribute of the cookie.
even if we don't switch to domains starting with a dot.
#8.2 Cookie Spoofing
#
#Proper application design can avoid spoofing attacks from related |
#domains. Consider:
#
# 1. User agent makes request to victim.hacker.edu, gets back cookie |
# session_id="1234" and sets the default ___domain victim.hacker.edu.
Oops! Why did I not notice this sooner? `hacker.edu' should of
course be `cracker.edu', or else old-time hackers will accuse us of
polluting their language.
Please do a global query-replace from `hacker.edu' to `cracker.edu'.
# 2. User agent makes request to spoof.hacker.edu, gets back cookie |
# session-id="1111", with Domain="hacker.edu". |
Change Domain="hacker.edu" above to Domain=".cracker.edu"
# 3. User agent makes request to victim.hacker.edu again, and passes |
#
# Cookie: $Version="1"; |
# session_id="1234"; |
# session_id="1111"; $Domain="hacker.edu" |
Change Domain="hacker.edu" above to Domain=".cracker.edu"
#
# The server at victim.hacker.edu should detect that the second |
# cookie was not one it originated by noticing that the Domain |
# attribute is not for itself and ignore it.
#
#8.3 Unexpected Cookie Sharing
#
Change the text:
#A user agent should make every attempt to prevent the sharing of session |
#information between hosts that do not ___domain-match.
to:
A user agent should make every attempt to prevent the sharing of session |
information between hosts that are not in the same ___domain.
That is all.
Received on Friday, 19 April 1996 15:12:01 UTC