Quando si apre un app Rails live, è pericoloso lasciare la chiave della sessione segreta nel controllo del codice sorgente?

Question

Ho un'applicazione Rails in esecuzione dal vivo da un po 'di tempo e ho intenzione di aprirla nel prossimo futuro. Mi chiedo quanto sia pericoloso lasciare il segreto dell'archivio delle chiavi di sessione nel controllo del codice sorgente mentre l'app è in diretta.

Se è pericoloso, in che modo le persone gestiscono questo problema di solito? Direi che è più semplice spostare la stringa in un file di testo che viene ignorato dallo SCM e leggerlo in seguito.

Solo per chiarezza, sto parlando di questo:

# Your secret key for verifying cookie session data integrity. 
# If you change this key, all old sessions will become invalid! 
# Make sure the secret is at least 30 characters and all random, 
# no regular words or you'll be exposed to dictionary attacks. 
ActionController::Base.session = { 
    :key   => '_application_session', 
    :secret  => '(long, unique string)' 
} 

E già che siamo in tema, c'è qualcos'altro in un'applicazione di default Rails che dovrebbe essere protetto quando è aperto sourcing un'app dal vivo ?

Answer 1

Rifletti sulla domanda. Riusciresti a riutilizzare una chiave segreta dal progetto di qualcun altro che hai appena scaricato? Probaby no, e nemmeno altri utenti intelligenti del tuo codice. Gli utenti malintenzionati avranno quindi una chiave da utilizzare come attacco nel tuo sito principale, così come contro gli utenti abbastanza pigri da non cambiare la chiave.

Altri file di configurazione che potrebbero non essere condivisi includono database.yml, s3.yml, amazon_s3.yml, ecc. Se non lo si invia a un estraneo, non tenerlo in memoria quando scateni il tuo codice per il mondo.

Answer 2

Lo inserisco in un file di configurazione. Probabilmente avrai comunque bisogno di alcune impostazioni di configurazione, quindi perché non lo metti lì e aggiungi un commento che dovrebbe essere modificato quando l'utente installa il software.

Answer 3

Alcuni esempi di codice e alcune esperienze su come lavorare con sessioni esistenti se si sta aggiornando un'applicazione già esistente possono essere trovati sul blog di Michael Hartl Security issue with Rails secret session keys.