Fortaleciendo Nuestra Implementación de SAML en GitHub

0
51

Durante más de una década, GitHub ha proporcionado autenticación empresarial mediante SAML (Language de Marcado de Aserciones de Seguridad), comenzando con el lanzamiento de GitHub Enterprise Server 2.0.0 en noviembre de 2014. El inicio de sesión único (SSO) a través de SAML permite a las empresas integrar sus proveedores de identidad existentes con una amplia gama de productos de GitHub, extender políticas de acceso condicional y gestionar organizaciones empresariales en la plataforma.

Para implementar esta funcionalidad, el equipo de GitHub tuvo que construir y mantener el soporte para la especificación SAML 2.0. Esta especificación define el proceso de autenticación y establece la confianza entre un proveedor de identidad y los productos de GitHub. Esto incluye la generación de metadatos SAML para los proveedores de identidad, la creación de solicitudes de autenticación SAML como parte del flujo SSO iniciado por el proveedor de servicio y, lo más importante, el procesamiento y la validación de las respuestas SAML de un proveedor de identidad para autenticar a los usuarios.

Estas rutas de código son críticas desde una perspectiva de seguridad, dado que cualquier error en el establecimiento y validación del proceso de autenticación puede resultar en un bypass de autenticación o en la suplantación de usuarios. Además, estas áreas del código utilizan el análisis de XML y la criptografía, dependen de especificaciones complejas, como las normas de firma XML, cifrado XML y esquemas XML. La superficie de ataque del código SAML es bastante amplia, lo que permite que los datos validados para la autenticación sean manipulados.

Esta combinación de criticidad en la seguridad, complejidad y superficie de ataque hace que la implementación de SAML presente un riesgo mayor que la mayoría del código que se desarrolla y mantiene.

Desde su lanzamiento en 2014, GitHub ha invertido continuamente en reforzar estos flujos de autenticación, colaborando con investigadores de seguridad tanto internos como a través de su programa de recompensas por errores de seguridad para identificar y corregir vulnerabilidades. Sin embargo, a pesar de abordar cada vulnerabilidad, quedaban inquietudes persistentes debido a la amplitud y complejidad de las causas raíz identificadas.

El año pasado, el equipo de ingeniería se propuso responder a la pregunta de cómo construir confianza en una tecnología tan compleja y arriesgada como SAML. Tras revisar su propia implementación, decidieron que era momento de un cambio, evaluando bibliotecas previas y considerando nuevas ideas para mejorar su estrategia de SAML. Este proceso llevó a identificar cambios prometedores que se podrían implementar.

El primer paso fue repensar su biblioteca. Evaluaron la biblioteca ruby-saml, considerada por su comunidad fuerte y activa, decidiendo finalmente utilizarla tras revisar varias opciones y apreciar sus ventajas en términos de soporte y mantenimiento en comparación con su propia implementación interna.

Para validar la nueva biblioteca, GitHub implementó pruebas A/B, permitiendo evaluar y observar los cambios en la lógica de procesamiento de SAML. Utilizando un enfoque basado en experimentos, se llevó a cabo una validación cuidadosa que mantuvo la estabilidad de su código SAML mientras el equipo evaluaba ruby-saml.

Además, se centraron en la validación de esquema y la minimización de su superficie de ataque, lo que les permitió reducir la complejidad del procesamiento de entradas al restringir la validación del esquema y aplicar validaciones más estrictas.

Finalmente, decidieron adoptar una estrategia de doble análisis implementando ambas bibliotecas, una antigua y confiable y otra nueva y mantenida activamente, para reforzar su implementación y contener el impacto de futuras vulnerabilidades.

A medida que GitHub continúa manejando casi un millón de respuestas SAML al día, este enfoque les brinda la resiliencia necesaria. La experiencia adquirida se presenta como un modelo para otros equipos que buscan abordar partes complejas o críticas en sus bases de código, destacando la importancia de experimentos incrementales y basados en datos.
vía: GitHub Security