Una delle migliori pratiche di sicurezza più comuni in questi giorni sembra spostare wp-config.phpuna directory più in alto rispetto alla radice del documento del vhost . Non ho mai trovato una buona spiegazione per questo, ma suppongo che sia per minimizzare il rischio di uno script dannoso o infetto all'interno della webroot dalla lettura della password del database.

Tuttavia, devi ancora consentire a WordPress di accedervi, quindi devi espanderlo open_basedirper includere la directory sopra la radice del documento. Questo non vanifica solo l'intero scopo e potenzialmente espone registri, backup, ecc. Del server agli aggressori?

Oppure la tecnica sta solo cercando di prevenire una situazione in cui wp-config.phpverrebbe mostrato come testo in chiaro a chiunque lo richieda http://example.com/wp-config.php, invece di essere analizzato dal motore PHP? Sembra un evento molto raro e non supererebbe gli aspetti negativi dell'esposizione di registri / backup / ecc. Alle richieste HTTP.

Forse è possibile spostarlo al di fuori della radice del documento in alcune configurazioni di hosting senza esporre altri file, ma non in altre configurazioni?

Conclusione: dopo molto avanti e indietro su questo tema, sono emerse due risposte che ritengo debbano essere considerate quelle autorevoli. Aaron Adams fa un buon caso a favore di spostare wp-config, e chrisguitarguy fa un buon caso contro di esso . Queste sono le due risposte che dovresti leggere se sei nuovo nella discussione e non vuoi leggere l'intera cosa. Le altre risposte sono ridondanti o inaccurate.

Risposta breve: si

La risposta a questa domanda è un sì inequivocabile , e dire il contrario è completamente irresponsabile .

Risposta lunga: un esempio del mondo reale

Consentitemi di fornire un esempio molto reale, dal mio server molto reale, in cui lo spostamento wp-config.phpall'esterno della radice Web ha impedito in modo specifico l'acquisizione dei suoi contenuti .

Il bug:

Dai un'occhiata a questa descrizione di un bug in Plesk (risolto in 11.0.9 MU # 27):

Plesk reimposta l'inoltro del sottodominio dopo aver sincronizzato l'abbonamento con il piano di hosting (117199)

Sembra innocuo, vero?

Bene, ecco cosa ho fatto per attivare questo bug:

1. Configurare un sottodominio per reindirizzare a un altro URL (ad esempio, site.staging.server.coma site-staging.ssl.server.com).
2. Modificato il piano di servizio dell'abbonamento (ad es. La sua configurazione PHP).

Quando l'ho fatto, Plesk ha ripristinato le impostazioni predefinite del sottodominio: pubblicazione dei contenuti di ~/httpdocs/, senza interpreti (ad esempio PHP) attivi.

E non me ne sono accorto. Per settimane.

Il risultato:

• Con wp-config.phpnel web root, una richiesta /wp-config.phpavrebbe scaricato il file di configurazione di WordPress.
• Con l' wp-config.phpesterno del Web root, una richiesta per /wp-config.phpscaricare un file completamente innocuo. wp-config.phpImpossibile scaricare il file reale .

Pertanto, è ovvio che spostarsi wp-config.phpal di fuori della radice del Web ha benefici di sicurezza in buona fede nel mondo reale .

Come spostarsi wp-config.phpin qualsiasi posizione sul server

WordPress cercherà automaticamente una directory sopra l'installazione di WordPress per il tuo wp-config.phpfile, quindi se è lì che lo hai spostato, il gioco è fatto!

E se lo avessi spostato da qualche altra parte? Facile. Creane uno nuovo wp-config.phpnella directory di WordPress con il seguente codice:

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

(Assicurati di cambiare il percorso sopra nel percorso effettivo del tuo wp-config.phpfile trasferito .)

Se riscontri un problema con open_basedir, aggiungi il nuovo percorso alla open_basedirdirettiva nella configurazione di PHP:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

Questo è tutto!

Separando le argomentazioni contrarie

Ogni argomento contro lo spostamento wp-config.phpall'esterno della radice del web dipende da false assunzioni.

Argomento 1: Se PHP è disabilitato, sono già presenti

L'unico modo in cui qualcuno vedrà che il contenuto di [ wp-config.php] è se eludono l'interprete PHP dei tuoi server ... Se ciò accade, sei già nei guai: hanno accesso diretto al tuo server.

FALSO : Lo scenario che descrivo sopra è il risultato di un'errata configurazione, non di un'intrusione.

Argomento 2: la disabilitazione accidentale di PHP è rara e quindi insignificante

Se un attaccante ha abbastanza accesso per cambiare il gestore PHP, sei già fregato. I cambiamenti accidentali sono molto rari nella mia esperienza e in tal caso sarebbe facile cambiare la password.

FALSO : Lo scenario che descrivo sopra è il risultato di un bug in un comune software del server, che influenza una configurazione comune del server. Questo non è certo "raro" (e inoltre sicurezza significa preoccuparsi del raro scenario).

WTF : la modifica della password dopo un'intrusione non aiuta molto se sono state raccolte informazioni sensibili durante l'intrusione. Davvero, pensiamo ancora che WordPress sia utilizzato solo per i blog casuali e che gli aggressori siano interessati solo alla defacement? Preoccupiamoci di proteggere il nostro server, non solo di ripristinarlo dopo che qualcuno è entrato.

Argomento 3: Negare l'accesso a wp-config.phpè abbastanza buono

È possibile limitare l'accesso al file tramite la configurazione dell'host virtuale o .htaccess- limitare efficacemente l'accesso esterno al file nello stesso modo in cui si sposterebbe all'esterno della radice del documento.

FALSO : Immagina che i valori predefiniti del tuo server per un host virtuale siano: no PHP, no .htaccess, allow from all(quasi insolito in un ambiente di produzione). Se la tua configurazione viene in qualche modo ripristinata durante un'operazione di routine - come, diciamo, un aggiornamento del pannello - tutto tornerà al suo stato predefinito e sarai esposto.

Se il modello di sicurezza ha esito negativo quando le impostazioni vengono ripristinate accidentalmente ai valori predefiniti, è necessaria maggiore sicurezza.

WTF : Perché qualcuno dovrebbe specificamente raccomandare meno livelli di sicurezza? Le auto costose non hanno solo le serrature; hanno anche allarmi, immobilizzatori e localizzatori GPS. Se qualcosa vale la pena proteggere, fallo bene.

Argomento 4: L'accesso non autorizzato a wp-config.phpnon è un grosso problema

Le informazioni sul database sono davvero le uniche cose sensibili in [ wp-config.php].

FALSO : le chiavi e i sali di autenticazione possono essere utilizzati in qualsiasi numero di potenziali attacchi di dirottamento.

WTF : Anche se le credenziali del database fossero l'unica cosa wp-config.php, dovresti essere terrorizzato dal fatto che un attaccante ci metta le mani sopra.

Argomento 5: spostarsi wp-config.phpall'esterno della radice Web rende in realtà un server meno sicuro

Devi ancora consentire l'accesso a WordPress [ wp-config.php], quindi devi espanderlo open_basedirper includere la directory sopra la radice del documento.

FALSO : Supponendo che wp-config.phpsia attivo httpdocs/, basta spostarlo su ../phpdocs/e impostare open_basedirper includere solo httpdocs/e phpdocs/. Per esempio:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

(Ricordati di includere sempre /tmp/, o la tua tmp/directory utente , se ne hai una.)

Conclusione: i file di configurazione devono sempre trovarsi sempre all'esterno della radice Web

Se ti interessa la sicurezza, ti sposterai wp-config.phpal di fuori della tua radice web.

La cosa più grande è che wp-config.phpcontiene alcune informazioni sensibili: nome utente / password del database, ecc.

Quindi l'idea: spostalo fuori dalla radice del documento e non devi preoccuparti di nulla. Un utente malintenzionato non potrà mai accedere a quel file da una fonte esterna.

Ecco il problema, tuttavia: in wp-config.phprealtà non stampa nulla sullo schermo. Definisce solo varie costanti utilizzate durante l'installazione di WP. Quindi l'unico modo in cui qualcuno vedrà che il contenuto di quel file è se elude l'interprete PHP del tuo server - ottiene il .phpfile da renderizzare come un semplice testo. Se ciò accade, sei già nei guai: hanno accesso diretto al tuo server (e probabilmente permessi di root) e possono fare quello che vogliono.

Vado avanti e dirò che non ci sono vantaggi a spostarsi wp-configal di fuori della radice del documento dal punto di vista della sicurezza - per i motivi sopra e questi:

1. È possibile limitare l'accesso al file tramite la configurazione dell'host virtuale o .htaccess, limitando efficacemente l'accesso esterno al file nello stesso modo in cui spostarsi all'esterno della radice del documento
2. Puoi assicurarti che le autorizzazioni dei file siano rigorose wp-configper impedire a qualsiasi utente senza privilegi sufficienti di leggere il file anche se ottengono (limitato) l'accesso al tuo server tramite SSH.
3. Le tue informazioni sensibili, le impostazioni del database, vengono utilizzate solo su un singolo sito. Quindi, anche se un utente malintenzionato avesse accesso a tali informazioni, l'unico sito su cui avrebbe effetto sarebbe l'installazione di WordPress a cui wp-config.phpappartiene il file. Ancora più importante, quell'utente del database ha solo le autorizzazioni per leggere e scrivere nel database di quell'installazione WP e nient'altro - nessun accesso per concedere le autorizzazioni ad altri utenti. Significa, in altre parole, se un utente malintenzionato ottiene l'accesso al database, è semplicemente una questione di ripristino da un backup (vedere il punto 4) e modifica dell'utente del database
4. Fai il backup spesso. Spesso è un termine relativo: se pubblichi 20 articoli ogni giorno, è meglio eseguire il backup ogni giorno o ogni pochi giorni. Se pubblichi una volta alla settimana, il backup una volta alla settimana è probabilmente sufficiente.
5. Hai il tuo sito sotto il controllo della versione ( come questo ), il che significa che anche se un attaccante ha ottenuto l'accesso, puoi facilmente rilevare le modifiche al codice e ripristinarle. Se un attaccante ha accesso a wp-config, probabilmente hanno incasinato qualcos'altro.
6. Le informazioni sul database sono davvero le uniche cose sensibili wp-confige, poiché stai attento (vedi punti 3 e 4), non è un grosso problema. Sali e simili possono essere cambiati in qualsiasi momento. L'unica cosa che succede è che invalida i cookie degli utenti registrati.

Per me, wp-configuscire dal documento radice puzza di sicurezza per oscurità - che è davvero un uomo di paglia.

Penso che Max sia una risposta ben informata, e questo è un lato della storia. Il codice WordPress ha più consigli :

Inoltre, assicurati che solo tu (e il server Web) sia in grado di leggere questo file (generalmente significa un'autorizzazione 400 o 440).

Se usi un server con .htaccess, puoi inserirlo in quel file (in alto) per negare l'accesso a chiunque navighi per esso:

<files wp-config.php>
order allow,deny
deny from all
</files>

Nota che l'impostazione dell'autorizzazione 400 o 440 su wp-config.php potrebbe impedire ai plugin di scriverli o modificarli. Un caso genuino, ad esempio, potrebbe essere la memorizzazione nella cache dei plug-in (W3 Total Cache, WP Super Cache, ecc.) In tal caso, andrei con 600 (l'autorizzazione predefinita per i file nella /home/userdirectory).

Qualcuno ci ha chiesto di brillare e io risponderò qui.

Sì, ci sono vantaggi in termini di sicurezza nell'isolare il tuo wp-config.php dalla directory principale del tuo sito.

1- Se il tuo gestore PHP viene rotto o modificato in qualche modo, le tue informazioni DB non saranno esposte. E sì, l'ho visto accadere alcune volte su host condivisi durante gli aggiornamenti del server. Sì, il sito verrà interrotto durante quel periodo, ma le password saranno intatte.

2- Le migliori pratiche raccomandano sempre di isolare i file di configurazione dai file di dati. Sì, è difficile farlo con WordPress (o qualsiasi app web), ma spostarlo verso l'alto fa un po 'di isolamento.

3- Ricorda la vulnerabilità di PHP-CGI, in cui chiunque potrebbe passare i? -S a un file e visualizzare l'origine. http://www.kb.cert.org/vuls/id/520827

Alla fine, questi sono piccoli dettagli, ma aiutano a minimizzare il rischio. Specialmente se ti trovi in ​​un ambiente condiviso, dove chiunque può accedere al tuo database (tutto ciò di cui hanno bisogno è un utente / pass).

Ma non lasciare che le piccole distrazioni (ottimizzazioni premature) si mettano di fronte a ciò che è veramente necessario per rendere un sito adeguatamente sicuro:

1- Tienilo sempre aggiornato

2- Utilizzare password complesse

3- Limitare l'accesso (tramite autorizzazioni). Abbiamo un post a riguardo qui:

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

Grazie,

Decisamente sì.

Quando sposti wp-config.php fuori dalla directory pubblica lo proteggi dalla lettura usando il browser quando il gestore php viene modificato in modo dannoso (o accidentalmente!).

La lettura del login / password del DB è possibile quando il server è difficilmente infetto da un errore di amministratore scadente. Carica una multa all'amministratore e ottieni un host server più curato e affidabile. Anche se potrebbe essere più costoso.

Voglio solo chiarire, per amor di discussione, che spostare il tuo file wp_config.php non significa necessariamente che devi spostarlo solo nella directory principale. Supponiamo che tu abbia una struttura come / root / html, dove html contiene l'installazione di WP e tutto il tuo contenuto HTML. Invece di spostare wp_config.php su / root, potresti spostarlo su qualcosa come / root / secure ... che è sia esterno alla directory html che non nella directory principale del server. Ovviamente, dovresti assicurarti che php possa essere eseguito anche in questa cartella sicura.

Dato che WP non può essere configurato per cercare wp_config.php in una cartella di pari livello come / root / secure, devi fare un ulteriore passo. Ho lasciato wp_config.php in / root / html e ho ritagliato le parti sensibili (login al database, salt, prefisso tabella) e le ho spostate in un file separato chiamato config.php. Quindi aggiungi il includecomando PHP al tuo wp_config.php, in questo modo:include('/home/content/path/to/root/secure/config.php');

Questo è essenzialmente ciò che ho fatto nella mia configurazione. Ora, sulla base della discussione di cui sopra, sto ancora valutando se è necessaria o addirittura una buona idea. Ma volevo solo aggiungere che la configurazione di cui sopra è possibile. Non espone i tuoi backup e altri file root e fintanto che la cartella sicura non è impostata con il suo URL pubblico, non è navigabile.

Inoltre, puoi limitare l'accesso alla cartella protetta creando un file .htaccess con:

order deny,allow
deny from all
allow from 127.0.0.1

Ci sono molti temi e plugin scritti male che permettono agli atatcker di inserire codice (ricorda il problema di sicurezza con Timthumb). Se dovessi essere un attaccante, perché dovrei cercare wp-config.php? Basta iniettare questo codice:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Puoi provare a nascondere il tuo wp-config.php. Finché WordPress rende accessibili tutte le informazioni sensibili a livello globale, non ha alcun vantaggio nascondere wp-config.php.

La parte negativa di wp-config.php non è che contiene dati sensibili. La parte negativa è definire i dati sensibili come una costante accessibile globale.

Aggiornare

Voglio chiarire i problemi define()e perché è una cattiva idea definire i dati sensibili come una costante globale.

Esistono molti modi per attaccare un sito Web. L'iniezione di script è solo un modo per attaccare un sito web.

Supponendo che il server abbia una vulnerabilità che consente a un utente malintenzionato di accedere a un dump della memoria. L'attaccante troverà nel dump della memoria tutti i valori di tutte le variabili. Se si definisce una costante accessibile globale, deve rimanere in memoria fino alla fine dello script. Creando una variabile anziché una costante, ci sono buone probabilità che il Garbage Collector sovrascriva (o libera) la memoria dopo che la variabile non è più necessaria.

Un modo migliore per proteggere i dati sensibili è eliminarli immediatamente dopo averli utilizzati:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

Dopo aver utilizzato i dati sensibili, l'assegnazione a nullsovrascriverà i dati in memoria. Un utente malintenzionato deve ottenere il dump della memoria nel momento in cui $db_concontiene i dati sensibili. E questo è un tempo molto breve nell'esempio sopra (se la classe Database_Handler non ne salva una copia).

Oltre ai vantaggi di sicurezza, ti consente anche di mantenere l'istanza di WordPress sotto il controllo della versione mantenendo i file principali di WordPress come sottomodulo / esterno. Ecco come Mark Jaquith ha realizzato il suo progetto WordPress-Skeleton. Vedi https://github.com/markjaquith/WordPress-Skeleton#assumptions per i dettagli.