Recentemente, tive um problema em que não consigo instalar o plugin WP Smush Pro porque não tenho a instalação manual ou instalação com um clique opções disponíveis.

Eu encontrei esta postagem que sugeria ajustar as configurações em wp-config.php. Eu adicionei as configurações sugeridas, porém a que parece ser a mais importante é:

define("FS_METHOD", "direct");

O que eu gostaria de saber quais são as reais preocupações que devo ter em relação à configuração de FS_METHOD como direct? Existem outras alternativas para instalar o plug-in?

Isto é o que a documentação oficial tem a dizer:

FS_METHOD força o método do sistema de arquivos. Deve ser apenas “direto”, “ssh2″, ” ftpext “ou” ftpsockets “. Geralmente, você só deve alterar isso se estiver tendo problemas de atualização. Se você alterar e não ajudar, altere novamente / novamente Mova isso. Na maioria das circunstâncias, configurá-lo para “ftpsockets” funcionará se o método escolhido automaticamente não funcionar.

(Preferência primária) “direct” força-o a usar solicitações de I / O de arquivo direto de dentro do PHP, isto é repleto de problemas de segurança em hosts mal configurados, é escolhido automaticamente quando apropriado.

Resposta

Foi assim que entendi a ideia da API de arquivos WordPress . Se estiver errado, vote downvote 🙂

Ok. Se você carregar um arquivo, este arquivo terá um proprietário. Se você enviar seu arquivo com FTP, faça o login e o arquivo será propriedade do usuário do FTP. Como você tem as credenciais, pode alterar esses arquivos por meio do FTP. O proprietário geralmente pode executar, excluir, alterar etc. o arquivo. Claro, você pode mudar isso alterando as permissões do arquivo .

Se você enviar um arquivo usando PHP, o usuário do linux, que é executar o PHP é possuir o arquivo. Este usuário agora pode editar, excluir, executar etc. o arquivo. Tudo bem, contanto que apenas você seja o usuário que está executando o PHP em seu sistema.

Vamos supor que você esteja em um host compartilhado “mal” configurado. Muitas pessoas executam seus sites PHP neste sistema. Vamos dizer que apenas um usuário Linux está executando PHP para todas essas pessoas. Um dos webmasters neste host compartilhado tem más intenções. Ele vê sua página e descobre o caminho para a instalação do WordPress. Por exemplo, WP_DEBUG é definido como verdadeiro e há uma mensagem de erro como 

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

“Ha!” o menino mau diz. Vamos ver se esse cara definiu FS_METHOD como direct e escreveu um script como 

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

Uma vez que apenas um usuário está executando o PHP e este usuário também é usado pelo bad boy, ele pode alterar / excluir / executar os arquivos em seu sistema se você os carregou via PHP e anexou o PHP usuário como proprietário.

Seu site foi hackeado.

Ou, como diz no Codex:

Muitos sistemas de hospedagem têm o servidor da web rodando como um usuário diferente do proprietário dos arquivos WordPress. Quando este for o caso, um processo de gravação de arquivos do usuário do servidor web terá os arquivos resultantes pertencentes à conta do usuário do servidor web em vez da conta do usuário real. Isso pode levar a um problema de segurança em situações de hospedagem compartilhada, em que vários usuários compartilham o mesmo servidor da web para sites diferentes.

Resposta

Qual é o risco?

Em um host compartilhado mal configurado, o PHP de cada cliente será executado como o mesmo usuário (digamos apache para discussão). Essa configuração é surpreendentemente comum.

Se você estiver em um host e usar o WordPress para instalar o plug-in usando acesso direto ao arquivo, todos seus arquivos de plug-in pertencerão a apache. Um usuário legítimo no mesmo servidor seria capaz de atacá-lo escrevendo um script PHP que injeta código maligno em seus arquivos de plug-in. Eles carregam seu script em seu próprio site e solicitam seu URL. Seu código foi comprometido com sucesso porque seu script é executado como apache, o mesmo que possui seus arquivos de plug-in.

O que FS_METHOD "direct" tem a ver com isso?

Quando o WordPress precisa instalar arquivos (como um plugin), ele usa get_filesystem_method () função para determinar como acessar o sistema de arquivos. Se você não definir FS_METHOD, ele escolherá um padrão para você, caso contrário, usará sua seleção, desde que faça sentido.

O comportamento padrão tentará para detectar se você “está em um ambiente de risco como o um que descrevi acima, e se ele achar que você está seguro, usará o método "direct". Nesse caso, o WordPress criará os arquivos diretamente por meio do PHP, fazendo com que eles pertençam ao usuário apache (neste exemplo). Caso contrário, ele “recorrerá a um método mais seguro, como solicitar credenciais SFTP e criar os arquivos como você.

FS_METHOD = "direct" pede ao WordPress para ignorar isso em -detecção de risco e sempre criar arquivos usando o método "direct".

Então, por que usar FS_METHOD = "direct"?

Infelizmente, a lógica do WordPress “para detectar um ambiente de risco é falha e produz falsos positivos e falsos negativos. Opa. O teste envolve a criação de um arquivo e a garantia de que ele pertence ao mesmo proprietário do diretório em que reside. A suposição é que, se os usuários forem os mesmos, o PHP está sendo executado como sua própria conta e é seguro instalar plug-ins como esse Se eles forem diferentes, o WordPress presume que o PHP está sendo executado como uma conta compartilhada e não é seguro instalar plug-ins como essa conta. Infelizmente, essas duas suposições são suposições que frequentemente estarão erradas.

Você usaria define("FS_METHOD", "direct" ); em um cenário de falso positivo como este: você faz parte de uma equipe confiável cujos membros carregam arquivos através de suas próprias contas. O PHP é executado separadamente usuário. O WordPress presumirá que este é um ambiente de risco e não terá como padrão o modo "direct". Na realidade, ele é compartilhado apenas com usuários em quem você confia e, como tal, "direct" é seguro. Nesse caso, você deve usar define("FS_METHOD", "direct" ); para forçar o WordPress a gravar arquivos diretamente.

Comentários

Resposta

Existe um” bem configurado ” situação em que “direto” levará a problemas.

Também é possível configurar a hospedagem WP compartilhada com usuários de execução PHP não compartilhados, diferentes dos usuários que possuem arquivos / diretórios. Então você acaba com os arquivos pertencentes ao usuário1 e o código PHP é executado como php-user1.

Nessa situação, plug-ins hackeados ou código principal (a) não podem “escrever para (ou mesmo ler de , dependendo das permissões) diretório de outros usuários; (b) não consigo escrever os arquivos deste de usuário e, portanto, não posso adicionar código de cavalo de Tróia ao código do núcleo ou do plugin.

Portanto, se a hospedagem for configurada dessa forma , você DEVE usar FTP para atualizações e “direto” não funcionará.

Se você definir “direto” em wp-config.php e o usuário de execução de PHP não tiver permissão de gravação, você obterá Update Mensagens com falha e sem pop-up solicitando credenciais de FTP.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *