Bugs item #3349227, was opened at 2011-07-01 20:05
Message generated for change (Comment added) made by gnombat
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3349227&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gnombat (gnombat)
Assigned to: Daniel Stenberg (bagder)
Summary: secure attribute in cookie does not work with equals sign

Initial Comment:
If an HTTPS server marks a cookie as secure with the "Secure" attribute, and it uses an equals sign, curl does not recognize the cookie as secure. This is best illustrated with an example: suppose the server returns the following 2 headers:

Set-Cookie: secure_without_equals=1; secure
Set-Cookie: secure_with_equals=1; secure=

Then suppose the server is accessed with curl:

curl --cookie-jar cookies-curl.txt https://SERVER

The resulting cookie jar is as follows:
...
... FALSE / TRUE 0 secure_without_equals 1
... FALSE / FALSE 0 secure_with_equals 1

With most other browsers and HTTP clients, both cookies are treated as secure. For example, with wget:

wget --save-cookies=cookies-wget.txt --keep-session-cookies -q -O- https://SERVER
...
... FALSE / TRUE 0 secure_with_equals 1
... FALSE / TRUE 0 secure_without_equals 1

This appears to be a problem in real-world applications; e.g., Microsoft servers sometimes return a Set-Cookie header with "secure=" in it.

$ curl -V
curl 7.21.7 (i686-pc-linux-gnu) libcurl/7.21.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: IDN IPv6 Largefile NTLM SSL libz

----------------------------------------------------------------------

Comment By: gnombat (gnombat)
Date: 2011-07-03 14:29

Message:
Regarding the RFC:

http://tools.ietf.org/html/rfc6265

The grammar in section 4.1.1 seems to allow only "Secure" (without
equals).

However, section 5.2 seems to allow equals with a "possibly empty"
attribute value?

   The user agent MUST use an algorithm equivalent to the following
   algorithm to parse the unparsed-attributes:

   ...

   4. If the cookie-av string contains a %x3D ("=") character:

          The (possibly empty) attribute-name string consists of the
          characters up to, but not including, the first %x3D ("=")
          character, and the (possibly empty) attribute-value string
          consists of the characters after the first %x3D ("=")
          character.

----------------------------------------------------------------------

Comment By: gnombat (gnombat)
Date: 2011-07-03 14:13

Message:
How is this for a "live" example? :)

http://live.com/

You will need an actual Microsoft "Live ID" (or whatever they are calling
it these days). Enter a valid ID and password and then submit. The actual
request leads to about half a dozen redirections, but only the initial POST
is the interesting one. It sets a cookie named WLSSC, which is apparently
intended to be secure.

As far as browsers go, I tested Firefox, IE, Opera, Chrome, and Safari,
and they all seem to treat "secure=" as equivalent to "secure".

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-07-03 12:24

Message:
Wonderfully non-compliant with the rather new RFC6265. Can you please give
me an example of an actual live and public web page that uses such a cookie
header.

Do most browsers handle this?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3349227&group_id=976
Received on 2011-07-03