Quali problemi di sicurezza dovrei considerare quando imposto FS_METHOD su "direct" in wp-config?

Qual è il rischio?

Su un host condiviso configurato male, il PHP di ogni cliente verrà eseguito come lo stesso utente (diciamo apache per questo esempio). Questa configurazione è sorprendentemente comune.

Se sei su un host del genere e usi WordPress per installare il plugin con accesso diretto ai file, tutti i file del plugin apparterranno a apache. Un utente legittimo sullo stesso server potrebbe attaccarti scrivendo uno script PHP che inietta codice malevolo nei tuoi file del plugin. Caricano il loro script sul loro sito web e ne richiedono l'URL. Il tuo codice viene compromesso con successo perché il loro script viene eseguito come apache, lo stesso utente che possiede i tuoi file del plugin.

Cosa c'entra FS_METHOD 'direct'?

Quando WordPress deve installare file (come un plugin) usa la funzione get_filesystem_method() per determinare come accedere al filesystem. Se non definisci FS_METHOD sceglierà un valore predefinito, altrimenti userà la tua scelta se ha senso.

Il comportamento predefinito proverà a rilevare se sei in un ambiente a rischio come quello descritto sopra, e se pensa che sei al sicuro userà il metodo 'direct'. In questo caso WordPress creerà i file direttamente tramite PHP, facendoli appartenere all'utente apache (in questo esempio). Altrimenti ripiegherà su un metodo più sicuro, come chiederti le credenziali SFTP e creare i file come te.

FS_METHOD = 'direct' chiede a WordPress di ignorare quel rilevamento di rischio e sempre creare file usando il metodo 'direct'.

Allora perché usare FS_METHOD = 'direct'?

Sfortunatamente, la logica di WordPress per rilevare un ambiente a rischio è imperfetta e produce sia falsi positivi che falsi negativi. Ops. Il test consiste nel creare un file e assicurarsi che appartenga allo stesso proprietario della directory in cui si trova. L'assunzione è che se gli utenti sono gli stessi, PHP è in esecuzione come il tuo account ed è sicuro installare plugin come quell'account. Se sono diversi, WordPress assume che PHP sia in esecuzione come un account condiviso e non è sicuro installare plugin come quell'account. Sfortunatamente entrambe queste assunzioni sono ipotesi che spesso saranno sbagliate.

Useresti define('FS_METHOD', 'direct' ); in uno scenario di falso positivo come questo: fai parte di un team fidato i cui membri caricano tutti i file tramite il proprio account. PHP viene eseguito come un utente separato. WordPress assumerà che questo sia un ambiente a rischio e non userà il metodo predefinito 'direct'. In realtà è condiviso solo con utenti di cui ti fidi e quindi il metodo 'direct' è sicuro. In questo caso dovresti usare define('FS_METHOD', 'direct' ); per forzare WordPress a scrivere i file direttamente.

C'è una situazione 'ben configurata' in cui l'opzione 'direct' porterà a problemi.

È anche possibile configurare un hosting WordPress condiviso con utenti di esecuzione PHP non condivisi, diversi dagli utenti proprietari di file/directory. Quindi si finisce con i file di proprietà di user1 e il codice PHP viene eseguito come php-user1.

In quella situazione, plugin o codice core compromessi (a) non possono scrivere (o persino leggere, a seconda dei permessi) le directory di altri utenti; (b) non possono scrivere i file di questo utente e quindi non possono aggiungere codice trojan al core o al codice dei plugin.

Quindi se l'hosting è configurato in questo modo, DEVI usare FTP per gli aggiornamenti e l'opzione 'direct' non funzionerà.

Se imposti 'direct' in wp-config.php e l'utente di esecuzione PHP non ha i permessi di scrittura, riceverai messaggi di "Aggiornamento fallito" e non apparirà alcun pop-up che chiede le credenziali FTP.