django-admin startproject settings.py has some security holes

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

django-admin startproject settings.py has some security holes

Bobby Mozumder
In particular, they include settings that shouldn’t be stored in a git repo such as SECRET_KEY and database passwords. You’ll find these kinds of settings in git repos all the time.

Really the default django-admin startproject shouldn’t have a single settings.py that people include in their git repos, but instead a python settings module, with a base.py, development.py, staging.py, and production.py. An __init__.py reads base.py and one of development/staging/production based on ENV variables (defaulting to development if no ENV variable).

Additionally, startproject should add a .gitignore in the root directory to not include development/staging/production settings files.

I get that this might not be absolutely necessary but I think these are the kinds of defaults that make practical real-world use more secure, as well as standardizing workflow for more advanced production usage.

Is this something agreeable? I can put together a solution if people like this.

-bobby
   

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/320B70FD-BDC1-445D-B72B-0CD0BA736B88%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Ehigie Aito
Hello Bobby,
I think this should be added to a best practises documentation and not codified in Django. As I feel that would be overkill. 

On Thu, 10 Oct 2019, 20:41 Bobby Mozumder, <[hidden email]> wrote:
In particular, they include settings that shouldn’t be stored in a git repo such as SECRET_KEY and database passwords. You’ll find these kinds of settings in git repos all the time.

Really the default django-admin startproject shouldn’t have a single settings.py that people include in their git repos, but instead a python settings module, with a base.py, development.py, staging.py, and production.py. An __init__.py reads base.py and one of development/staging/production based on ENV variables (defaulting to development if no ENV variable).

Additionally, startproject should add a .gitignore in the root directory to not include development/staging/production settings files.

I get that this might not be absolutely necessary but I think these are the kinds of defaults that make practical real-world use more secure, as well as standardizing workflow for more advanced production usage.

Is this something agreeable? I can put together a solution if people like this.

-bobby


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/320B70FD-BDC1-445D-B72B-0CD0BA736B88%40gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BB1BD6kxbSR_fOwAWxY%3DtjRA30YPcYVt87%2BHguOKyZBOnHnuQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Christian González

Hi, may I disagree - I set up projects very often (for testing a package), and I always feel a bit awkward because of that monolithic settings.py file.

I can really support Bobby's idea, even if development/staging/production may be a bit overkill. Having a practical standard which ensures good practice from the start is a good thing. And OTOH, it won't hurt anyone if these files are there.

As there was another discussion earlier about "declarative" settings - maybe it would be helpful to exclude some of the settings from settings.py which is code, not declaration. SECRET_KEY could be anywhere by default, it doesn't have to be in an executable .py file. But this would mean to change Django's code to read it before or after importing settings.py.

+1 for a .gitignore file too.

Christian

Am 10.10.19 um 22:18 schrieb Ehigie Aito:
Hello Bobby,
I think this should be added to a best practises documentation and not codified in Django. As I feel that would be overkill. 

On Thu, 10 Oct 2019, 20:41 Bobby Mozumder, <[hidden email]> wrote:
In particular, they include settings that shouldn’t be stored in a git repo such as SECRET_KEY and database passwords. You’ll find these kinds of settings in git repos all the time.

Really the default django-admin startproject shouldn’t have a single settings.py that people include in their git repos, but instead a python settings module, with a base.py, development.py, staging.py, and production.py. An __init__.py reads base.py and one of development/staging/production based on ENV variables (defaulting to development if no ENV variable).

Additionally, startproject should add a .gitignore in the root directory to not include development/staging/production settings files.

I get that this might not be absolutely necessary but I think these are the kinds of defaults that make practical real-world use more secure, as well as standardizing workflow for more advanced production usage.

Is this something agreeable? I can put together a solution if people like this.

-bobby


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/320B70FD-BDC1-445D-B72B-0CD0BA736B88%40gmail.com.
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BB1BD6kxbSR_fOwAWxY%3DtjRA30YPcYVt87%2BHguOKyZBOnHnuQ%40mail.gmail.com.
-- 
Dr. Christian González
https://nerdocs.at

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bba18cb5-d1d9-79f6-de15-d5186bab1f32%40nerdocs.at.

pEpkey.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Nick Sarbicki
I strongly disagree with this.

I've not seen a common standard between companies when it comes to settings in Django and for good reason. Different companies employ different standards and practices when it comes to configuration and security. Enforcing an arbitrary standard - such as a settings file for each env - is too opinionated for me and would often involve extra work on setup to remove this initial way of doing things.

Likewise in my experience ignoring settings files is actually quite rare. Most companies store secrets external to the settings file and prefer to keep their settings in git. Adding a .gitignore with the settings files would actually cause issues on future projects where you aren't expecting this.

As mentioned this isn't necessarily to say having multiple settings files or ignoring settings files are bad in an individual project. But that every project has its own way of handling configuration and secrets, so enforcing the standard you follow on everyone else - not because it is the best possible way of doing things, but because it is how you do things - is unlikely to be a popular move.

Adapting your settings configuration to the way you work is a small amount of work - Django does a good job at the moment of staying unopinionated on this whilst giving you what you need to get going.

On the SECRET_KEY. It is true that many people commit their SECRET_KEY into the repo. But in the same way that you often get people committing DB credentials and API keys. It is not a frameworks job to inform you of every security malpractice (although Django does a good job of this already), it is up to the developer to understand what they are doing. Despite this there is extensive documentation on the SECRET_KEY needing to be secret, mentioned both in the settings documentation and the deployment checklist. There is even a comment above this setting explicitly stating that it should be kept secret in production.

Assuming Django's startproject command aims to have a fully functioning project from the get go - which means it needs a SECRET_KEY - then I think this is a pretty good compromise as is.

- Nick


On Fri, Oct 11, 2019 at 12:14 PM Christian González <[hidden email]> wrote:

Hi, may I disagree - I set up projects very often (for testing a package), and I always feel a bit awkward because of that monolithic settings.py file.

I can really support Bobby's idea, even if development/staging/production may be a bit overkill. Having a practical standard which ensures good practice from the start is a good thing. And OTOH, it won't hurt anyone if these files are there.

As there was another discussion earlier about "declarative" settings - maybe it would be helpful to exclude some of the settings from settings.py which is code, not declaration. SECRET_KEY could be anywhere by default, it doesn't have to be in an executable .py file. But this would mean to change Django's code to read it before or after importing settings.py.

+1 for a .gitignore file too.

Christian

Am 10.10.19 um 22:18 schrieb Ehigie Aito:
Hello Bobby,
I think this should be added to a best practises documentation and not codified in Django. As I feel that would be overkill. 

On Thu, 10 Oct 2019, 20:41 Bobby Mozumder, <[hidden email]> wrote:
In particular, they include settings that shouldn’t be stored in a git repo such as SECRET_KEY and database passwords. You’ll find these kinds of settings in git repos all the time.

Really the default django-admin startproject shouldn’t have a single settings.py that people include in their git repos, but instead a python settings module, with a base.py, development.py, staging.py, and production.py. An __init__.py reads base.py and one of development/staging/production based on ENV variables (defaulting to development if no ENV variable).

Additionally, startproject should add a .gitignore in the root directory to not include development/staging/production settings files.

I get that this might not be absolutely necessary but I think these are the kinds of defaults that make practical real-world use more secure, as well as standardizing workflow for more advanced production usage.

Is this something agreeable? I can put together a solution if people like this.

-bobby


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/320B70FD-BDC1-445D-B72B-0CD0BA736B88%40gmail.com.
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BB1BD6kxbSR_fOwAWxY%3DtjRA30YPcYVt87%2BHguOKyZBOnHnuQ%40mail.gmail.com.
-- 
Dr. Christian González
https://nerdocs.at

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bba18cb5-d1d9-79f6-de15-d5186bab1f32%40nerdocs.at.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAGuvt93VFf17sStwGLyPf9tSLvuEOYjaKZZ3Y59yEU7BVvVjEQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Florian Apolloner
In reply to this post by Bobby Mozumder


On Thursday, October 10, 2019 at 9:41:53 PM UTC+2, Bobby Mozumder wrote:
Additionally, startproject should add a .gitignore in the root directory to not include development/staging/production settings files.

I am very much against creating a .gitignore as part of startproject. Also I do check my production settings file into version control because all the sensitive data comes from the environment, not from the code.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/18bf525a-0bda-4cd3-8cb5-42419cb12754%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Mariusz Felisiak
In reply to this post by Bobby Mozumder
Hi,

    I don't agree that Django should force pattern with multiple settings files (base, development, staging, and production) there is many ways to keep secrets and probably a production.py settings file is not the best one (IMO). Everything depends on a project (not all of them have such environments). You can always use your own project template if you don't like the builtin project template (see https://docs.djangoproject.com/en/2.2/ref/django-admin/#startproject). Also including `.gitignore` would be confusing, we cannot assume that all projects use the same structure.

Best,
Mariusz

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2ef775cb-1984-4634-af7f-c513e7be5964%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Ehigie Aito
This feature should be filled under a "nice to have" and not a "must have". 

On Fri, 11 Oct 2019, 12:45 Mariusz Felisiak, <[hidden email]> wrote:
Hi,

    I don't agree that Django should force pattern with multiple settings files (base, development, staging, and production) there is many ways to keep secrets and probably a production.py settings file is not the best one (IMO). Everything depends on a project (not all of them have such environments). You can always use your own project template if you don't like the builtin project template (see https://docs.djangoproject.com/en/2.2/ref/django-admin/#startproject). Also including `.gitignore` would be confusing, we cannot assume that all projects use the same structure.

Best,
Mariusz

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2ef775cb-1984-4634-af7f-c513e7be5964%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BB1BD6iuZv3c4_ajSCbBrjnvy%2BT8s7dR3%2Bb2ywR7p3DM_BzMg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Carlton Gibson-3
In reply to this post by Bobby Mozumder
I can see a How-To explaining different patterns here being a valid addition to the docs.

FWIW, there’s a PR to ease/enable SECRET_KEY rotation. It might mitigate some of the issues with first committing sensitive values to git when it lands. https://code.djangoproject.com/ticket/30360

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8B884601-477D-4B82-9FE7-34B95548F73E%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Ehigie Aito
Exactly, I believe a best practices section should be added to the already robust Django documentation. Something akin to the Two Scoops of Django book. That would be better than focusing a pattern on everyone.

On Fri, 11 Oct 2019, 13:21 Carlton Gibson, <[hidden email]> wrote:
I can see a How-To explaining different patterns here being a valid addition to the docs.

FWIW, there’s a PR to ease/enable SECRET_KEY rotation. It might mitigate some of the issues with first committing sensitive values to git when it lands. https://code.djangoproject.com/ticket/30360

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8B884601-477D-4B82-9FE7-34B95548F73E%40gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BB1BD6u3cvyewgRu8dRaVLVPuy9ws2Lht_f4eKc%2BfqTNvHjOw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Carlton Gibson-3
It's just scope:

   * Not clear we need to _replace_ the space for books, and blog posts, and so on, in the main docs. 

and bandwidth:

   * These things are difficult to get right, and it needs someone to do them. (PRs always warmly received!)

On balance, I have to say, I think the default project template does very well. 
Taking a beginner, say, and adding, "As well as the million things you're already dealing with, there are these things called environment variable and..." is a step I'd be very cautious about taking. 

Yes, granted, for professional deployment, you might want different — but we have to serve everyone. 

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c7ddc76c-5435-4e89-bab9-042d2c2e6751%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Taymon A. Beal
Is the requirement here to avoid introduce additional barriers to getting up and running in local development, or to deploying a site so that it's accessible from the public internet?

Both of these are important goals, but trading off security against the latter worries me. I don't think we're doing beginners any favors if we make it easier for them to deploy sites with security issues, especially since they won't be in a good position to appreciate the consequences. Ideally we'd make it easy for beginners to deploy sites without security issues, but that's a hard problem given the diversity of production environments; in the meantime, I think we need to accept the reality that figuring out how to store secrets *is* a prerequisite to deploying Django in production, notwithstanding how much we wish it weren't.

I'd be interested in trying to contribute a solution more secure than the status quo without introducing more barriers to local development, if it would have a chance of being accepted.

Taymon

On Friday, October 11, 2019 at 8:00:59 AM UTC-7, Carlton Gibson wrote:
It's just scope:

   * Not clear we need to _replace_ the space for books, and blog posts, and so on, in the main docs. 

and bandwidth:

   * These things are difficult to get right, and it needs someone to do them. (PRs always warmly received!)

On balance, I have to say, I think the default project template does very well. 
Taking a beginner, say, and adding, "As well as the million things you're already dealing with, there are these things called environment variable and..." is a step I'd be very cautious about taking. 

Yes, granted, for professional deployment, you might want different — but we have to serve everyone. 

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/826f3d41-8e8a-4452-8b66-b1ba5f22c06d%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Josh Smeaton
A quick idea from the top of my head, is to change the assignment of SECRET_KEY in the generated settings to something like:

SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", "insecure-<generatedvalue>")

It signals that secrets in the environment are a good idea, that the default generated value is insecure, and it still has a random part so that default sites aren't automatically hackable when deployed. There's no impact to people just getting started.

We could go a small step forward and use `check --deploy` to check for the substring `insecure` (even though I believe the KEY is technically bytes?).

Just throwing something out there.


On Monday, 21 October 2019 23:48:59 UTC+11, Taymon A. Beal wrote:
Is the requirement here to avoid introduce additional barriers to getting up and running in local development, or to deploying a site so that it's accessible from the public internet?

Both of these are important goals, but trading off security against the latter worries me. I don't think we're doing beginners any favors if we make it easier for them to deploy sites with security issues, especially since they won't be in a good position to appreciate the consequences. Ideally we'd make it easy for beginners to deploy sites without security issues, but that's a hard problem given the diversity of production environments; in the meantime, I think we need to accept the reality that figuring out how to store secrets *is* a prerequisite to deploying Django in production, notwithstanding how much we wish it weren't.

I'd be interested in trying to contribute a solution more secure than the status quo without introducing more barriers to local development, if it would have a chance of being accepted.

Taymon

On Friday, October 11, 2019 at 8:00:59 AM UTC-7, Carlton Gibson wrote:
It's just scope:

   * Not clear we need to _replace_ the space for books, and blog posts, and so on, in the main docs. 

and bandwidth:

   * These things are difficult to get right, and it needs someone to do them. (PRs always warmly received!)

On balance, I have to say, I think the default project template does very well. 
Taking a beginner, say, and adding, "As well as the million things you're already dealing with, there are these things called environment variable and..." is a step I'd be very cautious about taking. 

Yes, granted, for professional deployment, you might want different — but we have to serve everyone. 

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3443dbe6-1a6a-45af-b5ec-08cf78426869%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: django-admin startproject settings.py has some security holes

Olivier Dalang
Hi,

Just a reminder about this page in the docs: https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/
It basically already covers it all. Maybe a direct link to that page from the settings file would be good enough?

Cheers,

Olivier

On Thu, Oct 24, 2019, 04:45 Josh Smeaton <[hidden email]> wrote:
A quick idea from the top of my head, is to change the assignment of SECRET_KEY in the generated settings to something like:

SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", "insecure-<generatedvalue>")

It signals that secrets in the environment are a good idea, that the default generated value is insecure, and it still has a random part so that default sites aren't automatically hackable when deployed. There's no impact to people just getting started.

We could go a small step forward and use `check --deploy` to check for the substring `insecure` (even though I believe the KEY is technically bytes?).

Just throwing something out there.


On Monday, 21 October 2019 23:48:59 UTC+11, Taymon A. Beal wrote:
Is the requirement here to avoid introduce additional barriers to getting up and running in local development, or to deploying a site so that it's accessible from the public internet?

Both of these are important goals, but trading off security against the latter worries me. I don't think we're doing beginners any favors if we make it easier for them to deploy sites with security issues, especially since they won't be in a good position to appreciate the consequences. Ideally we'd make it easy for beginners to deploy sites without security issues, but that's a hard problem given the diversity of production environments; in the meantime, I think we need to accept the reality that figuring out how to store secrets *is* a prerequisite to deploying Django in production, notwithstanding how much we wish it weren't.

I'd be interested in trying to contribute a solution more secure than the status quo without introducing more barriers to local development, if it would have a chance of being accepted.

Taymon

On Friday, October 11, 2019 at 8:00:59 AM UTC-7, Carlton Gibson wrote:
It's just scope:

   * Not clear we need to _replace_ the space for books, and blog posts, and so on, in the main docs. 

and bandwidth:

   * These things are difficult to get right, and it needs someone to do them. (PRs always warmly received!)

On balance, I have to say, I think the default project template does very well. 
Taking a beginner, say, and adding, "As well as the million things you're already dealing with, there are these things called environment variable and..." is a step I'd be very cautious about taking. 

Yes, granted, for professional deployment, you might want different — but we have to serve everyone. 

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3443dbe6-1a6a-45af-b5ec-08cf78426869%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAExk7p0%3DzRMJi1ObZnSuKncYgXVuNT-k%3DqMj5ONVuEN_nVTEQw%40mail.gmail.com.