¿Deberían las carpetas de complementos incluir un archivo index.php en blanco?


16

WordPress en sí, en la wp-contentcarpeta, incluye un archivo PHP vacío que se ve así.

<?php
// Silence is golden.
?>

¿Deberían los complementos incluir un archivo vacío como este también para evitar que la gente vea el contenido de un directorio? ¿Qué pasa con las carpetas adicionales en los temas, como un includesdirectorio?


1
Sí, probablemente sea una buena idea. Nunca pude entender por qué WP no tiene Options –Indexesen el .htaccess incluido, por lo que estos archivos no serían necesarios ...
onetrickpony

Respuestas:


17

No, no deberían. Si un complemento tiene vulnerabilidades solo porque alguien pueda ver su estructura de directorios, está roto. Estos errores deben corregirse.
La seguridad a través de la oscuridad es un error en sí mismo.

Depende del propietario del sitio permitir o prohibir la exploración de directorios.

Un segundo problema es el rendimiento: WordPress escanea todos los archivos PHP en el directorio raíz de un complemento para encontrar encabezados de complemento. Esto le permite tener múltiples complementos en el mismo directorio, por ejemplo /wp-content/plugins/wpse-examples/.

También significa que los archivos PHP no utilizados en ese directorio están desperdiciando tiempo y memoria cuando WordPress está buscando complementos. Un archivo no hará mucho daño, pero imagine que esto se está convirtiendo en una práctica común. Estás creando un problema real en un intento de arreglar una ficción.


2
"Depende del propietario del sitio permitir o prohibir la exploración de directorios". Ese es probablemente el punto clave.
chrisguitarguy

y mi pregunta principal es, ¿por qué no los archivos del complemento principal no están escritos index.php? eso podría ser una solución óptima
T.Todua

10

Voy a decir que sí. La seguridad a través de la oscuridad funciona si eres más oscuro que tus vecinos :) (bromeando, pero hay algo de verdad en eso).

La realidad es que los bots / escáneres ahora compilan las listas de complementos directamente desde wordpress.org y rastrean directamente la url del complemento, las versiones de huellas digitales para exploits conocidos y mantienen la información en una base de datos como referencia.

Entonces, ¿cuál preferiría tener, un bot que no puede recopilar información sobre su instalación o dejarlo en manos del autor del complemento para asegurarse de que esté seguro? ¿Qué tal ambos?

PD. En una nota al margen, hubo 186 vulnerabilidades reportadas de los complementos de wordpress.org el año pasado (* informó ...).


1
Los exploradores de exploits no prueban si existe el complemento. Intentan ejecutar el exploit durante la primera solicitud. Un vacío index.phpno protegería nada, solo obtendría una falsa sensación de seguridad.
fuxia

Pero lo hacen, wp-scan (una de muchas) huellas dactilares en más de 2200 complementos, por ejemplo, y utiliza algunas huellas dactilares decentes para detectar versiones (tamaño de archivo, adiciones de archivos, etc.).
Wyck

He limpiado docenas de sitios pirateados de WordPress. Casi siempre la primera solicitud fue un verdadero ataque. Eso es razonable: ¿por qué perder el tiempo con un escaneo detallado si puede probar la vulnerabilidad en la primera solicitud? Rastrea tus 404 para verlo. :)
fuxia

1
Estoy de acuerdo, esto debería depender del usuario final y no del autor. Pero tampoco creo que duela. Solo quería agregar un contrapunto ya que dijiste "no".
Wyck

1
marcó este como aceptado debido al debate de comentarios!
chrisguitarguy

1

Dado que el núcleo de WordPress lo hace, tiene sentido que los complementos sigan su ejemplo. Si bien todo esto se puede proteger con varias configuraciones del lado del servidor, no está de más tener un valor predeterminado (probablemente por qué lo hace el núcleo de WordPress).


0

Como señaló Fuxia, existe un inconveniente en el rendimiento al tener un .phparchivo adicional que WordPress escanea en busca de complementos. Un index.htmlprobablemente sería una mejor opción. Por supuesto, la mejor opción sería prohibir la exploración de directorios a través del servidor web.

Y también, la seguridad a través de la oscuridad no es buena.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.