Español
Română
РусскийSpostare wp-config fuori dalla root web è davvero vantaggioso?
Una delle best practice di sicurezza più comuni al giorno d'oggi sembra essere spostare wp-config.php una directory più in alto rispetto alla document root del vhost. Non ho mai trovato una buona spiegazione per questo, ma presumo sia per minimizzare il rischio che uno script malevolo o infetto all'interno della webroot possa leggere la password del database.
Tuttavia, devi comunque permettere a WordPress di accedervi, quindi devi espandere open_basedir per includere la directory sopra la document root. Questo non vanifica l'intero scopo e potenzialmente espone i log del server, i backup, ecc. agli attaccanti?
Oppure la tecnica cerca solo di prevenire una situazione in cui wp-config.php verrebbe mostrato come testo normale a chiunque richieda http://example.com/wp-config.php, invece di essere interpretato dal motore PHP? Questo sembra un caso molto raro e non compenserebbe gli svantaggi dell'esporre log/backup/ecc alle richieste HTTP.
Forse è possibile spostarlo fuori dalla document root in alcune configurazioni di hosting senza esporre altri file, ma non in altre configurazioni?
Conclusione: Dopo molte discussioni su questo argomento, sono emerse due risposte che ritengo debbano essere considerate quelle autorevoli. Aaron Adams presenta una buona argomentazione a favore dello spostamento di wp-config, e chrisguitarguy presenta una buona argomentazione contro. Queste sono le due risposte che dovresti leggere se sei nuovo alla discussione e non vuoi leggere l'intero thread. Le altre risposte sono ridondanti o imprecise.
Se hai un bug in Apache, Linux o nel cervello dell'amministratore, sei fritto in ogni caso. Nel tuo scenario non spieghi perché è più probabile che una configurazione errata avvenga alla radice del sito web rispetto a qualsiasi altro posto sul server. Un Apache configurato male può probabilmente accedere a /../config.php tanto facilmente quanto a /config.php
Mark Kaplun
Non sei "fritto in ogni caso." È molto probabile, e persino dimostrabile, che un bug possa ripristinare la root web al suo valore predefinito, nel qual caso non sei "fritto" – il tuo wp-config.php rimane al sicuro. Ed è estremamente improbabile – così tanto da essere praticamente impossibile – che un bug ripristini arbitrariamente la root web esattamente alla directory in cui hai posizionato il tuo wp-config.php.
Aaron Adams
Quanto è probabile questo tipo di bug? Non sono un esperto di sicurezza, ma non ho mai sentito parlare di questo vettore di attacco utilizzato nella pratica. Sono contrario a raccomandare questo metodo perché una volta che devi mantenere il tuo sito, non sai dove si trova il tuo wp-config e probabilmente invaliderebbe la maggior parte dei tutorial che toccano quel file in qualche modo. Tu, io e il resto dei commentatori qui capiremmo cosa è successo, ma per le persone meno esperte sarebbe un grande e lungo momento di WTF.
Mark Kaplun
@MarkKaplun "Le persone che non leggono Stack Exchange potrebbero confondersi" è un argomento piuttosto debole contro una pratica di sicurezza consigliata su Stack Exchange. Quando più persone comprendono i reali pericoli di lasciare file di configurazione sensibili all'interno della root web, più persone sposteranno quei file fuori dalla root web, e più tutorial su WordPress verranno scritti per aiutare l'utente a individuare wp-config.php. Se pensi che la convenienza sia più importante della sicurezza, questa è la tua opinione; allora, però, rendi chiaro che stai consigliando agli utenti di dare priorità alla convenienza rispetto alla sicurezza.
Aaron Adams
Ciao Aaron, grazie per la risposta riflessiva e dettagliata. Hai ragione sul fatto che cambiare semplicemente la password dopo un'intrusione non sia sufficiente. Tuttavia, non sono ancora convinto dalla tua aneddoto su Plesk. È sicuramente un problema, ma non credo che spostare wp-config sia la soluzione appropriata a quel problema. Lo stesso vale per il ripristino della configurazione del vhost, ecc. Se la tua applicazione ha bisogno di abbastanza sicurezza da preoccuparti di quel tipo di vulnerabilità, allora devi affrontarle in modo più diretto. Ad esempio, non usare Plesk, perché sarà sempre vulnerabile; assicurati che la configurazione del vhost sia sicura di default...
Ian Dunn
Sì, è più o meno quello che pensavo. Sono contento di sapere di non essere l'unico :) Vorrei lasciare la domanda aperta per un altro giorno o due nel caso qualcuno abbia un contro-argomento convincente, ma finora questa mi sembra la risposta corretta.
Ian Dunn
Piccola correzione: non c'è alcun vantaggio in termini di sicurezza nello spostare il file wp-config.php fuori dalla root del documento. Ci sono altri vantaggi, che non sono legati alla sicurezza, e che si applicano solo a configurazioni insolite.
Otto
Ottimo punto. Modificato.
chrisguitarguy
Solo per sfatare un possibile mito - non è possibile che qualcosa vada storto lato server - nel qual caso il codice php viene stampato sullo schermo?
Stephen Harris
Certo. Se mod_php non funzionasse o i file PHP non venissero passati all'interprete PHP, è possibile. Se stai utilizzando una configurazione FCGI, la stessa cosa è possibile se i file PHP non vengono passati al processo fcgi per l'interpretazione. Entrambi i casi indicano problemi piuttosto gravi che però è improbabile si verifichino.
chrisguitarguy
Max ha la risposta. +1 per lui. Sto solo cercando di estenderla.
its_me
Aahan Krish, hai centrato il bersaglio. Grazie per l'aggiunta.
Max Yudin
Quindi, se usi htaccess per negare le richieste HTTP a wp-config.php, non ottieni lo stesso risultato che spostandolo fuori dalla root del documento, ma senza esporre log/backup/ecc.?
Ian Dunn
@IanDunn Dipende da quale sia la document root— (1) Se WordPress è ospitato in una directory all'interno di public_html, spostare wp-config.php al di fuori della directory significa che si troverà nella directory public_html. In questo caso, dovrai utilizzare le regole htaccess per negare le richieste HTTP a wp-config.php. (2) Se WordPress è installato direttamente sotto la directory public_html, un livello sopra => sposterai il file nella directory /home/user. In questo caso sei abbastanza al sicuro poiché il file è al di fuori della document root. Puoi comunque impostare i permessi del file a 600 (o anche più restrittivi come 440 o 400).
its_me
@IanDunn Come ho detto, questa è la mia comprensione di base, e non sono un esperto di sicurezza. :)
its_me
Ragazzi, grazie per aver condiviso le vostre opinioni. Penso che abbiamo già toccato la maggior parte di questi punti nelle altre risposte e nei relativi commenti. 1) Sì, è possibile, ma raro; 2) Sì, ci sono vantaggi, ma sono minimi; 3) Sì, è possibile, ma quel tipo di vulnerabilità è improbabile che si ripeta, e proteggersi da essa è un po' come giocare a "whac-a-mole", o far togliere le scarpe alle persone in aeroporto perché qualche idiota ha nascosto una bomba nella scarpa una volta. È una reazione eccessiva ed è improbabile che porti benefici futuri.
Ian Dunn
Nelle varie discussioni, la domanda è stata affinata da "Ci sono dei vantaggi?" a "Ok, ci sono alcuni vantaggi, ma superano i rischi?" Il rischio principale a cui mi riferisco è il fatto che devi espandere l'ambito di openbase_dir per consentire a PHP di accedere agli script al di fuori della root web. Molte configurazioni di hosting - comprese quelle che utilizzano Plesk, che sono molte - memorizzano log, backup, aree FTP private che dovrebbero essere isolate dalla root web, ecc. nella directory sopra la root web. Quindi, concedere a PHP l'accesso a quella directory può rappresentare una grave vulnerabilità.
Ian Dunn
@IanDunn da quando la rarità di un evento è un argomento valido contro l'adozione di una misura di sicurezza preventiva che affronta un evento così improbabile? Il tuo punto su dove PHP può aprire file può oggi essere affrontato tramite l'hardening di systemd, tra l'altro. Il punto centrale della sicurezza informatica è che gli aggressori hanno a disposizione infinite vie di intrusione, mentre i difensori possono solo difendersi da vettori di attacco noti. Quindi è consuetudine combinare quante più misure preventive possibili per fornire una rete di sicurezza, piuttosto che affidarsi a un singolo nodo.
0xC0000022L
Se un attaccante ha accesso sufficiente per modificare il gestore PHP, sei già nei guai. Nella mia esperienza, i cambiamenti accidentali sono molto rari, e in quel caso sarebbe facile cambiare la password. Alla luce di queste considerazioni, pensi ancora che valga la pena rischiare di esporre log/backup/ecc. a causa dell'ambito ampliato di open_basedir?
Ian Dunn
Non ho mai avuto accesso -rwx alle directory superiori a public_html, quindi non ho mai avuto familiarità con open_basedir. I miei log si trovano in una directory separata, così come i backup. Penso che sia così su tutti gli hosting condivisi.
Max Yudin
Gli host variano moltissimo; non esiste una struttura di directory standard. Plesk (uno dei pannelli di controllo più popolari per gli hosting condivisi) posiziona i log in /var/www/vhosts/example.com/statistics/logs e la root del documento è /var/www/vhosts/example.com/httpdocs. Spostare wp-config.php in /var/www/vhosts/example.com/wp-config.php richiederebbe di dare agli script l'accesso all'intera directory example.com.
Ian Dunn
Solo per curiosità, dove sono memorizzati i tuoi log e backup, se non nella directory del dominio? Vi si accede tramite un pannello di controllo o qualcosa del genere?
Ian Dunn
Sì, tramite un pannello di controllo.
Max Yudin
Ciao Michael, grazie per aver condiviso questo. Hai provato a testarlo in un ambiente reale per verificare che funzioni? Penso che la direttiva open_basedir accetti un intero albero, quindi per accedere a /root/secure da /root/html, dovresti impostare open_basedir su /root.
Ian Dunn
Per far funzionare la tua idea, penso che dovresti configurare la struttura delle directory come /root/httpdocs/config/accessible, dove httpdocs contiene log, backup, ecc.; config contiene wp-config.php, e accessible contiene WordPress e tutto il contenuto. Dovresti modificare la configurazione del vhost, ecc. per rimappare la root del documento su accessible. Tuttavia, non vedo alcun vantaggio rispetto al semplice negare le richieste HTTP a wp-config nella configurazione predefinita.
Ian Dunn
Secondo http://www.php.net/manual/en/ini.core.php#ini.open-basedir: "Su Windows, separa le directory con un punto e virgola. Su tutti gli altri sistemi, separa le directory con i due punti. Come modulo Apache, i percorsi open_basedir dalle directory padre vengono ora ereditati automaticamente." Quindi puoi impostare più directory, non è necessario che siano in un singolo albero.
Michael
Ho appena testato e sembra che tu abbia ragione. Tuttavia, non sono ancora sicuro di quale vantaggio in termini di sicurezza questo abbia rispetto al semplice negare l'accesso al file tramite Apache.
Ian Dunn
@IanDunn ha risposto bene nella risposta di Aaron Adams
AndrewC
Questa risposta non affronta direttamente la domanda. Qualsiasi autore di plugin può divertirsi con WordPress se riesce a convincerti a installare il suo codice con intenti malevoli. Non è diverso dall'installare volontariamente un virus sul tuo sistema. Questo argomento per non spostare wp-config.php è inutile. È come dire che installare volontariamente una bomba nell'auto rende inutile l'allarme. Tecnicamente vero, ma WTF?!?
Lance Cleveland
No, non è inutile. La domanda è: Posso proteggere l'account del database nascondendo wp-config.php? E la risposta è chiaramente: No. È come chiedere "Posso proteggere la mia auto dalle bombe con un allarme?" Non c'è altro vantaggio nel nascondere wp-config in termini di protezione dell'accesso al database o FTP. Entrambi sono nell'ambito globale. Sono sicuro che ci sono molti altri modi per gli attaccanti di accedere alle variabili globali senza iniettare codice.
Ralf912
Non vedo "posso proteggere l'account del database nascondendo wp-config.php" nella domanda originale. La domanda originale era "ha senso spostare wp-config.php?". La risposta è assolutamente sì, IMO. È come chiedere se dovresti chiudere a chiave la porta di casa quando esci. Dire "qualcuno può facilmente rompere una finestra e entrare comunque, quindi perché preoccuparsi" non risponde al punto fondamentale della domanda. IMO la domanda era questa: "Vale la pena lo sforzo extra per spostare wp-config.php? C'è QUALSIASI vantaggio nel farlo?". Sì. Almeno tiene lontani gli hacker pigri.
Lance Cleveland
Una delle migliori pratiche di sicurezza più comuni... Hai trascurato un punto molto (molto, molto) importante: a cosa è interessato un attaccante? E non è come hai stilizzato il tuo wp-config.php. Un attaccante è interessato ai valori che hai definito nel wp-config. Prendendo il tuo esempio con la porta d'ingresso: Nascondere il tuo wp-config è come se chiudessi a chiave la porta di casa, ma lasciassi tutto il tuo oro incustodito in giardino. Tutti i valori definiti nel wp-config sono definiti globalmente. Quindi sono tutti accessibili al di fuori del wp-config. Anche se nascondi il wp-config, i valori sono comunque presenti.
Ralf912
Penso che coloro che sostengono di spostarlo stiano cercando di proteggersi da scenari in cui wp-config.php potrebbe essere visualizzato in testo semplice tramite una richiesta HTTP, piuttosto che da scenari in cui potrebbe essere esposto ad altro codice PHP in esecuzione sull'host.
Ian Dunn
È in realtà una cosa molto positiva aggiungere una risposta a una vecchia domanda, c'è persino un badge per questo. WPSE è pensato per essere un repository di conoscenza, piuttosto che un forum.
Ian Dunn
Lo ha configurato nella root del documento, non al di fuori di essa, quindi non è rilevante per questa domanda. La tecnica di cui si chiedeva nella domanda specifica di spostare wp-config.php una directory sopra la root del documento del vhost, non solo una directory sopra la cartella di installazione di WordPress. L'intero punto è di posizionarlo al di fuori della cartella che può essere letta dalle richieste HTTP.
Ian Dunn