"secure" cookies not getting recognized on localhost

[mukesh-610]

I did this

Command issued:

curl --cookie-jar cookies.txt -siX POST -H "Content-Type: application/json" -d '{"email": "email@dummy.com", "password": "password"}' http://localhost:8080/login

I expected the following

I got a Set-Cookie header like this:

Set-Cookie: JSESSIONID=6EE0DE37D3A1C69A4FCFFA5931821B49; Path=/; SameSite=None; Secure

I hoped that the cookie will get written to the cookie jar, but it was not the case. There were no cookies in the file. The following was the contents of the cookie jar after execution:

# Netscape HTTP Cookie File
# https://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

curl/libcurl version

curl 7.69.1 (x86_64-w64-mingw32) libcurl/7.69.1 OpenSSL/1.1.1e (Schannel) zlib/1.2.11 libidn2/2.3.0 libssh2/1.9.0 nghttp2/1.40.0
Release-Date: 2020-03-11
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz Metalink MultiSSL NTLM SPNEGO SSL SSPI TLS-SRP

operating system

Windows. I got curl packaged along with git bash (https://gitforwindows.org/).

comments

I tried it under Linux and it works perfectly. I couldn't get it to work with the curl packaged along with my git bash.

[bagder]

Are you using the same curl version on Linux vs Windows? I note that the cookie says secure and you're getting it over http:// (ie not secure) which I suspect is the reason.

[mukesh-610]

The curl version on Linux:

curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2u zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

The Windows version was a little more recent compared to this.

I executed the same command under Linux. The Set-Cookie header was also similar:

Set-Cookie: JSESSIONID=6135D2A1DC70D08AC434D77503339128; Path=/MLP318; SameSite=None; Secure

The cookie jar:

# Netscape HTTP Cookie File
# https://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

localhost       FALSE   /MLP318 TRUE    0       JSESSIONID      6135D2A1DC70D08AC434D77503339128

The cookie indeed had Secure flag set, but this curl version under Linux had no problem storing it. But while loading back the cookie (--cookie cookies.txt), it wasn't transmitted to the server, presumably due to having the Secure flag.

While I understand that secure cookies are intended to be transmitted over a https connection, it would be nice to have curl treat localhost as secure by default (even over HTTP), or at least include a CLI option for this behaviour. Mozilla Firefox already does this.

[danielgustafsson]

7.52 is not exactly recent, the changes to restricting secure cookies came in 7.64.0. If you upgrade your curl on Linux it will match the behavior on Windows.

[bagder]

it would be nice to have curl treat localhost as secure by default (even over HTTP)

Agreed! @danielgustafsson maybe something to consider while you're there poking on cookies atm?

[danielgustafsson]

it would be nice to have curl treat localhost as secure by default (even over HTTP)

Agreed! @danielgustafsson maybe something to consider while you're there poking on cookies atm?

Indeed, I was just reading up on it. Will add it to my small cookie TODO list.

[bagder]

One problem here: localhost is not guaranteed to be a local address in curl. It will still resolve the name and it might at times resolve to something else than 127.0.0.1 and then it isn't local.

I think that name resolving detail needs to be fixed before we can consider localhost to be secure. Web browsers don't resolve localhost anymore for this purpose.

[bagder]

See #7039 for a take on "localhost" to always be truly local.

[bagder]

I've labeled this "enhancement" as this is functionality we never attempted to support before.