Quali problemi di sicurezza dovrei avere quando si imposta FS_METHOD su "direct" in wp-config?

Di recente ho riscontrato un problema in cui non sono stato in grado di installare il plug-in WP Smush Pro perché non ho le opzioni di installazione manuale o installazione con un clic disponibili.

Mi sono imbattuto in questo post che mi ha suggerito di modificare le impostazioni wp-config.php. Ho aggiunto le impostazioni suggerite, tuttavia quella che sembra essere la più importante è:

define('FS_METHOD', 'direct');

Quello che mi piacerebbe sapere è quello che riguarda vero avrei dovuto giro impostazione FS_METHODa direct? Ci sono altre alternative all'installazione del plugin?

Questo è ciò che la documentazione ufficiale ha da dire:

FS_METHOD forza il metodo del filesystem. Dovrebbe essere solo "diretto", "ssh2", "ftpext" o "ftpsocket". In genere, è necessario modificarlo solo se si verificano problemi di aggiornamento. Se lo cambi e non aiuta, cambialo / rimuovilo. Nella maggior parte dei casi, impostarlo su "ftpsocket" funzionerà se il metodo scelto automaticamente non funziona.

(Preferenza primaria) "diretto" lo costringe a utilizzare le richieste di I / O di file diretti dall'interno di PHP, questo è irto di problemi di sicurezza su host mal configurati, Questo viene scelto automaticamente quando appropriato.

Questo è solo il modo in cui ho capito l'idea dell'API File WordPress . Se è sbagliato, si prega di votare :)

Va bene. Se carichi un file, questo file ha un proprietario. Se carichi il tuo file con FTP, accedi e il file sarà di proprietà dell'utente FTP. Dal momento che si dispone delle credenziali, è possibile modificare questi file tramite FTP. Il proprietario di solito può eseguire, eliminare, alterare ecc. Il file. Naturalmente, puoi cambiarlo cambiando le autorizzazioni del file .

Se carichi un file usando PHP, l'utente Linux, che sta eseguendo PHP, possiede il file. Questo utente può ora modificare, eliminare, eseguire ecc. Il file. Questo va bene finché solo tu sei l'utente che esegue PHP sul tuo sistema.

Supponiamo che ci si trovi su un host condiviso "mal configurato". Molte persone gestiscono i loro siti Web PHP su questo sistema. Diciamo che solo un utente Linux sta eseguendo PHP per tutte queste persone. Uno dei webmaster su questo host condiviso ha cattive intenzioni. Vede la tua pagina e trova il percorso per la tua installazione di WordPress. Ad esempio, WP_DEBUG è impostato su true e viene visualizzato un messaggio di errore simile

[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1

"Ah!" dice il cattivo. Vediamo, se questo ragazzo ha fissato FS_METHODper directe scrive uno script come

<?php
unlink( '/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php' );
?>

Dal momento che solo un utente esegue PHP e questo utente viene utilizzato anche dal cattivo ragazzo, può modificare / eliminare / eseguire i file sul proprio sistema se li hai caricati tramite PHP e da questo allegato l'utente PHP come proprietario.

Il tuo sito è stato violato.

O, come dice nel Codice:

Molti sistemi di hosting hanno il server web in esecuzione come un utente diverso rispetto al proprietario dei file WordPress. In questo caso, un processo di scrittura dei file dell'utente del server Web avrà i file risultanti di proprietà dell'account utente del server Web anziché dell'account dell'utente reale. Ciò può comportare un problema di sicurezza in situazioni di hosting condiviso, in cui più utenti condividono lo stesso server Web per siti diversi.

Qual è il rischio?

Su un host condiviso mal configurato, il PHP di ogni cliente verrà eseguito come lo stesso utente (diciamo apacheper la discussione). Questa configurazione è sorprendentemente comune.

Se sei su un host del genere e usi WordPress per installare il plug-in usando l'accesso diretto ai file, tutti i tuoi file plug-in apparterranno apache. Un utente legittimo sullo stesso server sarebbe in grado di attaccarti scrivendo uno script PHP che inietta codice malvagio nei tuoi file plugin. Caricano il loro script sul proprio sito Web e ne richiedono l'URL. Il tuo codice è stato compromesso con successo perché il loro script viene eseguito come apache, lo stesso che possiede i tuoi file plugin.

Cosa FS_METHOD 'direct'c'entra con questo?

Quando WordPress deve installare file (come un plug-in), utilizza la funzione get_filesystem_method () per determinare come accedere al filesystem. Se non lo definisci FS_METHOD, sceglierà un valore predefinito per te, altrimenti utilizzerà la tua selezione fintanto che avrà senso.

Il comportamento predefinito proverà a rilevare se ti trovi in ​​un ambiente a rischio come quello che ho descritto sopra e se pensa di essere al sicuro utilizzerà il 'direct'metodo. In questo caso WordPress creerà i file direttamente tramite PHP, facendoli appartenere apacheall'utente (in questo esempio). Altrimenti tornerà a un metodo più sicuro, come richiedere le credenziali SFTP e creare i file come te.

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

Allora perché usare FS_METHOD = 'direct'?

Sfortunatamente, la logica di WordPress per rilevare un ambiente a rischio è difettosa e produce sia falsi positivi che falsi negativi. Ops. Il test prevede la creazione di un file e la verifica che appartenga allo stesso proprietario della directory in cui risiede. Il presupposto è che se gli utenti sono uguali, PHP è in esecuzione come proprio account ed è sicuro installare plug-in come tale account. Se sono diversi, WordPress presuppone che PHP sia in esecuzione come account condiviso e non è sicuro installare plug-in come tale account. Sfortunatamente entrambe queste ipotesi sono ipotesi colte che spesso saranno sbagliate.

Utilizzeresti define('FS_METHOD', 'direct' );in uno scenario falso positivo come questo: fai parte di un team di fiducia i cui membri caricano tutti i file tramite il proprio account. PHP viene eseguito come proprio utente separato. WordPress supporrà che si tratti di un ambiente a rischio e non passerà alla 'direct'modalità predefinita . In realtà è condiviso solo con utenti di cui ti fidi e come tale 'direct'modalità è sicura. In questo caso dovresti usare define('FS_METHOD', 'direct' );per forzare WordPress a scrivere direttamente i file.

Esiste una situazione "ben configurata" in cui "diretto" porterà a problemi.

È anche possibile configurare l'hosting WP condiviso con utenti di esecuzione PHP non condivisi, diversi dagli utenti di proprietà di file / directory. Quindi finisci con i file di proprietà di user1 e il codice PHP viene eseguito come php-user1.

In tale situazione, plug-in compromessi o codice core (a) non possono scrivere (o persino leggere, a seconda delle autorizzazioni) la direzione di altri utenti; (b) non può scrivere i file di questo utente e quindi non può aggiungere il codice trojan al codice core o al plugin.

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

Se imposti "direct" in wp-config.php e l'utente dell'esecuzione di PHP non dispone dell'autorizzazione di scrittura, otterrai messaggi di aggiornamento non riusciti e non appariranno pop-up che richiedono credenziali FTP.