note 21439 added to function.setcookie
| From: | public at macfreek dot nl | Date: | Mon, 13 May 2002 12:31:57 +0000 |
| Subject: | note 21439 added to function.setcookie | ||
| Groups: | php.notes | ||
| Request: | Send a blank email to php-notes+get-30580@lists.php.net to get a copy of this message | ||
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.
--
http://www.php.net/manual/en/function.setcookie.php
http://master.php.net/manage/user-notes.php?action=edit+21439
http://master.php.net/manage/user-notes.php?action=delete+21439
http://master.php.net/manage/user-notes.php?action=reject+21439