Si alguna vez has desarrollado alguna extensión en Joomla, seguro que te es familiar la regla de index.html, que es la necesidad de poner una fihero index.html «en blanco» en cada uno de los directorios que contengan ficheros PHP. Este hábito está tan arraigada en la mentalidad de los desarrolladores de Joomla que se ha apodado «una función de seguridad» y se hizo requisito para publicar una extensión en el Directorio de Extensiones Joomla!. El caso es, ¿Realmente es una medida de seguridad o un intento de solucionar el problema equivocado?
Primero, examinemos la razón de poner ficheros index.html por todos lados. Como seguramente sabes, en la mayoría de servidores web, si no pones los ficheros index.html dentro de un directorio, todos sus contenidos se listan en el navegador. Por ejemplo, si elimino el fichero index.html del directorio de caché y accedo a él como http://www.ejemplo.com/cache/ obtengo el listado completo de el contenido del directorio caché.
Esto implica que un atacante potencial puede hacer click en cualquiera de estos enlaces y ver los contenidos de lasa paginas cacheadas. Incluso peor, veamos lo que sucede si hay un fichero PHP dentro (como en el ejemplo anterior), y hacen click en él. Oops! El fichero se ejecutó.
Esto es un riesgo de seguridad, por tres razones. La primera razón es que accediendo directamente a los ficheros PHP en tu sitio, un cracker podría recuperar información sensible sobre tu sitio (como la estructura del árbol en tu servidor) a directamente injectar SQL y ficheros en tu código. La otra razón es que un cracker podría cargar un script en tu sitio, mediante un componente vulnerable, y acceder desde la web comprometiendolo. La tercera razón es que un atacante emprendedor podría potencialmente utilizar los nombres y tamaños de los archivos para identificar una versión vulnerable de una extensión instalada en tu sitio y lanzar un ataque contra este. Aparentemente, poniendo los archivos index.html en su lugar, no obtienen listado de archivos así que estamos protegidos y es por eso que se le haya apodado «función de seguridad», ¿cierto?
Pues esto es absolutamente falso!
Quien piense así, está pensando en seguridad mediante oscuridad (obscurity) que, como todos deberíamos conocer a estas alturas, no es seguro en absoluto. Veamos por qué.
Por qué los ficheros index.html no proporcionan seguridad
En primer lugar, debemos tener en cuenta cómo funciona un cracker potencial. Hay dos clases de crackers: los niñatos script y los crackers de verdad. La primera clase de crackers (aunque están muy lejos de llamarse así) simplemente prueban cualquier vulnerabilidad que saben de tu sitio, sin importar si aplica a este o no. Te reírias al ver todos los intentos de ataque en mis logs que no tienen nada que ver con mi sitio web: ataques contra Joomla 1.0, versiones antiguas de virtuemart, incluso ataques contra IIS. Nada de esto está instalado siquiera en mi sitio! Ellos simplemente atacan al azar con la esperanza de toparse con un objetivo. En este caso, la existencia del archivo index.html es completamente irrelevante para su ataque.
La otra clase de crackers, los crackers de verdad, no se basarán en listado de directorios. Pongamos que quieren saber si tu sitio web está haciendo uso de Joomla!. Como ya sabrás, hay un directorio includes/js en tu sitio, con un archivo index.html, no obstante, también hay un archivo joomla.javascript.js. ¿Ya lo has adivinado, verdad? Exactamente, el cracker intentará acceder a la dirección http://ejemplo.com/includes/js/joomla.javascript.js. Si el archivo está allí, el sitio está funcionando con Joomla!, si no, bueno.. pues no es Joomla!. Mediante un proceso similar de análisis de archivos estáticos (que index.html no protege) un cracker puede averiguar la versión del CMS que estás utilizando e incluso la versión de las extensiones instaladas.
Finalmente, la presencia de index.html no bloquea el acceso a los ficheros alojados en tu sitio. Si un cracker consigue reventar una extensión para subir un archivo PHP arbitrario (normalmente un script de hackeo) en tu sitio, logrará acceder a él a toda costa.
Por lo tanto, la presencia – o inexistencia completa – de index.html no tiene ningún efecto en la seguridad de tu sitio.
Therefore the presence –or complete lack– of index.html files has no effect on your site’s security whatsoever.
¿ Hay algún problema por tener los ficheros index.html ?
Por supuesto, no solo porque no proveen seguridad, sino porque proporcionan una falsa sensación de seguridad pero que finalmente terminan disminuyendo la seguridad de nuestro sitio y el sitio, proveyendo un mal servicio a nuestros usuarios. Por no hablar cómo puede matar una extensión antes incluso de que se haga popular. ¿Suena como un grito lejano? Sigue leyendo y llora a gusto..
Instalación
Durante la instalación de un componente complejo, como Akeeba Subscriptions de Akeeba Backup, acabamos teniendo cientos de archivos inútiles que ocupan el 15% de los ficheros incluidos en el archivo. Recuerda que en hosts compartidos que requieren el modo FTP para la instalación, tendremos que extraerlos al directorio tmp primeramente (que lleva mucho tiempo de por sí), para luego transferirlos al lugar adecuado. La cantidad de tiempo necesario para instalar una extensión es proporcional al número de archivos, no su tamaño total, debido a la manera inefciente en que trabaja el protocolo FTP.
Como resultado, la gente comienza con páginas en blanco / páginas de 500 Internal Server Error al instalar nuestros componentes debido a los tiempos de espera. Éstos nunca se quejarán al JED por la regla index.html. Ellos siempre se terminarán quejando de nosotros, los desarrolladores, poniéndo el grito en el cielo y llamándonos idiotas incompetentes que deberían ponerse a coser en vez de seguir escribiendo software.
Este es el hecho: incluso conociendo el problema, no podemos solucionarlo porque JED no nos lo permite. En otras palabras , estamos jodidos.
Límite de Inodos (cantidad de ficheros)
La mayoría de los servidores compartidos tienen un limite de inodo. ej: activamente limitan el número de ficheros alojados permitidos en el servidor. Proliferando la inclusidón de ficheros inútiles estamos activamente forzando a Joomla a inflar artificialmente el número de ficheros «necesarios» para su operación, alcanzando el límite del inodo. Eliminando los index.html podemos llegar a liberar un 20% de número de ficheros, ofreciendo un buen servicio a nuestros clientes. Así que, aunque conocemos el problema, sabemos que es anti-funcional (limite artificial que no tiene otro propósito de existencia que molestar a los usuarios legítimos), aún así, no se nos permite solucionarlo!
Demasiado revelador
Los ficheros index.html terminan siendo muy reveladores. No sirven una página en lbanco. Sirven una página HTML que tiene un cuerpo vacío. Eso está muy lejos de su intención, supuestamente, como medida de seguridad. Cualquier atacante potencial con medio cerebro verá el código y se dará cuenta de que hay algo ahí. Si hay algo ahí, significa que el directorio EXISTE (de lo contrario, obtendría un «error 404 – No Encontrado») Por lo tanto, la existencia del fichero index.html sirve para confirmar que el directorio existe -un hecho que se conocería incluso sin el index.html- al existir la extensión, puede ser un objetivo potencial para su explotación.
En castellano plano: servir contenido, cualquier contenido, al acceder a un directorio revela que el directorio está ahí. Tendríamos que devolver un error 404 o 403 si lo que intentas es confundir lo máximo posible a los crackers potenciales.
Daño irreparable
Aunque todo esto pueda sonar duro, los ficheros index.html puede causar un daño irreparable a la reputación del autor de una extensión y matar el software antes incluso de llegar a la versión 1.0. Esta es la historia sobre Akeeba Subscriptions y cómo siguiendo las reglas del JED frustró los esfuerzos de su autor de crear el primer y único sistema para Joomla!.
Entonces, ¿hay alguna alternativa válidad a los index.html?
La única solución viable para detener estos ataques es el uso de ficheros .htaccess para limitar el acceso a ficheros y directorios arbitrarios. El fichero debe tener las siguientes lineas:
########## Begin - No directory listings ## Note: +FollowSymlinks may cause problems and you might have to remove it IndexIgnore * Options +FollowSymLinks All -Indexes ########## End - No directory listings
En servidores IIS hay una solución parecida, en forma de ficheros web.config (el equivalente IIS del .htaccess). De hecho, uno puede convertir automatícamente un .htaccess a un fichero web.config.
