note 21439 deleted from function.setcookie by tularis
| From: | tularis@php.net | Date: | Sun, 02 Jan 2005 14:40:26 +0000 |
| Subject: | note 21439 deleted from function.setcookie by tularis | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-82595@lists.php.net to get a copy of this message | ||
Note Submitter: public at macfreek dot nl
----
Your link to the Cookie specification is very out-of-date. There are two newer specification which
are adopted by the IETF:
http://www.netscape.com/newsref/std/cookie_spec.html
"Persistent Client State -- HTTP Cookies"
http://www.ietf.org/rfc/rfc2109.txt "HTTP
State Management Mechanism"
http://www.ietf.org/rfc/rfc2965.txt "HTTP
State Management Mechanism"
RFC 2965 specifies the Set-Cookie2 syntax, RFC 2109 specifies the Set-Cookie syntax, which is
commonly used (and I recommend is used at the moment).
These RFC have a better security section, and deal with things like Spoofing (see exerpt bellow):
Proper application design can avoid spoofing attacks from related domains. Consider:
1. User agent makes request to victim.cracker.edu, gets back
cookie session_id="1234" and sets the default domain
victim.cracker.edu.
2. User agent makes request to spoof.cracker.edu, gets back cookie
session-id="1111", with Domain=".cracker.edu".
3. User agent makes request to victim.cracker.edu again, and
passes
Cookie: $Version="1"; session_id="1234",
$Version="1"; session_id="1111"; $Domain=".cracker.edu"
The server at victim.cracker.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.