As pastas de plug-in devem incluir um arquivo index.php em branco?


16

O próprio WordPress, na wp-contentpasta, inclui um arquivo PHP vazio que se parece com isso.

<?php
// Silence is golden.
?>

Os plug-ins devem incluir um arquivo vazio como esse para impedir que as pessoas visualizem o conteúdo de um diretório? E quanto a pastas adicionais em temas - como um includesdiretório?


1
Sim, provavelmente é uma boa ideia. Nunca entendi por WP não tem Options –Indexesno htaccess empacotado, então esses arquivos não seria necessário ...
onetrickpony

Respostas:


17

Não, eles não deveriam. Se um plugin tem vulnerabilidades apenas porque alguém pode ver sua estrutura de diretórios, ele está quebrado. Esses erros devem ser corrigidos.
A segurança através da obscuridade é um bug para si.

Cabe ao proprietário do site permitir ou proibir a navegação no diretório.

Uma segunda questão é o desempenho: o WordPress verifica todos os arquivos PHP no diretório raiz de um plug-in para encontrar cabeçalhos de plug-in. Isso permite que você tenha vários plugins no mesmo diretório, por exemplo /wp-content/plugins/wpse-examples/.

Isso também significa que arquivos PHP não utilizados nesse diretório estão perdendo tempo e memória quando o WordPress está procurando plugins. Um arquivo não causará muitos danos, mas imagine que isso esteja sendo uma prática comum. Você está criando um problema real na tentativa de corrigir uma ficção.


2
"Cabe ao proprietário do site permitir ou proibir a navegação no diretório." Esse é provavelmente o ponto principal.
Chrisguitarguy

e minha pergunta principal é: por que não os arquivos principais do plug-in não estão escritos index.php? que pode ser solução óptima
T.Todua

10

Eu vou dizer sim. Segurança através da obscuridade funciona se você for mais obscuro do que seus vizinhos :) (brincando, mas há alguma verdade nisso).

A realidade é que os bots / scanners agora compilam as listas de plugins logo no wordpress.org e rastreiam diretamente as URLs dos plugins, versões de impressões digitais para explorações conhecidas e mantêm as informações em um banco de dados para referência.

Então, qual você prefere, um bot que não consiga coletar informações sobre sua instalação ou deixa para o autor do plugin para garantir sua segurança. Que tal ambos.

ps. Em uma nota lateral, houve 186 explorações relatadas nos plugins do wordpress.org no ano passado. (* Relatado ..).


1
Os scanners de exploração não testam se o plug-in existe. Eles tentam executar a exploração durante a primeira solicitação. Um vazio index.phpnão protegeria nada, você apenas teria uma falsa sensação de segurança.
fuxia

Mas eles fazem, o wp-scan (um dos muitos) imprime mais de 2200 plugins, por exemplo, e usa algumas impressões digitais decentes para detectar versões (tamanho do arquivo, adições de arquivos, etc.).
21412 Wyck

Limpei dezenas de sites WordPress hackeados. Quase sempre o primeiro pedido foi um ataque real. Isso é razoável: por que perder tempo com uma verificação detalhada se você pode testar a vulnerabilidade na primeira solicitação? Acompanhe seus 404s para vê-lo. :)
fuxia

1
Concordo que isso deve ser do usuário final e não do autor. Mas também não acho que dói. Eu só queria adicionar um contraponto, já que você disse "não".
21412 Wyck

1
marcou este como aceito por causa do debate de comentários!
Chrisguitarguy

1

Como o núcleo do WordPress faz isso, faz sentido que os plugins sigam o exemplo. Embora tudo isso possa ser protegido com várias configurações do lado do servidor, não faz mal ter um padrão (provavelmente porque o núcleo do WordPress faz isso).


0

Como fuxia apontou, há uma desvantagem de desempenho em ter um .phparquivo extra que o WordPress deve procurar por plugins. Uma index.htmlprovavelmente seria uma opção melhor. Obviamente, a melhor opção seria proibir a navegação no diretório através do servidor web.

E também, segurança através da obscuridade não é boa.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.