NOOB exposes CSRF token. Now what?

[Gordon Reeder]

I'm learning Django and still very new at it. And like a newbie, I may have made a newbie goof.
I have leaked my CSRF token.
I am building up a web site with Django which I have under revision control with Git. I have pushed two commits of the project out to Github. The commits included the settings.py file, which list the CSRF token. I have read (after the fact) that maybe that wasn't the smartest thing to do.

So now what?

Can I remove the settings.py file from Github?
Or can I generate a new CSRF token?

Any suggestions?

[Gergely Polonkai]

Hello,

you may force-push a new commit that removes the settings file from the GitHub repo, but if you are really paranoid, you may want to change your CSRF token in production immediately. It may cause some temporary annoyance to your users, but nothing long-term.

Best,

Gergely

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/9faaf7ad-29af-473d-8e63-e1c51b4b90d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Evans]

CSRF tokens are generated on the fly, they aren't stored in your settings.py.

However, what is stored in settings is your SECRET_KEY. If you have
leaked it, you should change it immediately. This will invalidate
sessions, signed cookies, password reset tokens, some forms (if loaded
before you change it, and submitted after).

Take the pain now.

Cheers

Tom

[Tom Evans]

On Fri, Sep 25, 2015 at 12:01 PM, Tom Evans <teva...@googlemail.com> wrote:
> However, what is stored in settings is your SECRET_KEY. If you have

> leaked it, you should change it immediately. This will invalidate..

Helpfully, the django documentation for SECRET_KEY details precisely
what cycling it will invalidate, so you don't need to trust my
un-detailed list:

https://docs.djangoproject.com/en/1.8/ref/settings/#secret-key

Cheers

Tom

[Mike Dewhirst]

Gordon

As others have said, you need to keep such stuff out of your repo.

For that I wrote a little file parser called getcreds.py (see below) to
read plain text files and retrieve the necessary info for settings.

eg., from my settings.py ...

# keep all credentials in separate fname files in credsdir
from .getcreds import getcreds
email_creds = getcreds('smtp.host', PROJECT)
EMAIL_HOST = email_creds[0]
EMAIL_PORT = email_creds[1]
EMAIL_HOST_USER = email_creds[2]
EMAIL_HOST_PASSWORD = email_creds[3]

SECRET_KEY = getcreds('django.secret', PROJECT)[0]

dbhost = getcreds('db.host', PROJECT)
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': PROJECT,
'USER': dbhost[0],
'PASSWORD': dbhost[1],
'HOST': dbhost[2],
'PORT': dbhost[3],
}
}

This is off-list because it isn't widely used. I don't wish to pollute
the wider nob community with such heresy. It works nicely for me but
best-practice (I'm told) is to store such things in environment vars and
get them from there when required. I'd drop my approach and do that if I
had time.

Cheers

Mike

<below>
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
# this is the only django import permitted in settings files
from django.core.exceptions import ImproperlyConfigured


def getcreds(fname, project, credsroot='/var/www/creds'):
""" return a list of userid and password and perhaps other data """
credsdir = '%s/%s' % (credsroot, project)
creds = []
fname = '%s/%s' % (credsdir, fname)
with open(fname, 'r') as f:
for line in f:
creds.append(line.strip())
if not creds:
raise ImproperlyConfigured('Missing setting: %s' % fname)
return creds

> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com

> <mailto:django-users...@googlegroups.com>.

> To post to this group, send email to django...@googlegroups.com

> <mailto:django...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/9faaf7ad-29af-473d-8e63-e1c51b4b90d0%40googlegroups.com

> <https://groups.google.com/d/msgid/django-users/9faaf7ad-29af-473d-8e63-e1c51b4b90d0%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Gordon Reeder]

OK, thanks everyone for the replies. It looks like I'll have to regenerate the secret_key (not token). Thankfully, I have not actually deployed the site yet. So the pain should be minimal and limited to just me.