API pentest

Las pruebas de penetración de las interfaces de programación de aplicaciones (API) se centran en la evaluación de la postura de seguridad de los entornos que utilizan API y requieren la transmisión de datos. Los objetivos del compromiso son subvertir la lógica de la aplicación y provocar una exposición de información sensible accediendo a funcionalidades y niveles de acceso restringidos. Las actividades de prueba se llevan a cabo utilizando principalmente técnicas de enumeración y explotación manuales descritas en la Guía de Pruebas de API de OWASP.

Procedimiento
Los probadores de penetración se centran en la identificación de clases de vulnerabilidades dentro de los 10 riesgos más críticos para la seguridad de las aplicaciones API del Open Web Application Security Project (OWASP):

Autorización a nivel de objeto rota – Las API tienden a exponer puntos finales que manejan identificadores de objetos, lo que crea un problema de control de acceso a nivel de una amplia superficie de ataque. Las comprobaciones de autorización a nivel de objeto deberían considerarse en cada función que accede a una fuente de datos utilizando una entrada del usuario.

Autorización a nivel de objeto rota – Las API tienden a exponer puntos finales que manejan identificadores de objetos, lo que crea un problema de control de acceso a nivel de una amplia superficie de ataque. Las comprobaciones de autorización a nivel de objeto deberían considerarse en cada función que accede a una fuente de datos utilizando una entrada del usuario.

Exposición excesiva de datos – En cuanto a las implementaciones genéricas, los desarrolladores tienden a exponer todas las propiedades de los objetos sin tener en cuenta su sensibilidad individual, confiando en que los clientes realizan el filtrado de los datos antes de mostrarlos al usuario.

La falta de recursos y la limitación de la tasa – Muy a menudo, las API no imponen ninguna restricción en cuanto al tamaño o el número de recursos que puede solicitar el cliente/usuario. Esto no sólo puede impactar el rendimiento del servidor de la API, provocando una denegación de servicio (DoS), sino que también dejan la puerta abierta a fallos de autenticación como la fuerza bruta.

Autorización de nivel de función rota – Las políticas de control de acceso complejas con diferentes jerarquías, grupos, roles y una separación poco clara entre las funciones administrativas y las regulares, tienden a a provocar fallos de autorización. Al explotar estos problemas, los atacantes obtienen acceso a los recursos de otros usuarios y/o a las funciones administrativas.

Asignación masiva – La vinculación de los datos proporcionados por el cliente (por ejemplo, JSON) a los modelos de datos, sin un filtrado adecuado de las propiedades basado en una lista permitida, suele conducir a una asignación masiva. Ya sea adivinando las propiedades de los objetos explorando otros puntos finales de la API, leyendo la documentación o proporcionando propiedades adicionales de los objetos en las cargas útiles de las solicitudes, permite a los atacantes modificar propiedades de los objetos que no se supone que deban hacer.

Mala configuración de la seguridad – La desconfiguración de la seguridad suele ser el resultado de configuraciones por defecto poco seguras, configuraciones incompletas o ad-hoc, almacenamiento en la nube abierto, cabeceras HTTP mal configuradas métodos HTTP innecesarios, uso compartido de recursos de origen cruzado (CORS) permisivo y mensajes de error verbales que contienen información sensible.

Inyección Los fallos de inyección, como SQL, NoSQL, Command Injection, etc., se producen cuando el atacante inyecta códigos o fragmentos de estos que se introducen a través de cualquier formulario de consulta que pueda enviar información a la base de datos de la web. Los datos maliciosos del atacante pueden engañar al intérprete del código para que ejecute comandos no deseados o acceda a datos sin la debida autorización.

Gestión inadecuada de los activos – Las API tienden a exponer más puntos finales que las aplicaciones web tradicionales, lo que hace que una documentación adecuada y actualizada sea muy importante. Un inventario adecuado de hosts y versiones de APIs desplegadas también desempeñan un papel importante a la hora de mitigar problemas como las versiones obsoletas de las API y los puntos finales de depuración expuestos.

Registro y supervisión insuficientes – Un registro y una supervisión insuficientes, junto con una integración inexistente o ineficaz con la respuesta a incidentes, permite a los atacantes seguir atacando los sistemas, mantener la persistencia, pivotar a más sistemas para manipular, extraer o destruir datos. La mayoría de los estudios sobre infracciones demuestran que el tiempo para detectar una infracción es de más de 200 días, normalmente detectada por partes externas en lugar de procesos internos o la supervisión.

ES