È stato suggerito in protezione di un articolo PHP che utilizza la direttiva come sotto in htaccess è più sicuro rispetto a quello nella tua app:
<VirtualHost ilia.ws>
Include /home/ilia/sql.cnf
</VirtualHost>
quindi dichiarare i parametri in sql.cnf come di seguito:
SetEnv DB_LOGIN “login”
SetEnv DB_PASSWD “password”
SetEnv DB_DB “my_database”
SetEnv DB_HOST “127.0.0.1”
E finalmente accedili tramite:
echo $_SERVER[‘DB_LOGIN’]; // login
echo getenv(“DB_LOGIN”); // login
Questo è un approccio ragionevole. Il vantaggio di questo approccio è che evita di memorizzare la tua password nel codice sorgente. Questa è una buona cosa: non devi inserire le password nel codice sorgente .
(Naturalmente, con questo suggerimento, la password del database non è memorizzata nel file .htaccess , ma è memorizzata in un file di configurazione separato, ma la differenza è irrilevante.)
Importante: assicurati che sql.cnf non sia memorizzato nella tua web root. Se è memorizzato nella tua web root, forse chiunque conosca il percorso giusto sarà in grado di richiederlo semplicemente inviando una richiesta GET.
sql.cnf all'interno della tua webroot, che è un po 'oscuro ma può essere facilmente evitato posizionando il file all'esterno della tua web root. Considera che se stai modificando sql.cnf usando un editor di testo e la tua connessione cade mentre la stai modificando, il tuo editor salverà automaticamente una copia del file sql.cnf in qualche file di backup: ad es. sql.cnf~ (nel stessa directory). Ora il file di backup ha un'estensione diversa, quindi se qualcuno cerca di recuperare quel file, il server Apache servirà felicemente una copia del file in chiaro, rivelando la password del database. Vedi l'1% dei siti con CMS espone le loro password del database per i dettagli. Per ulteriori informazioni sul principio generale:
La raccomandazione si basa sul fatto che i file PHP saranno leggibili a livello mondiale ma i file .htaccess / httpd.conf non lo faranno. L'autore sottolinea giustamente che l'uso della crittografia per nascondere questi valori non aiuta - poiché ciò significa che la chiave di crittografia deve essere accessibile al codice PHP. Ma la memorizzazione dei valori nell'ambiente evita solo alcuni problemi che sono anche evitabili con altri mezzi. I valori in un file httpd.conf saranno leggibili da qualsiasi codice PHP eseguito sul server. Spostandoli in un defn vhost restringe la visibilità. Puoi mantenerli come codice PHP all'interno della root del documento semplicemente anteponendo il nome del file con '.ht'.
Certamente è buona prassi mantenere i token in modo indipendente dalla maggior parte del codice. Poiché
Tuttavia, l'utilizzo della configurazione del server web è solo un modo per ottenere questo risultato: esistono altri approcci validi.
Indipendentemente dal percorso che intraprendi, la sicurezza della soluzione deriverà dal considerare tutti gli aspetti: permessi sui file / accessibilità del file, restrizioni sulla connessione DB, controlli di accesso nel DB
Ci sono alcuni avvertimenti con questo, il primo si spera che il percorso: /home/ilia/sql.cnf non si trovi all'interno del webroot del tuo sito web, o un utente malintenzionato potrebbe semplicemente visitare l'URL link per visualizzare le credenziali del tuo database.
Inoltre, si spera che il tuo sito web non includa vari bug di divulgazione delle informazioni o una pagina phpinfo poiché phpinfo scaricherà l'array $ _SERVER e quindi rivelerà le credenziali del tuo database a qualsiasi visitatore di questa pagina.
Inoltre, l'ipotesi che sarebbe più difficile per un utente malintenzionato ottenere le informazioni se è memorizzata in un file PHP rispetto alle variabili di ambiente è spazzatura. Il tuo esempio imposta le variabili d'ambiente per ogni richiesta di pagina. Ciò significa che un attacco directory trasversale che potrebbe non avere le autorizzazioni per leggere il tuo file sql.conf avrà comunque il permesso di leggere / prof / self / environ e ottenere le credenziali in questo modo.
Garantire che il server del database sia associato all'interfaccia di loopback, che le credenziali del database dispongano dei privilegi più bassi possibili e che l'applicazione Web e il software del server siano tempestivamente corretti e archiviare le credenziali nel file php.