El proyecto OWASP API Security Top 10 mantiene un documento de los 10 principales riesgos de seguridad en APIs, así como un portal de documentación para las mejores prácticas al crear o evaluar API.
En el post anterior analizamos el objetivo del proyecto y, a continuación, brindamos un resumen de las primeras cinco vulnerabilidades del Top 10.

API 1: Autorización de nivel de objeto vulnerable

Las API tienden a exponer puntos finales (end-points) que manejan identificadores de objetos, creando un problema de Control de Acceso y amplieando la superficie de ataque. En cada función que accede a datos utilizando una entrada del usuario, se deben considerarse agregar verificaciones adicionales de autorización a nivel de objeto.

Ejemplo: /api/shops/{shopID}/create

La autorización a nivel de objeto es un mecanismo de control de acceso que generalmente se implementa a nivel de código para validar que un usuario solo puede acceder a objetos a los que debería tener acceso. Cada end-point de API que recibe una ID de un objeto y realiza cualquier tipo de acción sobre el objeto, debe implementar comprobaciones de autorización a nivel de ese objeto. Las comprobaciones deben validar que el usuario conectado tiene acceso para realizar la acción solicitada en el objeto solicitado.

Las fallas en este mecanismo generalmente conducen a la divulgación no autorizada de información, modificación o destrucción de todos los datos.

Como prevenirlo

• Implementar un mecanismo de autorización adecuado que se base en las políticas y la jerarquía del usuario.
• En cada función que utiliza una entrada del cliente para acceder a un registro de la base de datos, se debeusar un mecanismo de autorización para verificar si el usuario conectado tiene acceso para realizar la acción solicitada en el registro.
• Se debería usar valores aleatorios e impredecibles como GUID para las ID de los registros.
• Se deben escribir pruebas para evaluar el mecanismo de autorización.

API 2: Autenticación de usuario vulnerable

A menudo, los mecanismos de autenticación se implementan incorrectamente, lo que permite a los atacantes comprometer los tokens de autenticación o explotar fallas de implementación para asumir las identidades de otros usuarios de manera temporal o permanente. La incapacidad del sistema para identificar al cliente/usuario compromete la seguridad de la API en general.

Ejemplo: /api/system/verification-codes/{smsToken} (con un token de 4 dígitos)

Los end-point y los flujos de autenticación son activos y deben protegerse. Los formularios de "Olvidé mi contraseña / restablecer contraseña" debe tratarse de la misma manera que los mecanismos de autenticación más sensibles.

Como prevenirlo

• Asegurarse de conocer todos los flujos posibles para autenticarse en la API (mobile, web, enlaces profundos que implementan autenticación con un solo clic, etc.)
• Leer sobre sus mecanismos de autenticación. Asegurarse de comprender qué y cómo se usan. Por ejemplo, OAuth no es autenticación, y tampoco lo son las API keys.
• No reinventar la rueda de la autenticación, generación de tokens, almacenamiento de contraseñas. Usar los estándares.
• Los puntos finales de recuperación de credenciales y "olvido de contraseña" deben tratarse como end-points de inicio de sesión en términos de fuerza bruta, limitación de velocidad y protecciones de bloqueo.
• Usar la OWASP Authentication Cheatsheet.
• Donde sea posible, implementar la autenticación multifactor (MFA).
• Implementar mecanismos anti-fuerza bruta para mitigar el relleno de credenciales automático, ataques de diccionario y ataques de fuerza bruta en los end-points de autenticación. Este mecanismo debería ser más estricto que el mecanismo de limitación de velocidad regular en la API.
• Implementar un mecanismo de bloqueo o recuperación de cuenta para evitar la fuerza bruta contra usuarios específicos. Implemente verificaciones de contraseña débil y un CAPTCHA.
• Las API keys no deben usarse para la autenticación de usuarios, sino para la autenticación de la aplicación o el proyecto del cliente.

API3: Exposición excesiva de datos

Al esperar 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 realicen el filtrado de datos antes de mostrarlo al usuario.

Ejemplo: /api/articles/{articleId}/comments/{commentId} (expone todos los comentarios y los datos personales del autor del mismo)

Las API devuelven, por diseño, datos confidenciales al cliente. Estos datos generalmente se filtran en el lado del cliente antes de presentarse al usuario. Un atacante puede detectar fácilmente el tráfico y ver los datos confidenciales.

Como prevenirlo

• Nunca confiar en el cliente para filtrar datos confidenciales.
• Revisar las respuestas de la API para asegurarse de que solo contengan los datos necesarios.
• Los ingenieros de backend siempre deben preguntarse "¿quién es el consumidor de los datos?" antes de exponer un nuevo end-point API.
• Evitar el uso de métodos genéricos como to_json() y to_string(). En cambio, se debe seleccionar las propiedades específicas que realmente se quieran devolver al cliente.
• Clasificar la información confidencial y de identificación personal (PII) y revisar todas las llamadas API que devuelven dicha información para ver si estas respuestas plantean un problema de seguridad o confidencialidad.
• Implementar un mecanismo de validación de respuesta basado en esquemas como una capa adicional de seguridad. Como parte de este mecanismo, se debe definir y aplicar los datos devueltos por todos los métodos API, incluidos los errores.

API 4: Fallas en la restricción y limitación de recursos

Muy a menudo, las API no imponen ninguna restricción sobre el tamaño o la cantidad de recursos que puede solicitar el cliente. Esto no solo puede afectar el rendimiento del servidor API, lo que lleva a la denegación de servicio (DoS), sino que también deja la puerta abierta a fallas de autenticación a través de fuerza bruta.

Ejemplo: /api/users?page=1&size=10000000 (brinda una cantidad excesiva de resultados)

Las solicitudes de API consumen recursos como red, CPU, memoria y almacenamiento. La cantidad de recursos necesarios para satisfacer una solicitud depende en gran medida de la entrada del usuario y la lógica empresarial del end-point. Una API es vulnerable si al menos uno de los siguientes límites falta o está configurado de manera inapropiada (por ejemplo, demasiado bajo/alto):

• Tiempos de espera de ejecución
• Memoria máxima asignable
• Número de descriptores de archivo
• Número de procesos
• Tamaño de archivos
• Número de solicitudes por cliente y/o recurso
• Número de registros por página, a devolver en una única solicitud

Como prevenirlo

• Docker facilita la limitación de memoria, CPU, número de reinicios, descriptores de archivos y procesos. Es recomendable su utilización.
• Implementar un límite sobre la frecuencia con que un cliente puede llamar a la API dentro de un marco de tiempo definido.
• Notificar al cliente cuando se excede el límite. proporcionando el número máximo y la hora a la que se restablecerá el límite.
• Validar adecuadamente (del lado del servidor) el formato de la consulta y los parámetros del cuerpo de la solicitud, específicamente el relacionado al número de registros que se devolverán en cada respuesta.
• Definir y aplicar un tamaño máximo de datos en todos los parámetros entrantes y payloads, como la longitud máxima de las cadenas y el número máximo de elementos en las matrices y los objetos.

API 5: Autorización vulnerable a nivel de función

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

Ejemplo: GET /api/admin/v1/users/all (muestra todos los usuarios de la aplicación)

La mejor manera de encontrar problemas de autorización a nivel de función es realizar un análisis profundo del mecanismo de autorización, teniendo en cuenta la jerarquía de usuarios, los diferentes roles o grupos en la aplicación.

Como prevenirlo

• La aplicación debe tener un módulo de autorización consistente y fácil de analizar que se invoque desde todas las funciones de negocio. Con frecuencia, dicha protección es proporcionada por uno o más componentes externos al código de la aplicación.
• El o los mecanismo de aplicación deberían denegar cualquier tipo de acceso por defecto, requiriendo concesiones explícitas a roles específicos para acceder a cada función.
• Revisar los end-points y su autorización a nivel de función, teniendo en cuenta la lógica empresarial de la aplicación y la jerarquía de grupos.
• Asegurar que todos los controladores administrativos implemente comprobaciones de autorización basadas en los grupo y el rol del usuario.
• Asegurar que las funciones administrativas implementen comprobaciones de autorización basadas en el grupo y el rol del usuario.

Continuará...