Vulnerabilidad API testing
Las pruebas de seguridad de una API (Application Programming Interface) buscan identificar y mitigar vulnerabilidades que podrían ser explotadas por atacantes para obtener acceso no autorizado a datos, manipular el comportamiento de la aplicación o causar una denegación de servicio. A diferencia de las pruebas de una aplicación web tradicional, las pruebas de API se centran en la lógica del negocio y la autenticación, ya que no existe una interfaz de usuario visual.
Vulnerabilidades comunes en el testing de APIs
El OWASP API Security Project ha identificado las vulnerabilidades más críticas para las APIs. Aquí están algunas de las más comunes:
Broken Object Level Authorization (BOLA): Es una de las vulnerabilidades más críticas. Ocurre cuando un usuario puede acceder a recursos que pertenecen a otro usuario simplemente cambiando el identificador del objeto en la URL. Por ejemplo, si un usuario con ID 100 puede ver su perfil en
/api/users/100, un atacante podría intentar acceder a/api/users/101para ver el perfil de otro usuario. La API no verifica si el usuario autenticado tiene permiso para acceder a ese ID específico.Broken Authentication: Se refiere a fallos en la implementación de la autenticación. Un atacante podría explotar debilidades en la gestión de tokens, las credenciales por defecto o la falta de rate limiting para realizar ataques de fuerza bruta y obtener acceso a cuentas de usuario.
Excessive Data Exposure: Esta vulnerabilidad se produce cuando la API envía más datos de los necesarios al cliente. En lugar de filtrar los datos sensibles en el servidor, se espera que el cliente decida qué mostrar. Un atacante podría interceptar la respuesta y acceder a datos privados, como información de contacto o números de tarjeta de crédito, que el desarrollador de la interfaz de usuario no pretendía mostrar.
Mass Assignment: Esta vulnerabilidad se relaciona con la capacidad de un atacante para modificar propiedades de objetos que no deberían ser accesibles. Un atacante puede, por ejemplo, enviar un campo como
{"isAdmin": true}en una solicitud para elevar sus privilegios, y si la API no valida los datos correctamente, podría asignar ese valor al objeto de usuario.Unrestricted Resource Consumption: Las APIs son susceptibles a ataques de denegación de servicio (DoS) si no se imponen límites de recursos. Un atacante podría enviar una gran cantidad de solicitudes o una única consulta muy compleja (especialmente en GraphQL) que agote los recursos del servidor (CPU, memoria, ancho de banda), causando una caída del servicio.
Injection: Aunque es menos común en APIs que no interactúan directamente con bases de datos, las APIs son vulnerables a ataques de inyección (SQL, NoSQL, o Command Injection) si no se valida y sanitiza la entrada del usuario antes de usarla en consultas o comandos del sistema.
¿Cómo se prueban las APIs en busca de vulnerabilidades?
El testing de seguridad de APIs generalmente se realiza con herramientas como Postman, Burp Suite y OWASP ZAP. El proceso implica:
Descubrimiento: Se busca entender la funcionalidad de la API y sus puntos de entrada.
Análisis de la entrada: Se examinan todos los parámetros y datos que la API acepta para identificar posibles puntos de inyección.
Fuzzing: Se envían datos malformados o inesperados a la API para ver cómo responde y si se pueden provocar errores que revelen información o vulnerabilidades.
Análisis de la salida: Se examinan las respuestas de la API para detectar cualquier información sensible que esté siendo expuesta.
Pruebas de autenticación y autorización: Se intenta acceder a puntos finales sin credenciales válidas o con credenciales de otros usuarios para verificar si el control de acceso funciona correctamente.
