Cada pull request Agregar o modificar un endpoint altera la superficie de ataque de tu API. La mayoría de las herramientas de seguridad de API no lo detectan hasta que el endpoint está activo y recibiendo tráfico. Para entonces, la solución ya no es un simple cambio de una línea en una revisión de código, sino una conversación sobre respuesta a incidentes.
La seguridad de las API consiste en encontrar y solucionar los riesgos relacionados con la forma en que una aplicación expone sus puntos finales: quién puede llamarlos, qué datos devuelven y si hacen lo que dice la documentación.
La mayoría de las herramientas diseñadas para solucionar este problema prueban la API en tiempo de ejecución, desde fuera, del mismo modo que lo haría un atacante. Este enfoque funciona, pero solo después de que la API esté desplegada. xygeni Opta por la vía anterior: lee el código fuente y la especificación de la API antes de que se envíe una sola solicitud al punto final.
Las cuatro formas de probar una API y qué responde cada una.
La mayoría de los programas maduros ejecutan más de uno de estos:
- Pruebas estáticas Analiza el código fuente y las especificaciones de la API antes de la implementación. Responde a la pregunta "¿qué acabamos de exponer?". Este es el enfoque en el que se centra este artículo.
- Pruebas dinámicas (DAST) Envía tráfico real a una API en funcionamiento y observa cómo responde. Responde a la pregunta: "¿Qué es realmente accesible y explotable en este momento?".
- Fuzzing Envía datos de entrada mal formados o inesperados a los puntos finales para detectar fallos y errores en casos extremos. Responde a la pregunta: "¿Qué falla con una entrada que no habíamos previsto?".
- Pruebas de penetración manuales Añade el criterio humano para encontrar fallos lógicos que las herramientas automatizadas pasan por alto. Responde a la pregunta: "¿Qué combinaciones haría un atacante inteligente?".
Ninguna de ellas reemplaza a las demás. Responden a preguntas diferentes en distintos momentos del ciclo de vida, y la principal carencia de la mayoría de los programas radica en la primera.
Por qué la mayoría de las herramientas de seguridad de API detectan el riesgo demasiado tarde.
Las pruebas de seguridad de API en tiempo de ejecución envían tráfico a una aplicación en funcionamiento y observan su respuesta. Se trata de una capa legítima y necesaria. Sin embargo, por su propia naturaleza, es un indicador rezagado: un punto final debe existir, estar desplegado y ser accesible antes de que un escáner en tiempo de ejecución pueda proporcionar información al respecto. Lo que encuentre ya estaba expuesto durante el tiempo que duró el escaneo.
Detrás de ese problema de sincronización hay una segunda deficiencia. Las herramientas de ejecución solo pueden probar lo que saben que existe. Si un punto final nunca se documentó, o si la especificación OpenAPI quedó obsoleta en el momento en que se implementó una nueva ruta, un escáner de ejecución no tiene forma de saber que existe. Prueba el mapa, no el territorio.
Las pruebas de seguridad de API estáticas cierran ambas brechas al trasladar la verificación al lugar donde se define el punto final: su código y su especificación de API, antes de la implementación. pull request que introduce un punto final es el pull request que pone de manifiesto su riesgo.
Qué significa realmente la seguridad de las API estáticas
Xygeni crea su inventario de API a partir de dos fuentes: el código fuente de su aplicación y las especificaciones de su API, incluidas OpenAPI y Swagger.
Un inventario basado únicamente en especificaciones muestra los puntos finales que alguien se acordó de documentar. Un inventario basado únicamente en código muestra lo que existe, pero no necesariamente cómo se suponía que debía usarse. Consultar ambos ofrece una visión completa: los puntos finales que documentaron tus equipos y los que nadie documentó.
Ese inventario es la base sobre la que se construye todo lo demás:
- Total de API descubiertas y activos en riesgo medidos en comparación con una línea de base
- Puntos finales desglosados por método HTTP
- Problemas agrupados por servicio
- Cada punto final con su método, ruta, servicio, módulo, estado de autenticación y puntuación de riesgo.
Tus responsables de ingeniería pueden ver la forma de la interfaz de tu API sin necesidad de abrir ni una sola incidencia.
Cada punto final que encontró Xygeni, con su método, estado de autenticación y puntuación de riesgo, se construyó a partir del código y la especificación en conjunto.
Production note Recorta el panel de clasificación de IA de cualquier captura de pantalla de seguridad de la API.
Mapeado al Top 10 de seguridad de API de OWASP
Los resultados confirman el marco que sus equipos de seguridad y sus auditores ya utilizan. Xygeni detecta riesgos en toda la API de seguridad de OWASP. 10 mejores (2023):
Una categoría se omite deliberadamente. La API 6, Acceso sin restricciones a flujos de negocio sensibles, requiere comprender qué se supone que permite un proceso de negocio, y ningún analizador estático lo detecta de forma fiable. Cualquier proveedor que afirme lo contrario solo le está vendiendo una casilla de verificación. Esa responsabilidad recae en su modelado de amenazas y en sus pentesters.
No todos los hallazgos son iguales: Sensibilidad de los datos y combinaciones tóxicas
Una lista plana de hallazgos trata un punto final de verificación de estado no autenticado de la misma manera que un punto final no autenticado que devuelve registros de clientes. No se trata del mismo problema, y un modelo de priorización que los puntúa de forma idéntica acostumbra a los equipos a ignorar la lista.
Xygeni clasifica los datos que maneja cada punto final, identificando la información de identificación personal (PII), la información de procesamiento de tarjetas de pago (PCI) y la información de salud protegida (PHI) en los parámetros de solicitud y en las respuestas, y los relaciona con el estado de autenticación del punto final.
También correlaciona los hallazgos que llegan al mismo punto final y aumenta la gravedad cuando se acumulan. Una fuga de información personal identificable (PII) en una respuesta es un hallazgo grave por sí solo. La misma fuga en un punto final que no requiere autenticación es crítica, y la plataforma la califica como tal en lugar de dejar la conexión para que alguien la detecte manualmente.
Puntos finales zombis y huérfanos: la deriva entre el código y la especificación.
Debido a que Xygeni lee tu código y tu especificación de API simultáneamente, detecta dónde discrepan. Esa divergencia se manifiesta en tres patrones reconocibles:
- Puntos finales no documentados. Existen en el código y nunca se añadieron a la especificación.
- Puntos finales zombis. Están marcados como obsoletos o retirados, pero aún se puede acceder a ellos.
- Puntos finales huérfanos. Nadie en el equipo actual es el dueño de ellos.
Ninguno de estos aparece en un inventario que solo incluye especificaciones, porque precisamente las especificaciones son las que los omiten.
Pruebas sobre las que puedes actuar, no una autorización para investigar.
Cada hallazgo apunta al controlador responsable exacto: el archivo, la clase, el método y la línea específica que introdujo la vulnerabilidad, con el código malicioso mostrado junto a él. Cada uno también incluye su gravedad, su categoría en el Top 10 de seguridad de API de OWASP, su CWE, el estado de autenticación del punto final y la clasificación de sensibilidad de los datos involucrados.
Un hallazgo que simplemente menciona un punto final obliga al desarrollador a revisar el código fuente antes incluso de poder empezar a corregir nada. Un hallazgo que menciona la línea lo lleva directamente a la solución.
Los resultados se exportan como JSON, CSV, Markdown y SARIF 2.1.0, por lo que llegan al archivo therramientas que tus equipos ya utilizan.
El controlador, la línea y el código que introdujo la vulnerabilidad. No es un ticket para investigar.
Por qué esto reside en una plataforma y no en otra consola.
Xygeni ejecuta la seguridad de la API junto con SAST, SCA, Protección de secretos, IaC y DAST dentro de una única plataforma, correlacionada a través de ASPMen lugar de enviarlo como una herramienta separada con su propio login y su propia cartera de pedidos pendientes.
Esto es importante porque los hallazgos estáticos y los hallazgos en tiempo de ejecución responden a preguntas diferentes sobre el mismo punto final, y son más útiles juntos que por separado. El análisis estático indica que un punto final es riesgoso antes de su lanzamiento. DAST confirma qué es realmente accesible y explotable una vez que está en funcionamiento.
Si se divide entre dos consolas, el riesgo correlacionado se convierte en dos tareas pendientes sin relación entre sí. Nadie las concilia, y el punto final, que no está documentado ni autenticado, no aparece en ninguna de las dos colas.
Vea la superficie de ataque real de su API. La seguridad de la API está disponible como una Enterprise Se trata de un complemento para la plataforma Xygeni, y se realiza un escaneo en sus propios repositorios dentro de su propia infraestructura.
Preguntas Frecuentes
¿Puede identificar qué puntos finales manejan datos confidenciales?
Sí. Xygeni identifica la información de identificación personal (PII), la información de procesamiento de pacientes (PCI) y la información de salud protegida (PHI) en los parámetros y respuestas de los puntos finales, y utiliza esa clasificación para ordenar los hallazgos según la exposición real.
¿Puede funcionar en todos? pull request?
Sí. El escaneo incremental analiza solo los puntos finales que cambiaron, y el manifiesto que produce puede enfocar un escaneo DAST posterior en esos mismos puntos finales, de modo que las pruebas estáticas y en tiempo de ejecución se mantienen alineadas con lo que realmente se movió.
¿Mi código sale de mi entorno?
No. Los escaneos se realizan en su propia infraestructura. Solo se cargan los resultados, que están protegidos tanto en tránsito como en reposo.
¿Cómo puedo obtener seguridad para la API?
La seguridad de la API está disponible como una Enterprise Complemento. Solicita una prueba de concepto y la definiremos contigo.
