Bugs item #3349227, was opened at 2011-07-02 03:05
Message generated for change (Comment added) made by bagder
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: Closed
>Resolution: Fixed
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: Daniel Stenberg (bagder)
Date: 2011-08-09 15:40

Message:
Thanks for the report, this problem is now fixed in the git repository.

To try it out, you either checkout/update your git clone:
http://curl.haxx.se/source.html

or you try tomorrow's daily snapshot: http://curl.haxx.se/snapshots/

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

Comment By: Daniel Stenberg (bagder)
Date: 2011-07-06 22:21

Message:
@Vignesh: we already have such an interface to libcurl, so it would just be
a matter of exposing it to the command line interface. But that's not a
subject for this bug report.

We have a patch being discussed on the mailing list for fixing this
particular issue.

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

Comment By: Vignesh Saravanai (svignesh)
Date: 2011-07-06 10:20

Message:
Interesting part in live.com example is if WLSSC cookie is sent for
non-secure request, they redirect you to login page :( (it looks like they
implemented it last week)

All scripts using curl to automate live.com got broken.

I was trying to figure out a work around. Deleting cookie stored in memory
is not yet supported in curl. I have to store the cookies to a file,
construct a new cookie file without WLSSC cookie and then load the new
cookie.

IMHO, we need an interface to delete/update a cookie in curl.

Thanks,
Vignesh.

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

Comment By: Daniel Stenberg (bagder)
Date: 2011-07-03 21:46

Message:
Argh. You're right of course...

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

Comment By: gnombat (gnombat)
Date: 2011-07-03 21: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 21: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 19: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-08-09