Servidores de staging y de pruebas olvidados: la parte que nadie vigila

Un servidor de staging o de pruebas olvidado es una copia de su sitio web o aplicación que se montó para el desarrollo y luego se quedó funcionando en internet. Suele estar en un nombre como staging.yourcompany.com, dev.yourcompany.com o test2.yourcompany.com, ya nadie lo revisa y a menudo ejecuta código más antiguo con una configuración más débil que producción.

Estos servidores importan porque forman parte de la presencia de su empresa en internet, aunque nadie los trate así. No reciben las mismas actualizaciones, accesos ni monitorización que el sitio principal, y sin embargo con frecuencia comparten las mismas copias de la base de datos, claves de API y cuentas de administrador.

La buena noticia: son fáciles de encontrar y, una vez localizados, la solución suele ser sencilla. Este artículo muestra cómo buscarlos y qué hacer con cada uno.

Por qué se olvidan los servidores de staging

Un servidor de staging se crea por un buen motivo: probar una versión antes de que la vean los clientes. Luego la versión sale, el desarrollador pasa a otro proyecto o termina el contrato con la agencia, y el servidor sigue funcionando porque apagarlo nunca estuvo en la lista de tareas de nadie. Patrones habituales:

• Una copia completa de producción, con un volcado reciente de la base de datos, para que las pruebas parezcan realistas.
• El modo de depuración activado, que muestra trazas de error, valores de configuración o detalles del framework.
• Contraseñas de administrador predeterminadas o compartidas que eran "solo para pruebas".
• Versiones antiguas del CMS, de los plugins o de las librerías que producción ya ha actualizado.
• Sin HTTPS, o con un certificado que caducó hace meses.
• La indexación en buscadores nunca se bloqueó, así que el sitio de pruebas aparece junto al real.

Nada de esto es grave por sí solo. En conjunto, significa un host bajo su propio dominio que es más débil que todo lo que lo rodea.

Cómo se hacen visibles estos servidores

No hace falta publicar un enlace para que se encuentre un host de staging. 3 vías habituales:

1. Certificate Transparency. Cuando se emite un certificado de confianza pública para staging.yourcompany.com, el nombre queda escrito en registros abiertos (el protocolo se describe en el RFC 9162). Cualquiera puede consultar esos registros, como se explica en registros de Certificate Transparency explicados.
2. Registros DNS. Un registro que sigue apuntando al servidor lo hace accesible por su nombre, y los nombres fáciles de adivinar como dev, test y beta son los primeros que se prueban.
3. Buscadores y archivos web. Un sitio de pruebas sin reglas de indexación puede aparecer en los resultados de búsqueda, y las páginas antiguas permanecen en los archivos web.

Cómo encontrar sus propios servidores olvidados

Empiece por los nombres y luego revise cada uno.

1. Busque %.yourcompany.com en crt.sh y reúna todos los nombres de host.
2. Repase su zona DNS en busca de nombres como dev, stage, staging, test, uat, beta, old, demo, preview.
3. Resuelva cada uno y compruebe la respuesta:

dig +short staging.yourcompany.com
curl -sI https://staging.yourcompany.com

1. Abra cada host en un navegador y pregúntese: ¿muestra datos reales de clientes, un formulario de inicio de sesión, una página de depuración, una página predeterminada del servidor o un error de una plataforma de alojamiento?
2. Busque archivos que nunca deberían servirse. La guía de pruebas de OWASP lo trata en WSTG-CONF-04 y señala que las copias de seguridad tienden a servirse como texto plano en lugar de ejecutarse. Nuestro artículo sobre archivos .env, .git y copias de seguridad expuestos enumera los nombres habituales.

Si un nombre apunta a una plataforma de alojamiento que muestra una página de "no such app" o "bucket not found", trátelo como urgente: es el escenario clásico de la toma de subdominios.

Qué hacer con cada uno

Para cada host de staging o de pruebas, elija uno de estos 3 desenlaces.

Eliminarlo. Si nadie sabe decir quién es su responsable ni para qué sirve, apague el servidor y borre el registro DNS. Borre el registro después del servidor, no antes, y no deje nunca un CNAME apuntando a un servicio que ya no paga.

Restringirlo. Si el equipo todavía lo necesita, póngalo detrás de una autenticación o de una lista de IP permitidas. La autenticación HTTP Basic se añade rápido, pero MDN señala que debe usarse sobre HTTPS porque las credenciales solo van codificadas en base64. Una VPN o un proxy con control de identidad es una mejor opción a largo plazo.

Limpiarlo. El entorno de staging no debería contener datos reales de clientes. Use datos generados o enmascarados, claves de API separadas con permisos limitados y desactive la salida de depuración.

Mantener alejados a los buscadores es útil, pero no es una protección. Google documenta noindex como forma de excluir páginas de los resultados, mediante <meta name="robots" content="noindex"> o una cabecera X-Robots-Tag (Google Search Central). La página sigue siendo accesible para cualquiera que tenga la dirección.

X-Robots-Tag: noindex

Una lista de comprobación breve

• Cada host que no es de producción tiene un responsable con nombre y una fecha de fin.
• Ningún dato real de clientes en staging.
• Staging exige inicio de sesión o está detrás de una VPN.
• Modo de depuración desactivado, claves separadas, sin contraseñas de administrador compartidas.
• Certificado válido, o el host se elimina.
• Los registros DNS se borran cuando se elimina el servidor.
• La lista se revisa al terminar cada proyecto, no una vez al año.

Dónde encaja Datahorses

Datahorses vigila su empresa desde fuera cada día, incluidos los nombres de host nuevos bajo sus dominios, los subdominios y servidores de pruebas olvidados y los archivos expuestos en ellos. Cada hallazgo llega con los pasos exactos para su desarrollador, y no entramos en sus sistemas ni necesitamos ningún acceso. Consulte qué vigilamos y qué ocurre cuando encontramos algo.