Paso a paso26 de octubre de 20265 min de lectura

¿Tu web antigua es segura? Compruébalo así antes de modernizarla

Una empresa pidió poner al día una web que llevaba diez años funcionando y, antes de tocar nada, encontramos un panel abierto a cualquiera y miles de pedidos descargables sin contraseña. Lo que comprobamos, y por qué lo probamos todo en una copia antes de cambiar nada en real.

Pol

Fundador de AutoBoost

Seguridad de tu webModernizar software
¿Tu web antigua es segura? Compruébalo así antes de modernizarla

Si tu web lleva años funcionando "sin que nadie la toque", esa frase no significa que esté segura: solo significa que todavía no la ha mirado nadie con intención de entrar. Antes de cambiar una línea de una web antigua, hay tres cosas muy concretas que se pueden comprobar en una tarde, y un último paso que decide si el cambio sale bien o te deja sin poder entrar a tu propio negocio.

El caso: una web de diez años con la puerta de atrás abierta

Una empresa nos pidió modernizar su web, que llevaba funcionando desde hacía una década sobre una versión de su lenguaje de programación tan antigua que ya no recibe ningún parche de seguridad. Antes de construir nada nuevo, revisamos lo que ya había, por una razón simple: no tiene sentido poner una fachada nueva sobre una casa con las ventanas rotas.

Lo que encontramos no era una web lenta ni fea. Era una web con tres agujeros abiertos desde hacía años, sin que nadie lo hubiera notado:

  • Un panel de administración al que se podía entrar sin usuario ni contraseña. Dentro había datos bancarios y médicos de clientes.
  • Un formulario público por el que se le podía colar código a la web, en vez de limitarse a recibir lo que el cliente escribe.
  • Los PDF de casi todos los pedidos del histórico, descargables por cualquiera que adivinara el número de pedido. No hacía falta ni usuario ni sesión: solo cambiar un número en la dirección.

El número que más pesó fue este: cerca de 43.000 pedidos del histórico tenían su PDF accesible así, sin ninguna comprobación de quién lo pedía.

¿Cómo se sabe si tu web tiene el mismo problema?

No hace falta ser programador para hacerse estas tres preguntas sobre tu propia web, sea quien sea quien la mantenga hoy:

¿Quién puede entrar al panel de administración, y cómo? Si la dirección del panel se puede adivinar (algo tan simple como añadir /admin a tu propia web) y entrar no exige nada más que una contraseña que lleva años sin cambiarse, o peor, ninguna, cualquiera que la encuentre está dentro. Pide que alguien lo intente desde fuera, sin dar por hecho que "nadie la conoce".

¿Qué pasa si alguien escribe algo raro en tus formularios? Un formulario de contacto o de pedido debería tratar siempre lo que escribe quien lo rellena como texto, nunca como una instrucción. Cuando no es así, ese formulario se convierte en una puerta para meterle a la web cosas que no debería poder hacer nadie de fuera.

¿Tus documentos (pedidos, facturas, albaranes) llevan algo más que un número de serie en la dirección? Si la dirección de un PDF de tu propia web es previsible, "pedido 4821" seguido de "pedido 4822", y no comprueba quién lo está pidiendo, cualquiera con paciencia puede recorrerlos todos, uno a uno, sin que tu web se entere de que algo raro está pasando.

Si a alguna de las tres le contestas "no lo sé", esa es la respuesta: nadie lo ha comprobado todavía, y "funciona bien" no es lo mismo que "es segura". Son dos cosas distintas que se parecen mucho hasta el día en que dejan de parecerlo.

¿Qué se hace primero cuando aparece esto?

En este caso, antes de construir nada nuevo cerramos lo más urgente directamente en la web real: el panel quedó protegido, el formulario dejó de aceptar código y los PDF empezaron a comprobar quién los pedía. Eso no espera a ningún proyecto grande: un agujero abierto se cierra en cuanto se encuentra, no cuando toque.

¿Por qué no basta con arreglarlo y seguir adelante?

Porque el siguiente paso, poner al día el motor que hace funcionar la web entera, es un cambio que toca todo a la vez, no una pieza suelta. Una web que lleva diez años sin actualizarse puede depender de un detalle muy concreto y muy antiguo que nadie recuerda que está ahí, y ese tipo de cambio es precisamente el que puede romper algo sin avisar.

Por eso ese cambio grande no se hizo directamente sobre la web real: se probó primero entero sobre una copia exacta. Y ahí aparecieron dos fallos que, hechos en real a la primera, habrían dejado a la empresa sin poder entrar a su propio panel ni generar un solo PDF nuevo desde el primer minuto. Se corrigieron sobre la copia, sin que nadie fuera de la empresa llegara a notar nada, y solo entonces se aplicó el cambio de verdad.

La regla de decisión

Si vas a tocar algo que lleva mucho tiempo sin tocarse y que todo tu negocio usa a la vez, pruébalo primero sobre una copia exacta. Nunca directamente en real. Da igual que sea una web, el programa que lleva tus pedidos o el que lleva tu contabilidad: cuanto más tiempo lleva algo "funcionando tranquilo", más probable es que dependa de un detalle que nadie ha vuelto a mirar, y ese detalle es el que se rompe cuando por fin lo tocas. Probarlo antes sobre una copia es lo que convierte un fallo grave, descubierto el día del cambio, en una corrección tranquila, descubierta una semana antes con tiempo de sobra.

Vimos algo parecido, con otra forma, en un grupo de farmacias cuya plataforma llevaba meses con un dato roto que nadie había mirado de cerca: puedes leer ese caso aquí. La lección se repite: lo que "lleva tiempo funcionando sin que nadie se queje" no es garantía de nada, es solo la ausencia de alguien que haya mirado con atención.

Puedes ver cómo encajamos este tipo de trabajo, auditar antes de construir, en negocios de distintos sectores en nuestros servicios. Si quieres que revisemos qué tiene tu web o tu software por dentro antes de que lo encuentre otra persona, escríbenos.

Compartir artículo
Web antigua: cómo saber si tiene un fallo de seguridad