Recentemente ho avuto un problema per il quale non sono stato in grado di installare il plugin WP Smush Pro perché non ho linstallazione manuale o linstallazione con un clic opzioni disponibili.
Mi sono imbattuto in questo post che suggeriva di modificare le impostazioni in wp-config.php. Ho aggiunto le impostazioni suggerite, tuttavia quella che sembra essere la più importante è:
define("FS_METHOD", "direct");
Cosa vorrei sapere Quali sono le reali preoccupazioni che dovrei avere riguardo allimpostazione di FS_METHOD su direct? Esistono altre alternative allinstallazione del plug-in?
Questo è ciò che dice la documentazione ufficiale:
FS_METHOD forza il metodo del filesystem. Dovrebbe essere solo “direct”, “ssh2″, ” ftpext “, o” ftpsockets “. Generalmente, dovresti cambiarlo solo se hai problemi di aggiornamento. Se lo modifichi e non aiuta, cambialo di nuovo / re spostalo. Nella maggior parte dei casi, impostarlo su “ftpsockets” funzionerà se il metodo scelto automaticamente non lo fa.
(Preferenza primaria) “diretto” lo costringe a usare richieste di I / O file diretto da PHP, questo è irto di problemi di sicurezza su host mal configurati, viene scelto automaticamente quando appropriato.
Risposta
Questo è solo il modo in cui ho capito lidea dell API di file WordPress . Se è sbagliato, per favore downvote 🙂
Ok. Se carichi un file, questo file ha un proprietario. Se carichi il tuo file con FTP, effettui il login e il file sarà di proprietà dellutente FTP. Dato che hai le credenziali, puoi modificare questi file tramite FTP. Il proprietario di solito può eseguire, eliminare, alterare ecc. Il file. Ovviamente puoi cambiare questa impostazione cambiando i permessi del file .
Se carichi un file utilizzando PHP, lutente linux, che è lesecuzione di PHP è il proprietario del file. Questo utente può ora modificare, eliminare, eseguire ecc. Il file. Questo va bene fintanto che solo tu sei lutente, che sta eseguendo PHP sul tuo sistema.
Supponiamo che tu sia su un host condiviso “mal configurato”. Molte persone gestiscono i propri 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 capisce il percorso per la tua installazione di WordPress. Ad esempio, WP_DEBUG è impostato su true e viene visualizzato un messaggio di errore del tipo
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1 “Ha!” dice il cattivo ragazzo. Vediamo, se questo tipo ha impostato FS_METHOD su direct e scrive uno script come
<?php unlink( "/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php" ); ?> Poiché un solo utente esegue PHP e questo utente è anche usato dal cattivo ragazzo, può alterare / eliminare / eseguire i file sul tuo sistema se li hai caricati tramite PHP e da questo allegato il PHP utente come proprietario.
Il tuo sito è stato compromesso.
Oppure, come dice il Codex:
Molti sistemi di hosting hanno il server web in esecuzione come un utente diverso dal proprietario dei file WordPress. In questo caso, un processo che scrive i file dallutente del server web avrà i file risultanti di proprietà dellaccount utente del server web invece dellaccount dellutente effettivo. Ciò può portare a un problema di sicurezza in situazioni di hosting condiviso, in cui più utenti condividono lo stesso server web per siti diversi.
Risposta
Qual è il rischio?
Su un host condiviso mal configurato, il PHP di ogni cliente verrà eseguito come lo stesso utente (diciamo apache per la discussione). Questa configurazione è sorprendentemente comune.
Se sei su un host di questo tipo e utilizzi WordPress per installare il plug-in utilizzando laccesso diretto ai file, i file del tuo plugin apparterranno a apache. Un utente legittimo sullo stesso server potrebbe attaccarti scrivendo uno script PHP che inietta codice malvagio nei tuoi file plugin. Caricano il loro script sul proprio sito web e richiedono il suo URL. Il tuo codice è stato compromesso correttamente perché il loro script viene eseguito come apache, lo stesso che possiede i file del tuo plug-in.
Cosa fa FS_METHOD "direct" centra?
Quando WordPress ha bisogno di installare file (come un plugin) utilizza get_filesystem_method () funzione per determinare come accedere al filesystem. Se non definisci FS_METHOD, sceglierà un valore predefinito, altrimenti utilizzerà la tua selezione finché ha senso.
Il comportamento predefinito proverà per rilevare se “ti trovi in un ambiente a rischio come il uno che ho descritto sopra, e se pensa che “sei al sicuro, utilizzerà il metodo "direct". In questo caso WordPress creerà i file direttamente tramite PHP, facendoli appartenere allutente apache (in questo esempio). Altrimenti ricadrà su un metodo più sicuro, come chiederti le credenziali SFTP e creare i file come te.
FS_METHOD = "direct" chiede a WordPress di ignorarlo a -rilevamento del rischio e sempre creare file utilizzando il metodo "direct".
Allora perché utilizzare 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 implica 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 gli stessi, PHP è in esecuzione come il tuo account ed è sicuro installare plugin come quello account. Se sono diversi, WordPress presume che PHP sia in esecuzione come account condiviso e non è sicuro installare plug-in come tale account. Sfortunatamente entrambi questi presupposti sono ipotesi plausibili che spesso saranno errate.
Useresti define("FS_METHOD", "direct" ); in uno scenario 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 se fosse separato utente. WordPress presumerà che questo sia un ambiente a rischio e non utilizzerà per impostazione predefinita la modalità "direct". In realtà è condivisa solo con utenti di cui ti fidi e come tale "direct" è sicura. In questo caso dovresti utilizzare define("FS_METHOD", "direct" ); per forzare WordPress a scrivere direttamente i file.
Commenti
Risposta
Cè un” ben configurato ” situazione in cui “diretto” porterà a problemi.
È anche possibile configurare hosting WP condiviso con utenti di esecuzione PHP non condivisi, diversi dagli utenti di proprietà di file / directory. Quindi ti ritroverai con i file di proprietà di utente1 e il codice PHP viene eseguito come php-utente1.
In quella situazione, i plugin hackerati o il codice principale (a) non possono scrivere (o anche leggere da , a seconda delle autorizzazioni) directory di altri utenti; (b) non è possibile “scrivere i file di questo utente” e quindi non è possibile “aggiungere codice trojan al codice principale o al codice del plug-in.
Quindi se lhosting è configurato in questo modo , DEVI usare FTP per gli aggiornamenti e “direct” non funzionerà.
Se imposti “direct” in wp-config.php e lutente che esegue PHP non ha il permesso di scrittura, otterrai Update Messaggi non riusciti e nessun popup che richiede le credenziali FTP.
get_filesystem_method()a questo: developer.wordpress.org/reference/functions/…