Quais preocupações de segurança devo ter ao definir FS_METHOD como "direto" no wp-config?

Recentemente, tive um problema em que não consegui instalar o plug-in do WP Smush Pro porque não tenho as opções de instalação manual ou instalação com um clique disponíveis.

Me deparei com este post que sugeria ajustar as configurações wp-config.php. Eu adicionei as configurações sugeridas, no entanto, a que parece ser a mais importante é:

define('FS_METHOD', 'direct');

O que eu gostaria de saber é que preocupações reais devo ter em relação FS_METHODà configuração direct? Existem outras alternativas para instalar o plugin?

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 com problemas de atualização. Se você alterá-lo e não ajudar, altere-o novamente / remova-o. Na maioria das circunstâncias, configurá-lo como 'ftpsockets' funcionará se o método escolhido automaticamente não funcionar.

(Preferência primária) "direct" obriga a usar solicitações de E / S de arquivo direto do PHP, isso é repleto de problemas de segurança em hosts mal configurados. É escolhido automaticamente quando apropriado.

É assim que entendi a idéia da API de arquivos do WordPress . Se estiver errado, por favor vote abaixo :)

OK. Se você enviar um arquivo, esse arquivo possui um proprietário. Se você fizer o upload do seu arquivo com FTP, efetue login e o arquivo será de propriedade do usuário do FTP. Como você possui as credenciais, é possível alterar esses arquivos através do FTP. O proprietário normalmente pode executar, excluir, alterar etc. o arquivo. Obviamente, você pode alterar isso alterando as permissões do arquivo .

Se você fizer upload de um arquivo usando PHP, o usuário linux, que está executando o PHP, será o proprietário do arquivo. Este usuário agora pode editar, excluir, executar etc. o arquivo. Tudo bem, desde que você seja o usuário que executa o PHP no seu sistema.

Vamos supor que você esteja em um host compartilhado "mal" configurado. Muitas pessoas executam seus sites PHP neste sistema. Digamos que apenas um usuário Linux esteja executando o 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 sua instalação do WordPress. Por exemplo, WP_DEBUG está definido como true 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 bad boy diz. Vamos ver, se esse cara criou FS_METHODpara directe ele escreve um roteiro como

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

Como apenas um usuário está executando o PHP e esse usuário também é usado pelo bad boy, ele pode alterar / excluir / executar os arquivos no seu sistema se você os tiver carregado por meio do PHP e por isso anexou o usuário do PHP como proprietário.

Seu site foi invadido.

Ou, como diz o Codex:

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

Qual é o risco?

Em um host compartilhado mal configurado, o PHP de cada cliente será executado como o mesmo usuário (digamos apachepara 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 a arquivos, todos os seus arquivos pertencerão apache. Um usuário legítimo no mesmo servidor poderá atacá-lo escrevendo um script PHP que injeta código incorreto nos arquivos de plug-in. Eles enviam o script para o próprio site e solicitam seu URL. Seu código foi comprometido com êxito porque o script é executado como apacheo mesmo que possui os arquivos de plug-in.

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

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

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

FS_METHOD = 'direct'pede ao WordPress para ignorar essa detecção de risco e sempre cria arquivos usando o 'direct'método

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. Ops. O teste envolve a criação de um arquivo e a certeza de que ele pertence ao mesmo proprietário que o diretório em que ele vive. O pressuposto é que, se os usuários forem iguais, o PHP será executado como sua própria conta e é seguro instalar plug-ins como essa conta. Se forem diferentes, o WordPress assume 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 educadas que freqüentemente estarão erradas.

Você usaria define('FS_METHOD', 'direct' );em um cenário falso positivo como este: você faz parte de uma equipe confiável, cujos membros todos carregam arquivos por meio de sua própria conta. O PHP é executado como seu próprio usuário separado. O WordPress assumirá que este é um ambiente de risco e não assumirá o 'direct'modo padrão . Na realidade, ele é compartilhado apenas com usuários em quem você confia e, como tal, o 'direct'modo é seguro. Nesse caso, você deve define('FS_METHOD', 'direct' );forçar o WordPress a gravar arquivos diretamente.

Há uma situação 'bem configurada' em que 'direta' levará a problemas.

Também é possível configurar a hospedagem WP compartilhada com usuários de execução PHP não compartilhados, diferente dos usuários de propriedade de 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, os plug-ins invadidos ou o código principal (a) não podem gravar (ou mesmo ler, dependendo das permissões) de outros usuários; (b) não pode gravar os arquivos deste usuário e, portanto, não pode adicionar o código de trojan ao código principal ou do plug-in.

Portanto, se a hospedagem estiver configurada assim, você DEVE usar o FTP para atualizações e 'direto' não funcionará.

Se você definir 'direct' no wp-config.php e o usuário de execução do PHP não tiver permissão de gravação, você receberá as mensagens Falha na atualização e não haverá pop-up solicitando credenciais de FTP.