Seguridad en APIS

Por Gerardo Canedo, Gerente de Seguridad de GeneXus Consulting.

Cada vez más nos encontramos utilizando o generando APIS. Un grupo de investigadores de seguridad ha analizado cuáles son las vulnerabilidades más prevalentes en este tipo de integración y, desde el 2019, vienen generando el OWASP API Security Top 10.

Estos son los aspectos a tener en cuenta al desarrollar una API:

1. Control de acceso

Que un usuario pueda utilizar una API no significa que pueda consultarla con cualquier dato. Un usuario de un banco puede consultar su estado de cuenta, no el estado de una cuenta que no le pertenece. Esto no se soluciona a nivel de Rol, sino a nivel de datos.

2. Errores de Autenticación

Siguiendo con el caso anterior, este punto se materializa si un atacante pudiera ver el estado de cuenta sin ser usuario.

3. Exposición excesiva de datos

Es común que se piense una API de forma genérica para utilizarse en varios lugares. Esta API tiene el superconjunto (todos) de los atributos a utilizar. Esto tiene como riesgo de seguridad exponer más datos que los necesarios. Un ejemplo de este tipo de vulnerabilidad es el reuso de un servicio para validar un documento de identidad. No sólo retornaba si el documento era válido, sino también los datos del usuario y el hash de su contraseña. La API necesaria debía retornar TRUE o FALSE únicamente.

4. Falta de limitaciones en el uso del API

Las APIS son muy fácilmente automatizables, para eso fueron diseñadas. Un abuso en su uso es llamarlas de forma concurrente -o solicitando muchos datos a la vez- con el fin de obtener todos los datos posibles. En este caso, es importante establecer límites de uso por unidad de tiempo que sean razonables al negocio, y también por usuario, no globales.

5. Errores en autorización de funciones

Las APIS tienen nombres y verbos predecibles (sobre todo en el caso de los servicios REST). Este error se manifiesta cuando pensamos en seguridad por oscuridad; como no decimos el nombre del endpoint, nadie lo puede utilizar. Un ejemplo es cuando un usuario que descubre un API -pensada para su uso interno, pero expuesta a internet por error- que permita crear una nueva cuenta.

6. Asignación masiva

Su nombre es contraintuitivo. No es sobre asignar muchas instancias en una única vez, sino, agregarle al endpoint valores que son aceptados. Si el API en su uso común utiliza los atributos Nombre, Apellido y Email, una asignación masiva puede ser incluir el campo ID y lograr actualizar otro usuario y no el propio. Otra asignación masiva puede ser incluir el campo SALDO y modificar el saldo de la cuenta.

7. Errores en las configuraciones de seguridad

Existen mecanismos para indicar desde dónde pueden ser invocadas las APIs, los cabezales HTTP requeridos y el cifrado de canales necesaria. Una falla de configuración corresponde a un error en estos aspectos, por ejemplo, el uso abierto del API o por HTTP en vez de HTTPs.

8. Inyecciones

A las clásicas inyecciones SQL se le agregan las NoSQL, GraphQL, comandos, etc. Cambian los intérpretes, la esencia de las vulnerabilidades continúan siendo las mismas.

9. Deficiencia en la gestión de archivos

Generalmente existen distintas versiones de las APIS, así como documentos de uso de las mismas. Es importante manejar conceptos como obsoleto (deprecated) y remediación de bugs en varias versiones del API. Ciertamente es una nueva dimensión a considerar a la hora de gestionar las remediaciones.

10. Registro y monitoreo insuficiente

Al igual que en el OWASP TOP 10, la falta de registro o monitoreo (loggin) impide detectar ataques, conocer el normal funcionamiento de las apis y establecer la carga normal de la misma. API que no genera logs y es monitoreada, API que no se mejora.

Para mas información sobre seguridad en APIS (construcción, pruebas y diseño), OWASP es el mejor recurso para consultar: ampliar información. 

Fuente de la foto: Vector de Tecnología creado por freepik – www.freepik.es