Come posso evitare di inserire la password del database in uno script perl?

Il metodo standard consiste nel mettere le credenziali in un file di configurazione e tentare di proteggere il file di configurazione dall'essere più leggibile rispetto al file perl. Questo offre un moderato aumento della sicurezza; per esempio, il codice potrebbe essere nel controllo del codice sorgente e accessibile agli sviluppatori, il file di configurazione non lo sarebbe. Il codice deve essere nella radice cgi del web server, ed eventualmente scaricabile in determinate configurazioni errate, e il file di configurazione non deve essere presente.

Il modo ambizioso è di crittografare in modo reversibile le credenziali e inserirle in un file di configurazione. Ovviamente, qualsiasi cosa criptata in modo reversibile può essere decifrata. L'applicazione BladeLogic ha fatto questo, ed è stato banale (< 1 giorno) per me per de-compilare il loro Java abbastanza per scoprire la funzione per decrittografare le credenziali e usarlo per decrittografarle in modo soddisfacente. Non un marchio contro di loro; è solo il nome del gioco crittografato in modo reversibile.

Un'altra opzione è quella di utilizzare l'autorizzazione basata sul sistema operativo insieme a restrizioni del database strettamente limitate. Ad esempio, limitare l'accesso dell'utente del client del database a un insieme di stored procedure per limitare il potenziale di abuso e consentire all'utente di accedere al database senza password. Questo non funziona se stai facendo client-server attraverso la rete, il che limita la frequenza con cui è utile. Inoltre, le persone tendono ad apparire più bisognose per l'accesso agli utenti del sistema operativo "senza password" di quanto non facciano scrivendo la password, volenti o nolenti. Non è del tutto logico, ma ci sono degli standard che dicono che tutti gli utenti del database devono avere password, quindi basta.

Spesso passo la password allo script in una variabile di ambiente in questo modo lo script non deve avere accesso alla posizione sicura che contiene la password.

PASSWORD='cat passwd_file'  perl_script.pl

quindi lo script legge la password

my $password = $ENV{'PASSWORD'}

punti bonus se lo script perl abbandona i privilegi

Come altri hanno già detto, inserisci le credenziali in un file separato che verrà caricato dallo script. I rischi di avere la password nello script includono la sua esposizione alla spalla, il suo essere impegnato nei sistemi di controllo di revisione o nei sistemi di gestione della configurazione e distribuito ben oltre ciò che dovrebbe essere, copiando accidentalmente in un'altra posizione quando riutilizzando parte del codice, ecc.

Il file delle credenziali dovrebbe avere le autorizzazioni minime necessarie. Probabilmente non dovrebbe essere incluso o trattato diversamente dai sistemi di gestione della configurazione.

Se disponibile, esaminare utilizzando una funzione del sistema operativo che limita l'accesso al file delle credenziali oltre alle autorizzazioni. Ad esempio, AppArmor o SELinux su Linux possono limitare l'accesso al file delle credenziali a uno script che ne ha bisogno. Questo protegge solo contro un attaccante che non può assumere il controllo dello script legittimo, quindi assicurati che lo script legittimo non sia di proprietà dell'utente che lo esegue (questo è un consiglio generale: non avere programmi eseguibili di proprietà dell'utente che li esegue ).

Il consenso sembra essere:

1. La password deve essere in un file separato, non parte del controllo di versione e protetta con autorizzazioni più restrittive di quella dello script.
2. La crittografia della password memorizzata è una perdita di tempo poiché lo script necessita essere in grado di decifrare la password comunque.

Ma sto pensando di aggiungere un terzo controllo sopra a quelli: il controllo degli accessi temporizzato (temporale) potrebbe aiutare un po 'anche qui. Limitando la quantità di tempo in cui la password in chiaro è disponibile per gli utenti con privilegi più bassi aggiungerebbe un altro (anche se piccolo) livello di controllo degli accessi tra la password e qualsiasi aggressore locale.

La mia idea è di avere il root per possedere il file della password, impostato su modalità 0400 . E poi avere un cronjob di root che fa un chmod 0404 sul file password appena prima del cronjob con privilegi inferiori che esegue lo script . A un intervallo specificato più tardi (si spera che dopo lo script sia terminato), un secondo cronjob di root esegue un chmod 0400 sul file della password. Tutto ciò presuppone che lo script abbia bisogno solo della password per qualche periodo di tempo inferiore a sempre . I tuoi pensieri su questo schema?

Mi piace mettere configurazioni in ~/config/appname e avere una configurazione generica per la mia connessione locale mysql (o qualsiasi altra). Se non vuoi dare alla tua casa un permesso X ed eseguire l'app come un utente diverso ha una cartella di configurazione standard da qualche parte. Lo faccio quindi non accetto involontariamente né fornisco password o nomi utente ad altri programmatori. Non penso che sia un grosso problema ma il mio capo è un maniaco della sicurezza ed è una buona abitudine soprattutto quando pubblica qualcosa sul web.

Sarebbe saggio scrivere un oneliner o twoliner standard per i tuoi file di configurazione e copiarli / incollarli in qualsiasi nuovo script che scrivi

Questo è ciò che sto pianificando per uno script che si connette a un database remoto. Richiede 2 server per memorizzare la chiave separatamente dal valore crittografato.

1. Sul server 2 (dove verrà memorizzata la chiave), crea uno script che accetterà un parametro chiave e lo memorizzerà localmente.
2. Sul server 1 (in cui è archiviato lo script), creare uno script che accetti la stringa di connessione (host, nome_db, nome utente, password) come parametro e generi una chiave casuale per crittografare la stringa di connessione. Archiviamo localmente la stringa crittografata, cancelliamo la chiave e la memorizziamo localmente, quindi inviamo la chiave (su SSL) al server 2. Questo script dovrà essere eseguito manualmente con la stringa di connessione effettiva per inizializzarlo e può essere rieseguito su resettare la chiave se il secondo server viene in qualche modo compromesso.
3. Sul server 1 Configura lo script originale per accettare un parametro chiave, convalidare la chiave con l'hash memorizzato, quindi utilizzare la chiave per decrittografare la stringa di connessione crittografata.
4. Sul server 2 Configura una chiamata cURL allo script sul Server 1 (su SSL) che invia la chiave ed esegue lo script. Questo può essere impostato su cron o comunque vuoi che venga eseguito.

Questa sarebbe una soluzione appropriata:

1. La password è memorizzata in un programma C / C ++ compilato che viene offuscato in questo modo: password char [100]; password [0] = 'a'; password [1] = 'b'; password [2] = 'c'; password [3] = '\ 0';

O qualche altro modo di offuscare la password. (la password non dovrebbe essere disponibile eseguendo "stringhe" nell'eseguibile)

2. Il programma C / C ++ restituisce la password solo agli script affidabili e registrati: A. Ottieni ppid e controlla / proc // cmdline, / proc // comm, ecc. B. Ottieni l'inode dello script del chiamante e confrontalo con l'identità registrata, per assicurarti che lo script non sia stato modificato.