Me temo que voy otra vez a aburrirte hablando sobre el caché de contenidos de Gesbit, recientemente disponible, como seguramente sepas. Hace poco que tratamos de este asunto en esta bitácora, e incluso le he dedicado varias entradas, la última: Disponible el caché de contenidos. El caso es que me he topado con lo que pudiera parecer un problema, o al menos una cierta vulnerabilidad.

Intentaré explicar esto a continuación, a ver si también, de este modo, y puesto que en esta bitácora faltan otros puntos de vista en forma de comentarios (los tuyos, por ejemplo), como he dicho ya más de una vez, escribiré por ver si yo también puedo poner en claro algunas de las cosas que tengo dando vueltas en la cabeza. Así es, ni siquiera yo tengo claro que lo notado tenga alguna relevancia.

Resulta que el sistema de caché hace uso de las URLs de las bitácoras para saber, por decirlo así, si dicha URL está ya "cacheada" o no lo está. Ahora bien, siendo esto así, como lo es, un usuario malintencionado podría solicitar una URL como esta, por ejemplo:

http://www.unabitacora.com/?nocache=1

Como puedes ver, la URL en cuestión incluye en este caso una variable, que Gesbit no tendrá en cuenta, pero, que, en todo caso forma parte de la URL. De este modo, el sistema de caché comprobaría si dicha URL ha sido "cacheada", y, si no lo ha sido, "dejará" que Gesbit genere dinámicamente la página correspondiente. Como acaso ya imagines, la página generada formaría parte entonces del caché de Gesbit (si está en uso) y se serviría en otras ocasiones para la misma URL.

Ahora bien, es fácil suponer que un usuario malintencionado podría usar este tipo de URLs para "forzar" la generación dinámica de páginas, para "saltarse" el sistema de caché, y, en un momento dado, para llevar a cabo un "ataque" de "denegación de servicio" contra el servidor que albergue la bitácora en cuestión. El sistema de caché reconocería estas URLs como distintas, porque, realmente, lo son:

http://www.unabitacora.com/?nocache=2
http://www.unabitacora.com/?nocache=3
http://www.unabitacora.com/?nocache=4
http://www.unabitacora.com/?nocache=N

He comprobado que este "problema" sucede no sólo en el sistema de caché implementado en Gesbit, sino en otros sistemas similares, y es que, como digo, siempre que estos se basen en la URL para conformar un "identificador" para las páginas que se sirven, será posible utilizar la técnica mostrada para "saltarse" el sistema de caché de contenido, para forzar la generación de páginas dinámicas.

He consultado privadamente con el autor de uno de estos "sistemas de caché" y, según él no se trata de un fallo, porque, lo mismo que ocurre con estas URLs ocurriría con cualquier otra que incluyera variables. Creo que entiendo lo que quiere decir, y creo sinceramente que este hombre sabe más que yo de estos menesteres, pero, todavía no me quedo del todo tranquilo.

Y es que el asunto, si es que representa o puede representar un problema, no tiene fácil solución, a lo que se ve. Lo segundo que se le ocurre a uno (por no aburrir no diré lo primero que se le ocurre) es conformar una lista de variables "válidas", de modo que no se tengan en cuenta el resto de variables en las URLs. Esta, que podría parecer una solución ideal, dista mucho de serlo, en el caso de Gesbit, al menos.

Es verdad que sería posible crear la tal lista de variables "válidas", pero, en el supuesto caso de que los plugins o temas de Gesbit necesitasen usar variables, el asunto no pintaría nada bien. Esto es porque el sistema de caché de contenidos en Gesbit funciona sin necesidad de hacer ni una sola consulta a la base de datos de Gesbit.

El sistema de caché se pone en marcha antes incluso de que el sistema de plugins lo haga, porque este requiere ya de una consulta a la base de datos: para obtener, justamente, las opciones de Gesbit, entre las que se encuentra la que determina qué plugins están "activos", cuál es el tema "actual", etc. Entonces, aquí, surge un dilema.

Si concluimos que sería bien crear la tal lista de variables "válidas" para solucionar el posible "problema" (luego se verá porqué entrecomillo) en el caché de contenidos, entonces será necesario hacer al menos una consulta a la base de datos de Gesbit, antes de que el sistema de caché se ponga en marcha. ¡Y esto es precisamente lo que se pretende evitar!

Por otro lado, y, queriendo entender la opinión del compañero, que, sin duda, sabe más que yo de estos menesteres, quiero pensar que soy demasiado imaginativo... y en realidad el susomentado "problema" con el caché de contenidos en realidad no es tal. Es cierto que el usuario que lo sepa puede "saltarse" el caché y "forzar" la generación de una página dinámica. A esto Gesbit no le preocupa mucho, porque, genera páginas con soltura sin problemas.

Pero, cuando hablo de un posible problema, ¿a qué me estoy refiriendo exactamente? ¿Qué quiero decir? Si lo que pienso, como es la verdad, es que alguien podría realizar una ataque de denegación de servicio a una bitácora, ¿para qué va a tener necesidad nadie de saltarse el caché de contenidos, si puede pedir, directamente, otra página de la bitácora, que, precisamente, no pasa por el caché de contenidos?

Hablo, por ejemplo, de la página que da entrada al panel de administración de Gesbit, por ejemplo. ¡Pero es que valdría cualquier otro archivo, cualquier otra petición, para hacer lo que se pretende! La hoja de estilo de un tema, por ejemplo, alguien puede "pedirla" y "pedirla" al servidor hasta dejarle KO, si es que esto es posible. Y aquí es cuando caigo del guindo.

Tal vez sea por algo alrededor de esto último que digo, por lo que esta persona con la que he consultado, no considera un problema este asunto: si alguien quiere hacer un ataque de denegación de servicio, no necesita saltarse el caché de contenidos... utilizará cualquier otra URL para hacer lo que pretende. Y, por otro lado, ahí acaba todo, es decir, no hay otro problema que ese con el caché de contenidos.

En fin. Que voy a publicar esta entrada, más que nada, porque queda demostrado, una vez más, que escribir sobre algo ayuda a encontrar una posible solución a lo que sea. En este caso no he encontrado una solución, pero, me he quedado más tranquilo, porque, he llegado a la conclusión, creo, acertada. Y el problema que veía al principio, parece que, en realidad, no es tal.

Pues mejor, ¿no te parece a ti también así?