Imagina la siguiente situación …
Cada mes publicas los resultados financieros o de márketing de tu empresa, y para eso lanzas una entrada en el blog corporativo en el que muestras el PDF con todos los datos de la compañía del periodo en cuestión.
Pues bien, un visitante curioso o malintencionado podría adelantársete y disponer de esos datos antes de que tu quieras sacarlos a la luz.
¿Cómo?, pues en realidad es sencillo, y debido a un error de WordPress en la gestión de adjuntos.
Me explico …
Cuando creas una entrada nueva, mientras no la publiques, puedes dejarla en borrador, pendiente de revisión o programada, y cualquier administrador o editor visualizarla previamente mediante la URL temporal o incluso la permanente, no así cualquier visitante o usuario sin los permisos adecuados, que obtendrá un error aunque conozca la URL.
Digamos, por ejemplo, que alguien vigila exhaustivamente tus publicaciones, pues aunque supiera los IDs de tus últimas entrada e hiciera pruebas al azar, al teclear algo cómo http://ayudawordpress.com/?p=73876&preview=true no tendría permisos suficientes para ver nada.
Pero no pasa lo mismo con los medios que hayas subido a WordPress, estén o no adjuntos a una entrada pues sus URLs son siempre accesibles.
De este modo, si siempre subes, digamos, los resultados financieros con una estructura de nombre de fichero similar, del tipo informe_finanzas_2013-08.pdf, tendría relativamente poco trabajo encontrarlo y visualizarlo si lo subiste antes de publicarlo, algo por lo demás bastante habitual, aunque solo sean horas.
Solo tendría que adivinar la URL completa de carga del archivo, que si te sigue habitualmente no le costará adivinar, del tipo http://tuweb.es/wp-content/uploads/2008/08/informe_finanzas_2013-08.pdf
Esto, en situaciones de mercado sensibles, puede ser un grave problema de cara a tus inversores o competidores. ¿Lo vas pillando?
Pero es aún más grave, pues de hecho es todavía más fácil adivinar la URL de un adjunto, pues no necesitarías siquiera saber la carpeta donde está alojado, ni siquiera el nombre de archivo, sino que solo necesitas “adivinar” el ID de adjunto, y eso es solo prueba y error.
Por ejemplo, el siguiente archivo no está asociado a ninguna entrada, o sea, no está publicado, pero sin embargo, y al contrario que con las entradas, si puedes verlo aunque no tengas permisos de usuario: http://ayudawordpress.com/?attachment_id=70246.
Creo que ya debes ir comprendiendo que si que es un fallo de seguridad en el modo en que WordPress gestiona la privacidad de los archivos adjuntos ¿lo ves?
Espero pronto se modifique la manera en que se gestionan las URLs de los adjuntos en WordPress, porque esto es un fallo tonto que, en según qué situaciones puede ser un agujero de seguridad que provoque pérdida de datos, en algunos casos importante. La solución podría pasar porque solo fueran accesibles los adjuntos cuando estén asociados a una entrada ya publicada, no antes, por ejemplo.
¿Soluciones?
Pues hay alguna. Por ejemplo, podrías subir manualmente la información sensible a una carpeta distinta de la habitual de WordPress y luego añadir una regla al fichero .htaccess para que ningún usuario no registrado pueda ver los archivos ahí subidos, pero es algo radical.
Por si te sirve este sería un ejemplo de .htaccess estándar con las líneas en cuestión (5, 6 y 7) protegiendo la carpeta “privados“, situada dentro de tu carpeta “uploads“, de manera que solo puedan ver los archivos los usuarios registrados:
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_URI} ^.*uploads/privados/.* RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in.*$ [NC] RewriteRule . /wp-login.php?redirect_to=%{REQUEST_URI} [R,L] RewriteRule . /index.php [R,L] RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress Pero ya te digo que es un apaño algo bestia y poco práctico.
Un modo menos radical y controlado de ofrecer ciertos adjuntos de un modo más racional sería utilizar un plugin que gestione descargas de archivos, cómo WP download manager, WP filebase o Easy digital downloads.
De este modo la información sensible solo la ofrecerás mediante descargas gestionadas con el plugin, pues además este tipo de plugins suelen ofrecer opciones para que ciertos archivos solo puedan ser descargados con contraseña o solo por usuarios registrados, lo que te ofrece más posibilidades.
Pero vaya, que son soluciones temporales a un problema existente. Si sabes de alguna solución más nos la cuentas ¿vale?
Ya va quedando menos, y hoy se ha liberado la versión “release candidate” 2 de WordPress 3.6, que parece que se confirma que la semana que viene estará lista en su versión final.
