¿Por qué los robots no te hacen caso? Échale la culpa a una lista de correos del año 1994.

En el campo de las aplicaciones web, se conocen por el término robots a los programas que se dedican a visitar las aplicaciones de cara a Internet, recopilando información sobre los contenidos y recursos disponibles, para indexarlos en grandes sistemas de bases de datos que luego son consultados por buscadores como Google o Bing ante las peticiones de búsqueda del usuario.

Estos programas son conocidos también por el nombre de Spider o Arañas Web ¿Qué nombre puede ser más apropiado para un programa que recorre las telarañas (web en inglés) de Internet?. También se le conoce por el término de web crawler, aunque estos no se limitan a solo a indexar contenidos de Internet, incluyen la realización de copias totales o parciales de los recursos de la web y son la base de servicios como Internet Archive.

En el año 2004 estaba estudiando en la Universidad de Camagüey (UC) y recuerdo al administrador del nodo comentarnos que el “Spider de Google” dejaba trazas cada 15 días de sus acciones tratando de indexar los contenidos del portal web de la UC. Puedo decir con certeza que esa fue la primera vez que escuché hablar del tema.

Quizás a muchos no les guste que un programa que responde a los intereses de tercero se encargue de husmear periódicamente hasta la página más olvidada de una aplicación web. Desde el inicio de la popularización de las aplicaciones web, se comenzó a identificar este problema y otros más. Los robots generaban un número de peticiones considerables a los antepasados de los servidores web, los cuales no estaban preparados para esa avalancha de peticiones automáticas. Hay que tener en cuenta que estos robots muchas veces indexaban repetidamente los mismos ficheros, indexaban contenidos temporales o incluso algunas peticiones generaban acciones colaterales (como por ejemplo en sistemas de encuestas).

Para tratar de solucionar este problema, fue creado el Estándar de Exclusión de Robots, el 30 de Julio de 1994 mediante el consenso de los participantes de la lista de correos robots-request@nexor.co.uk (en aquel tiempo una lista de correos era uno de los principales medio de comunicación en Internet, algo así como los servicios de Stack Overflow, Twitter y WordPress.com al mismo tiempo). Al inicio del documento especificaron:

It is not an official standard backed by a standards body, or owned by any commercial organisation. It is not enforced by anybody, and there no guarantee that all current and future robots will use it. Consider it a common facility the majority of robot authors offer the WWW community to protect WWW server against unwanted accesses by their robots.

Lo que traducido a la lengua de Cervantes sería:

Esto no es un estándar oficial respaldado por un cuerpo de estándares, o propiedad de alguna organización comercial. Esto no fuerza a nadie, y por tanto no garantiza que todos los actuales y futuros robots lo usen. Considere esto como una facilidad común que la mayoría de los autores de robots ofrecen a la comunidad WWW para proteger los servidores WWW contra accesos no deseados por sus robots.

Como puede apreciarse, esta es la explicación de porqué los robots actuales no respetan al pie de la letra todo lo indicado en el conocido archivo robots.txt.

Por este motivo, es necesario que los desarrolladores, en la actualidad, usen el archivo robots.txt con el único propósito de “sugerirle” a un robot cuales son los enlaces y contenidos “públicos” que el desarrollador tiene interés en que sean indexados por terceros. Cualquier otro uso o propósito pueden constituir una vulnerabilidad de la aplicación web. Algunos usos inadecuados y malas configuraciones del archivo robots.txt pueden ser:

• Indicar al robot que no debe acceder a un determinado recurso, pero no se establecen medidas de protección para evitar su acceso, un robot puede ignorar esta directiva y acceder efectivamente al recurso. Desconfié por tanto de los robots y establezca los permisos adecuados.
• Indicar al robot que no debe acceder a un determinado recurso y dicho recurso tiene medidas de protección para evitar su acceso. Esto puede parecer una contradicción con el punto 1, sin embargo, si hay un recurso que tiene medidas de protección para impedir su acceso no autorizado y se refleja en el archivo robots.txt, estamos informando a un atacante, de manera muy sencilla de cuál es la estructura y contenidos de nuestra aplicación web. Mi sugerencia es eliminar cualquier referencia a un recurso cuyo acceso no autorizado esté protegido, pues de otro modo estamos brindando información sensible a potenciales atacantes. Ejemplos de estos hay mucho, desde archivos config.php hasta paneles de administración.
• Dejar la configuración por defecto del archivo robots.txt que generan los CMS, en todos los casos los ficheros robots.txt están poblados de referencia a archivos de configuración y con información sensibles y los desarrolladores consideran que esa configuración es la adecuada cuando en realidad debe tomarse como una plantilla y no como el resultado final.

A modo de conclusión, te recomiendo que uses el robots.txt para que impidas el acceso a las rutas públicas si tu aplicación web lo requiere, de otro modo, si se trata de un panel de administración al cual se accede mediante autenticación previa, o son rutas restringidas por defecto en el sistema, no te recomiendo que lo pongas en el archivo robots.txt pues estarías brindando información útil a un atacante “por gusto”.

Espero que te haya gustado el post, yo por mi parte me he divertido bastante escribiéndolo.

S4lud0s y h4st4 el próx1m0 p0st!!!

P.D: Puedes encontrar más información en:

Buscando en robots.txt lo que está prohibido encontrar

Hacking driven by robotst.xt

Incomprensibles incomprendidos robots

Modelado de amenazas en el contexto de la indexación de páginas y propuesta de inclusión en el ENS