En mi carrera ha habido algunos, pero el que me viene a la mente también fue extremadamente gratificante. Aquí una descripción de alto nivel:
Empresa: Fortune 500
Pila tecnológica: Oracle, JMS, Spring 3, Spring 3 MVC
Servidor de aplicaciones: Resina 3 (¡qué asco!)
Infraestructura: Akamai CDN, F5, servidor Apache HTTP
Solicitud vol: 5M + solicitudes por día
Ingresos: $ 3.5B / año
Síntoma: Algunos usuarios del sistema informaban (a través del centro de llamadas) que “se convertirían en alguien más” solo en ciertas páginas de la aplicación.
- ¿Por qué es importante la participación del cliente para las aplicaciones móviles?
- ¿Crees que facilitar las aplicaciones de programación (PC o móvil) es algo bueno para la industria?
- Cómo desarrollar un dron
- Si tiene una idea que desea desarrollar en una aplicación, ¿cómo lo hace?
- ¿Por qué a los desarrolladores de aplicaciones no les gusta Objective-c?
Notas:
Esencialmente, lo que informaban los usuarios indicaba que sus sesiones autenticadas, como de costumbre, mostrarían la información de su cuenta en las páginas de la aplicación solo para cambiar a otra identidad en ciertas páginas. ¿Lo entendiste? ¡Las sesiones autenticadas se estaban convirtiendo ‘mágicamente’ en sesiones autenticadas de otros usuarios! O, sesión de highjacking.
Solución:
¿Cómo podría un usuario convertirse en otro usuario solo en ciertas páginas? Tenga en cuenta que tampoco necesariamente permanecerían en la sesión de highjacked: el siguiente clic que volvieron a estar o durarían un par de clics. Aquí está la parte divertida: la inspección de la fuente de la compañía mostró una dependencia en el administrador de sesión del servidor de aplicaciones. Entonces, seguir las migas de pan condujo a que me gustara la fuente del código fuente del servidor de aplicaciones para leer cómo el administrador CRUD’d las sesiones. Resulta que el servidor usó una matriz fija para la capacidad de la sesión y las operaciones de cambio de bits basadas en un parámetro de configuración para calcular el índice de la matriz de almacenamiento de la sesión en la que debe almacenarse el objeto de la sesión, todo desviado de la ID de sesión generada. Este algoritmo es muy común. Sin embargo, en este caso, la carga durante la aparición de este problema fue mayor que en cualquier otro momento del día, lo que significa que la matriz estaba llena. No importaba cuál era el valor de ID de sesión, se resolvería en un índice dentro del rango de configuración. ¡Durante la recuperación de la sesión del usuario real en cualquier solicitud dada, se devolvería la sesión incorrecta, dando al usuario la apariencia de convertirse en otra persona! La solución fue aumentar la capacidad de la matriz de sesión en la configuración del servidor para evitar que esto vuelva a suceder. Esta opción fue más rápida que abandonar el antiguo servidor de aplicaciones, que desde entonces se ha logrado.
Espero que todo esto tenga sentido y que definitivamente se me quede en la mente como uno de esos temas de libros de texto que nunca se olvida.
