Bypass

Un bypass no rompe el control: lo rodea. La diferencia importa porque cambia dónde hay que buscarlo. Si un atacante revienta una contraseña, el control de autenticación ha hecho su trabajo y ha perdido; si encuentra una ruta que no pasa por el formulario de acceso, el control sigue intacto y no llega a enterarse de nada.

Por eso los bypass casi siempre nacen de un supuesto y no de una vulnerabilidad del producto. El control da por hecho que todas las peticiones entran por la puerta principal, que el navegador respeta lo que el servidor le manda, que el identificador que viaja en la URL es el del usuario que ha iniciado sesión. Cada uno de esos supuestos es correcto casi siempre, y un bypass es el caso en el que no lo es.

La consecuencia práctica es que un bypass rara vez lo encuentra un escáner. Un escáner comprueba que el control existe y responde; el bypass vive en la ruta que el escáner no recorre.

Bypass de autenticación. Un endpoint de API que nadie protegió porque no aparece en el menú, un flujo de recuperación de contraseña que devuelve la sesión sin pedir el segundo factor, una cookie de sesión que el servidor acepta sin validar su firma. El segundo factor es donde más se ve: se implanta en el inicio de sesión normal y se olvida en la recuperación, en el acceso federado o en la aplicación móvil.

Bypass de filtrado. Un WAF y un firewall deciden a partir de lo que ven, y lo que ven depende de cómo interpreten el tráfico. Codificar la carga de otra manera, partirla en trozos que se reensamblan después o mandarla dentro de un protocolo permitido son formas clásicas de que la regla no llegue a dispararse. El filtro no falla: está mirando otra cosa.

Bypass de control de acceso. Cambiar un identificador en la URL, llamar directamente a una función administrativa que la interfaz solo enseña a los administradores, o pedir el mismo recurso por una ruta alternativa. Es el terreno de IDOR y de la autorización rota, y es el bypass más frecuente en aplicaciones web porque la comprobación se escribe una vez por pantalla y no una vez por dato.

Un bypass logrado produce tráfico legítimo. La petición que salta el control llega bien formada, con una sesión válida y una respuesta 200, así que en el registro no se distingue de la de un usuario normal. Lo que delata un bypass no es el error: es la secuencia. Un usuario que accede a un recurso que nunca pidió, una sesión creada sin que conste el paso por el segundo factor, una serie de identificadores consultados en orden.

De ahí que la detección útil sea la que mira relaciones y no eventos sueltos. Registrar la decisión de autorización, y no solo el acceso, es lo que convierte un bypass en algo visible: si el sistema anota quién pidió qué y con qué permiso se le concedió, el salto deja rastro. Si solo anota que hubo un 200, no lo deja.

La prevención que de verdad sirve va antes que todo eso. Mantener el software al día retira los bypass ya conocidos y publicados; los que quedan son los del diseño propio, y esos solo aparecen si alguien los prueba.

En un test de intrusión sobre una aplicación web el bypass no se busca como una categoría aparte. Se busca repitiendo cada operación privilegiada desde una cuenta que no debería poder hacerla, y después sin ninguna cuenta. Esa doble pasada es la que encuentra la ruta que la interfaz no enseña.

Las preguntas concretas son siempre las mismas. ¿El permiso se comprueba en el servidor o solo se oculta el botón? ¿El segundo factor se exige en todos los caminos de entrada o solo en el principal? ¿Qué ocurre si la petición llega sin la cabecera que el filtro espera? ¿Y si llega dos veces a la vez?

El hallazgo se redacta contra el punto donde falta la comprobación, no contra la petición que lo demostró. Un bypass arreglado bloqueando la carga concreta que lo probó vuelve con otra codificación la semana siguiente.