Sicurezza di Django SECRET_KEY, in che modo i metodi sono più sicuri

Question

Sicurezza di Django SECRET_KEY, in che modo i metodi sono più sicuri

#1 da (18 voti)

21

Mi avvicino a un punto in cui distribuirò la mia applicazione Django all'ambiente ostile altrimenti noto come "Internet" e sto cercando di capire meglio le ramificazioni del Django SECRET_KEY . Una delle procedure standard che sembra è quella di proteggere la chiave segreta in settings.py . Giusto. I documenti vanno così lontano da dire di non impegnare la tua chiave segreta in SVN, CVS, ecc ... Per questo fornisce un facile accesso alla tua chiave. Tuttavia, se qualcuno fosse tentato di eseguire il commit della chiave segreta, ciò indicherebbe che la chiave segreta è statica (vedi domanda n. 4)?

Ad ogni modo, ecco le mie domande:

In che modo la memorizzazione della chiave segreta come variabile d'ambiente è più sicura rispetto all'archiviazione diretta in settings.py ? Ad esempio, se un utente malintenzionato può leggere settings.py , è più che probabile che digiti $ echo $DJANGO_SECRET_KEY !
In che modo la memorizzazione della chiave segreta in un file è più sicura rispetto alla memorizzazione diretta in settings.py ? Se può leggere settings.py , probabilmente può leggere django_secret_key.txt .
Se l'utente malintenzionato ha compromesso la tua macchina, non può semplicemente caricare l'interprete python con settings.py in > print settings.SECRET_KEY ?
Infine, sarebbe una cattiva pratica generare in modo casuale la chiave segreta ogni volta che viene riavviato il processo del server web? Questo potrebbe essere completamente casuale, o potrebbe richiedere l'input dell'utente per la chiave. Ovviamente, quest'ultimo presenta una grave debolezza se l'autore dell'attacco può riavviare il webservice e inserire la chiave di sua scelta.

python django

posta James 26.06.2014 - 08:42

fonte

1 risposta

Leggi altre domande sui tag python django

Quanti nomi host possono essere supportati da un certificato ssl con caratteri jolly? C'è qualche limite? La rimozione di spazi in una stringa protegge dall'iniezione SQL?

score 18 · Accepted Answer

Una volta che un utente malintenzionato ha già accesso al sistema, è già troppo tardi. La preoccupazione principale per non perdere la chiave è perché viene spesso utilizzata come seme per le sessioni di hashing e di firma. L'idea è che la tua produzione SECRET_KEY debba essere completamente diversa rispetto allo sviluppo o alla messa in scena SECRET_KEY . È possibile generarlo in modo casuale ogni riavvio, anche se ciò potrebbe influire sull'esperienza utente (vedere i dettagli di seguito).

Fintanto che rispetti il principio di cambiare la chiave, non ci sono molti pericoli se ti impegni o meno (a patto che ti assicuri che venga cambiato una volta passato da dev a prod). In caso contrario, chi ha la chiave può prevedere l'esito degli algoritmi di hashing (utilizzati per le sessioni) o persino firmare le sessioni.

Se un utente malintenzionato ha ottenuto l'accesso al tuo sistema, sei già troppo lontano perché non è più il tuo sistema. Una cosa che devi assicurarti è che le autorizzazioni del file sul tuo file di impostazioni siano leggibili solo dall'utente che esegue il server web e da nessun altro. Questo impedisce a qualcuno che illegittimamente ha avuto accesso a un account limitato, che non è lo stesso dell'account del server web, di compromettere la tua chiave.

Qui c'è una buona risposta su Stack Overflow: Django SECRET_KEY scritto da sberder che specifica a cosa serve:

JSON object signing

crypto functions for salted hmacs or seeding the random engine which impacts:

password reset token

comment form security to protect against forged POST requests

form security

protect against message tampering as the message framework may use cookies to pass messages between views.

protect session data and create random session keys to avoid tampering as well.

create random salt for most password hashers

create random passwords if necessary

create itself when using startproject

create CSRF key

In reality a lot of the items listed here use SECRET_KEY through django.utils.crypt.get_random_string() which uses it to seed the random engine. This won't be impacted by a change in value of SECRET_KEY.

User experience directly impacted by a change of value are:

sessions, the data decode will break, that is valid for any session backend (cookies, database, file based or cache).

password reset token already sent won't work, users will have to ask a new one.

comments form (if using django.contrib.comments) will not validate if it was requested before the value change and submitted after the value change. I think this is very minor but might be confusing for the user.

messages (from django.contrib.messages) won't validate server-side in the same timing conditions as for comments form.