Auth Bajo Ataque Detectando Fallos de Auth de JavaScript en Producción Rápidamente

Hola, soy Viola. Soy ingeniera de software senior e ingeniera de confiabilidad del sitio en Londres. Trabajo mucho con sistemas de autenticación e incidentes. Así que hoy voy a presentar Auth Under Attack. Aquí es donde vamos a detectar fallos de autenticación de JavaScript en producción muy rápido. Quiero comenzar con una frase que todo ingeniero ha escuchado en algún momento. El registro se ha roto. Suena pequeño, suena contenido, pero también suena como una forma, un punto final, un lugar para mirar. Las producciones rara vez son tan amables. Los fallos de autenticación llegan cuando los usuarios rebotan entre páginas, sesiones que continúan después de que la confianza ha cambiado, y la lógica de actualización que sigue haciendo la misma pregunta y permisos que sobrevivieron más tiempo del que deberían.

Hoy, voy a recorrer la autenticación como una cadena de confianza en producción, cómo se rompe, cómo diagnosticarla rápidamente y cómo hacer que la misma clase de fallo sea más difícil de reintroducir en tu sistema. Y lo primero que quiero hacer es separar la puerta visible del sistema real detrás de ella. La página de inicio de sesión es la puerta. Detrás de ella, el sistema está tomando una cadena de decisiones. Nunca es solo una acción la que causa el error. ¿Quién proporcionó su identidad? ¿Cuánto tiempo sobrevivió esa prueba? ¿Qué sucede cuando cambia la confianza? Y cuándo se permite al usuario hacer y qué?

En la vida real, entendemos esto claramente. Y si alguien pierde una tarjeta de llave de hotel, el hotel no admira el plástico y espera lo mejor. La tarjeta antigua se revoca inmediatamente y se emite una nueva. Y así es como se actualizan las puertas. Los sistemas web necesitan la misma disciplina. Una cookie existente en el navegador, un rol antiguo en un token, o un botón oculto en la interfaz de usuario no completa la historia de confianza. La pregunta útil es, ¿qué parte de la cadena todavía cree en algo que ya no es cierto? Ahí es donde generalmente comienzan los incidentes de autenticación en producción.

Dos partes del sistema llevan diferentes historias sobre la confianza. La idea central de esta charla es que los fallos de autenticación son a menudo desacuerdos en el estado de confianza. El navegador puede seguir llevando una versión antigua de confianza donde la API ya la ha rechazado. El enrutador se queda tratando de navegar entre dos historias conflictivas y un token puede seguir llevando la autoridad de ayer mientras que la tienda de permisos ya sabe que el usuario ha sido degradado. Por eso estos incidentes parecen malditos. Cada capa puede usar y parecer razonable en aislamiento mientras que todo el sistema está mal.

Y en ese punto, dejaría de dividir el incidente por el límite del equipo, y comenzaría a rastrear el límite de confianza. Quién posee la verdad, y quién está actuando sobre la información obsoleta. Así que para mantener esa investigación precisa, uso cuatro verbos. Los cuatro verbos son probar, recordar, delegar, e imponer. La autenticación prueba quién es el sujeto. La gestión de sesiones recuerda esa prueba a lo largo del tiempo. La delegación permite que un cliente u otro sistema actúe con autoridad limitada. Así que la autorización impone lo que está permitido.

Cuando esos verbos se mezclan, el diagnóstico se vuelve confuso. Un inicio de sesión exitoso prueba la identidad en un momento dado. Un token lleva afirmaciones para un contexto limitado. Un botón visible pertenece a la presentación. Y la acción protegida aún necesita imposición del lado del servidor. Y sí, los JWTs pueden parecer muy oficiales, pero no son verdades eternas talladas en una montaña. Son declaraciones firmadas con alcance, audiencia y expiración. Así que mantener estos verbos separados mantiene el incidente legible.

Así que ahora coloquemos esos verbos dentro de la afirmación de producción real. En una aplicación moderna de JavaScript, la autenticación viaja a través del estado del navegador, cookies, guardias de ruta, proveedores de identidad, algún backend o backend para frontends, llamadas API, almacenes de sesión, verificaciones de permisos, y esta lista sigue y sigue. Pero a veces un borde, ya sabes, o una capa de caché que añade su propio toque de caos puede realmente aumentar el incidente. Así que los usuarios reportan el dolor visible. Están atrapados en el inicio de sesión o su panel sigue parpadeando y dice que estás conectado, pero luego los expulsa. Sabes, podría haber hecho eso ayer, dirías. Pero esto no es algo que el sistema debería estar realmente diciendo al usuario que haga. Así que esos reportes son síntomas valiosos. La bóveda puede decir, y la bóveda puede realmente mostrar el alcance de la cookie, manejo de actualización reclamaciones obsoletas, y revocar sesiones. Pero la parte interesante de esta investigación es que la brecha entre las capas. Así que una vez que ves la cadena, esa cadena desde el navegador hasta la observabilidad, las formas comunes de fallos se vuelven mucho más fáciles de reconocer.

Así que hay cuatro formas que miro primero. La primera es el bucle. El usuario es enviado de la aplicación al inicio de sesión, luego del inicio de sesión a la aplicación, luego de la aplicación al inicio de sesión nuevamente, una versión muy costosa de no, cuelga tú primero. La segunda es la sesión go cuando la confianza ha cambiado, pero el acceso antiguo sigue caminando como si nadie le hubiera dicho que la fiesta terminó. Y la tercera es la tormenta de actualización. Aquí es donde la lógica de recuperación sigue intentando recuperarse de su propia recuperación. Y la cuarta es el lago de permisos. Esta es nuestra antigua autoridad sobreviviendo a un cambio que debería haber reducido el acceso. Y estos son modos comunes de fallo de sistemas de autenticación distribuidos cuando la propiedad es muy poco clara.

Comencemos con el más ruidoso, el pasillo sin salida. Un bucle de redirección generalmente apunta a un estado de autenticación que no puede asentarse. El panel requiere un usuario autenticado, la página de inicio de sesión es algo que parece una sesión activa, el panel verifica contra ella, y la rechaza. El usuario es pasado de un lado a otro como un paquete que nadie quiere firmar por. Y yo rastrearía la máquina de estados aquí. ¿Puede la aplicación representar desconocido, no autenticado, o autenticado, expirado, prohibido, desconectado, o se requiere reautenticación? Lo siento, ¿puedes simplemente cortar esto, por favor? Lo siento, solo estoy hablando un poco de tonterías porque, sí, lo siento, mañanas.

Así que empezando desde aquí. ¿Puede la aplicación representar un estado desconocido, no autenticado, o autenticado, expirado, o prohibido, o cerrado sesión, y se requiere reautenticación? Cuando el modelo solo tiene verdadero y falso, la producción eventualmente inventa los estados faltantes, usualmente de la manera menos elegante posible. Y el siguiente fallo es más silencioso, pero es más peligroso.

Una sesión fantasma. Aparece cuando la confianza cambia, pero el acceso alternativo sigue moviéndose, así que el restablecimiento de contraseña es el ejemplo más claro de esto. El usuario cambia su contraseña, la interfaz celebra el éxito, y todos se sienten emocionalmente completos. Mientras tanto, otra sesión de navegador u otro dispositivo puede aún mantener autoridad válida. El restablecimiento de contraseña cambia el límite de confianza.

Y el restablecimiento de autenticación multifactorial, desactivación de cuenta, o actividad sospechosa, o incluso tasas de reducción, hacen lo mismo. Así que las sesiones existentes y los tokens de actualización necesitan una decisión explícita. Los flujos de recuperación sólidos actualizan toda la cadena de confianza, así que no solo la credencial intermedia. Así que los tokens de actualización son donde esto a menudo se vuelve bastante desordenado.

La lógica de actualización comienza con una buena intención. El token de acceso expira, la aplicación solicita uno nuevo, y el usuario evita iniciar sesión cada cinco minutos, ya sabes, esto es civilizado. Pero el peligro comienza cuando la actualización no tiene un único propietario o un presupuesto de reintentos y ningún estado de fallo único. Es entonces cuando la API puede devolver 401, el cliente actualiza, la actualización falla, y la solicitud original vuelve a intentarlo. Llega otro 401, comienza otra actualización. De repente, la aplicación está realizando un pequeño y perturbador ataque de denegación de servicio contra sí misma.

Así que la actualización extiende la confianza, por lo que necesita controles. Rotación, reubicación, límites de reintentos y un camino limpio hacia la reautenticación. El siguiente fallo es el que hace que las personas de seguridad dejen de sonreír. Fugas de permisos. Ocurren cuando la antigua autoridad sobrevive después de que la autoridad debería haber cambiado. Y un usuario era, por ejemplo, un administrador ayer. Hoy son un espectador. El cliente aún muestra el área de administración, el token aún lleva una reclamación antigua, y una respuesta en caché aún expone algo sensible. El cliente puede mejorar la experiencia y hacer que la interfaz de usuario sea más agradable, pero la acción protegida pertenece al servidor.

Y la API que sirve los datos o ejecuta la acción tiene que hacer cumplir el modelo de permisos actual. De lo contrario, la interfaz de usuario se convierte en teatro, y el servidor se convierte en un problema de escenario muy importante y costoso. Así que ahora conectemos estos modos de fallo en un incidente con forma de producción. Esto es lo que llamo el pequeño cambio que movió el límite. El incidente que me importa aquí comienza con un pequeño diff. Este es un extracto de PR, y alguien simplemente ajusta un guardia de ruta. Cambian el comportamiento de actualización, alguien más mueve un permiso, alguien más mueve una verificación de permisos porque la interfaz de usuario ya lo maneja.

Alguien más cambia el restablecimiento de contraseña y olvida las sesiones existentes. La pull request parece inofensiva porque el conteo de líneas es pequeño. La entrada de producción proviene de la decisión de confianza que cambió. Un límite de confianza se mide por lo que el cambio ahora permite y lo que preserva. Lo que elimina y lo que deja de aplicar. Así que, durante la investigación, preguntaría qué autoridad creó este cambio. ¿Qué preservamos? ¿Qué eliminamos? ¿Y tal vez dejamos atrás? En la versión rota, puedes ver que el sistema está en desacuerdo consigo mismo.

Así que, veamos esta demo rota. En este modo roto, enfócate en el desacuerdo más que en la UI. Esta aplicación demo ya ha sufrido bastante, estéticamente. Pero el cliente aún cree que el usuario es de confianza. Y el backend ha comenzado a rechazar esa confianza. El enrutador está reaccionando a información incompleta. Y el flujo de actualización está intentando recuperarse sin saber cuándo detenerse. Por eso este incidente consumió tiempo. El sistema realmente no sabe cuándo anunciar y si debería anunciar un invariante roto en un modelo educado.

Simplemente te da cadenas de redirección repetidas y aún una UI que contradice el estado. Los síntomas visibles son, bueno, son bastante desordenados porque la cadena de confianza es inconsistente. Así que, lo diagnosticamos como un incidente con evidencia y propiedad. Aquí es donde me pongo estricto con el diagnóstico. Quiero cuatro cosas. El síntoma, la evidencia, el invariante roto, y el propietario de la confianza. Utilizo el síntoma para entender el dolor del usuario. La evidencia para entender cuándo el sistema lo que el sistema realmente hizo. El invariante para definir lo que nunca debería haberse roto. Y el propietario para encontrar la capa responsable de restaurarlo. Para cada bucle directo, el estado de autenticación debe asentarse.

Para la sesión go, revocar confianza debe dejar de viajar a través de todas las sesiones o tokens de actualización. Para la tormenta de actualizaciones, el fallo debe alcanzar un estado terminal. Y para la fuga de permisos, los cambios de rol deben aplicarse del lado del servidor, no del lado del cliente. Una vez que ese invariante tiene un nombre, la solución deja de parecer un trabajo de adivinanza. Cuando realmente estamos en producción y el tiempo es esencial, queremos poder detectar esos fallos bastante rápido. Así que, los ingenieros más rápidos aquí no son los que adivinan más rápido. Son los que estrechan el sistema más rápido.

Y para poder estrechar el sistema más rápido, tienes que mapearlo antes de siquiera implementarlo. Así que, en esta versión fija de la demo, el mismo escenario se vuelve mucho menos dramático, que es exactamente lo que queremos, al menos en la introducción. Así que, en esta versión fija, estamos ejecutando el mismo escenario que alcanza una historia consistente. El servidor se convierte en el lugar donde se decide la confianza. La validez de la sesión se verifica allí. Los permisos se aplican donde se sirve la data. Y la actualización se maneja como una ruta de control, limitando el desperdicio en lugar de una negociación interminable.

Así que, el cliente comienza neutral. Pregunta al servidor. Alquila del estado confirmado. Y si la sesión es inválida, el usuario entonces pasa a la reautenticación limpia. Si el usuario ya no tiene este permiso, la API negará esta acción. Y no se actualizará. Si no se actualiza, el sistema deja de iluminar la realidad, y simplemente lanzará el error. El cambio importante aquí es la propiedad, porque la confianza en este tipo de sistema, ahora tendrá una fuente clara. Y después de que el incidente se solucione, la siguiente pregunta es, ¿cómo se mantiene esta clase de fallo fuera de producción la próxima vez?

Y parchear esto sería genial en producción. Serías un héroe. Pero proteger el entorno de tu sistema es mucho mejor. Las barandillas sirven todas al mismo propósito. Detienen la incertidumbre de convertirse en autoridad. Los estados de autenticación explícitos evitan que la aplicación trate lo desconocido como confiable. Y la actualización limitada evita que la recuperación se convierta en un bucle.

La versionado de sesiones te dará el servidor que tiene una forma limpia de terminar el acceso obsoleto después de algún tipo de reinicio, degradación o desactivación de cuenta. La autorización del sitio de servicio mantiene al cliente fuera del rol de autoridad final. La observabilidad te da la evidencia. 401s, 403s, picos de redirección, fallos de actualización, revocaciones de sesión y desajustes de permisos. Sin evidencia, la autenticación se convierte en sensaciones con cookies. Así que, algunas de esas barandillas pueden realmente vivir en pruebas y monitoreo. Algunas de ellas también pueden moverse a CI.

Así que, aquí es donde Groundpact encaja en la historia. Groundpact es una aplicación que he lanzado recientemente para crear una capa de gobernanza entre tus concesiones de autenticación. Lo uso aquí como la capa de prevención. El sistema verifica los invariantes de autenticación como contratos antes de que el cambio llegue a producción. Y en este ejemplo, señala que las APIs de administración ya no son aplicadas por el servidor. Así que, señala que el restablecimiento de contraseña ya no tiene el comportamiento de invalidación. Así que, no valida las sesiones existentes.

Así que, no valida las sesiones existentes. También señalará que el fallo de actualización ya no alcanza el estado terminal limpio. Y el punto es la visibilidad. Cuando presento mi pull request con cambios sobre quién puede acceder a una ruta, si las sesiones sobreviven al reinicio, o cómo se comporta la actualización, el cambio en el límite de confianza aparece antes de que se convierta en un incidente. Un error corregido es útil en producción, sin duda. Pero un invariante protegido de tu sistema de antemano es mucho mejor.

Y eso lleva a la doctrina final de que la autenticación debería convertirse, de hecho, en aburrida. Aburrido es bueno. Y este es el regalo que incluso puedes pedir en producción. Porque una buena autenticación se sentirá aburrida porque la responsabilidad será clara en este punto. No tendrás que seguir apagando incendios con cosas que ya puedes definir de antemano. Así que, el servidor lleva la verdad. Llevará la fuente de verdad más actualizada. Y el cliente llevará la experiencia.

La observabilidad llevará tu evidencia. Y tu pipeline de CI se convierte en el punto de control que evita que el incidente de ayer vuelva a entrar en producción bajo un nuevo pull request. Eso es lo que realmente quiero en producción. Este tipo de predictibilidad. No hay misterio aquí. No hay arqueología mágica de almacenamiento local donde tengamos que desenterrar lo que sucedió y lo que cambió para realmente causar el incidente. Así que, ya sabes, no estamos más en el estado de ánimo de decir que funciona a menos que Safari esté de humor. Solo un estado de autenticación explícito, observable y realmente aburrido. Y cerraré con mi principal conclusión de la sesión. Creo que la autenticación es la cadena de confianza.

Y la parte difícil es mantener cada capa de autenticación honesta después de que el usuario ya está dentro. Estoy hablando de sesiones, tokens, rutas, API, modelos de permisos y el flujo de recuperación. Eventualmente, esas capas comienzan a estar en desacuerdo. Y los síntomas se verán extraños. Verás bucles, sesiones fantasma, tormentas de actualización y fugas de permisos.

La forma de atravesarlo es encontrar el desacuerdo. Nombra el invariante que se rompió. Y restaura una propiedad clara. Una buena autenticación se sentirá aburrida porque la responsabilidad es clara. El servidor llevará la verdad. El cliente llevará tu experiencia. Pero tu observabilidad es lo que lleva la evidencia. La evidencia que realmente necesitarás si algo se rompe.

Pero tu CI aquí es ese punto de control que detendrá y evitará que las cosas se filtren en tu producción. Y detendrá el incidente de ayer para que no vuelva a funcionar allí, de modo que no tengas que combatir otro incidente similar. Así que, la clave aquí es hacer que tu autenticación sea lo más explícita posible. Hazla lo más observable posible. Y hazla aburrida. Gracias. Y si tienes alguna pregunta, por favor siéntete libre de contactarme a través de LinkedIn que puedes ver en tu pantalla ahora mismo. Simplemente escanea el código QR y conectémonos para discutir esto más a fondo. Muchas gracias por asistir hoy.