Perché usare .ENV? Cosa c'è di sbagliato con la memorizzazione dei segreti in un file config.php al di fuori della directory principale?

2

Sembra che in questi giorni la prassi generale sia quella di archiviare segreti (ad es., DB, credenziali API) in un file .ENV , quindi caricarlo automaticamente in $_ENV e $_SERVER . Questa libreria popolare lo fa ed è anche incoraggiato come best practice. Questa libreria fa un ulteriore passo avanti e crittografa il valore all'interno del file .ENV .

Dicono che l'intero scopo è di gestire facilmente le configurazioni di sviluppo / produzione e di ridurre al minimo i file di configurazione inviati al controllo della versione. In cima a "mai memorizzare credenziali sensibili nel codice".

Un chiaro problema a riguardo è una semplice iniezione di print_r($_SERVER) o print_r($_ENV) nel tuo codice rivelerà tutto. Oppure, se hai dimenticato di eliminare phpinfo.php , tutto è perduto! Ci sono anche altri modi in cui potrebbe perdere (ad es. Log).

Sono abbastanza sconcertato che questa pratica sia prevalente o forse mi manchi solo qualcosa.

C'è qualcosa di particolarmente sbagliato con il buon vecchio config.php archiviato al di fuori del root del documento? Voglio dire che potresti metterlo in discussione anche tu e non farà assolutamente parte del tuo codice. Puoi anche crittografarlo. Perché utilizzare .ENV ?

Aggiornamento:

Ecco un articolo che accetta i miei sentimenti

    
posta IMB 06.12.2018 - 16:42
fonte

1 risposta

0

Nessun problema inerente da una prospettiva di sicurezza

Se la tua applicazione o il suo server sono compromessi, l'autore dell'attacco sarà probabilmente in grado di leggere qualsiasi cosa nella configurazione, inclusi dati sensibili quali password, token o stringhe di connessione. Questo è vero se si usano i file di configurazione o le variabili di ambiente.

Se hai mai sospettato un compromesso, scriveresti / reimposti i tuoi segreti indipendentemente dal fatto che la tua configurazione sia archiviata in file o variabili d'ambiente.

Motivi pratici

L'articolo che hai collegato come spiegazione offre ragioni pratiche per l'utilizzo delle variabili di ambiente.

Secondo la loro raccomandazione, questo approccio riduce il rischio di: cattivi commit (in particolare, quelli contenenti dati di configurazione), distribuzioni configurate in modo errato e pratiche di sviluppo scadenti.

Nella misura in cui la loro raccomandazione impedisce comportamenti di cattiva sicurezza, è meglio seguirla. Le interruzioni della sicurezza sono dovute a errori umani durante l'implementazione / manutenzione e bug del software. Se un processo automatizzato o un'abitudine impediscono un problema, è la cosa giusta da fare.

    
risposta data 06.12.2018 - 17:21
fonte

Leggi altre domande sui tag