Enable SESSION_COOKIE_SECURE by Default

[Carlton Gibson]

Hi all. 

https://code.djangoproject.com/ticket/30314

>  Per the documentation, "Leaving this setting off isn’t a good idea because an attacker could capture an unencrypted session cookie with a packet sniffer and use the cookie to hijack the user’s session."

>

> If it's not a good idea for this setting to be off, why is it off by default? Seems backwards to me.

This looks right to me. A small breaking change for 3.0 would seem reasonable. So I'm going to Accept this. 

BUT this has been this way forever so I just wanted to check if there were any overriding Whys?

Thanks. 

Carlton

[Matthias Kestenholz]

(The same reasoning should probably be applied to CSRF_COOKIE_SECURE.)

My opinion is that this isn't a good idea. Right now it's possible to always have the SecurityMiddleware in MIDDLEWARE without adding any security-specific settings to the default setup. You get the following benefits:

- Authenticating when developing locally works (as I understand it it does not with *_COOKIE_SECURE set to True because you can't authenticate anymore on the http: development server)

- You get the SecurityMiddleware's warnings if you do not enable those settings when DEBUG=False

I fear that more people will remove the SecurityMiddleware (which is in the default setup) instead of deactivating secure cookies for local development which means a net negative for security.

Thanks,

Matthias

 

[Carlton Gibson]

Hi Matthias, 

Yes, super thanks. Breaking login in development would qualify as a good Why yes. 🙂

I'll assume we're NOT going to do this, but anyone with input, please do comment. 

> (The same reasoning should probably be applied to CSRF_COOKIE_SECURE.

Absolutely. And, soon, `LANGUAGE_` too. https://github.com/django/django/pull/11155

Thanks. C. 

On Wednesday, 3 April 2019 10:19:15 UTC+2, Matthias Kestenholz wrote:

[James Bennett]

On Wed, Apr 3, 2019 at 2:34 AM Carlton Gibson <carlton...@gmail.com> wrote:

Yes, super thanks. Breaking login in development would qualify as a good Why yes. 🙂

I'll assume we're NOT going to do this, but anyone with input, please do comment. 

Historically I've done something along the lines of

CSRF_COOKIE_SECURE = not DEBUG

SESSION_COOKIE_SECURE = not DEBUG

That guarantees I never go to production without the cookies set to secure, but also avoids breaking local dev. I do similar things with other SSL-related settings.

I'm not sure how well it generalizes to other people's use cases, though. 

[Matthias Kestenholz]

I do this too, but not using "not DEBUG" but SECURE_SSL_REDIRECT (or the related setting for django-canonical-domain). It might be a good idea to add something like this to the project template?

[Aldian Fazrihady]

Hi Carlton,

Many production systems, including mine, are using HTTPS, which effectively blocks the capability of attackers from sniffing other people's cookies.

Regards,

Aldian Fazrihady

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e67ee6a2-751e-4b24-9d72-6c746a8c0178%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Bennett]

On Wed, Apr 3, 2019 at 4:31 AM Aldian Fazrihady <mob...@aldian.net> wrote:

Many production systems, including mine, are using HTTPS, which effectively blocks the capability of attackers from sniffing other people's cookies.

Closing off opportunities to sniff cookies is more complex than just using HTTPS, which is why the 'Secure' and 'HttpOnly' flags exist on cookies, why HSTS and preloading exist, and several other mechanisms.

If you are using HTTPS, you should have both SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE set to True. This thread is discussing whether and how we could default those to True.