Resumen del módulo

Las interfaces de programación de aplicaciones web (API) son omnipresentes y permiten un

intercambio fluido de datos entre diversos sistemas y aplicaciones en internet. Sin embargo,
pueden ser susceptibles a diversas vulnerabilidades. Este módulo profundiza en el ámbito crítico
de la seguridad de las API, explorando vulnerabilidades comunes y vectores de ataque.
Centrándonos principalmente en el Top 10 de Seguridad de API de OWASP de 2023, examinaremos
los riesgos más comunes que enfrentan las API al atacar una API RESTful de un marketplace de
comercio electrónico.

En detalle, este módulo cubrirá lo siguiente:

 API1:2023 Broken Object Level Authorization

 API2:2023 Broken Authentication

 API3:2023 Broken Object Property Level Authorization

 API4:2023 Unrestricted Resource Consumption

 API5:2023 Broken Function Level Authorization

 API6:2023 Unrestricted Access to Sensitive Business Flows

 API7:2023 Server Side Request Forgery

 API8:2023 Security Misconfiguration

 API9:2023 Improper Inventory Management

 API10:2023 Unsafe Consumption of APIs

Introducción a los ataques API

Las interfaces de programación de aplicaciones (API) son fundamentales para el desarrollo de

software moderno, siendo las API web la forma más común. Permiten la comunicación fluida y el
intercambio de datos entre diversos sistemas a través de internet, actuando como puentes
cruciales que facilitan la integración y la colaboración entre diferentes aplicaciones de software.

En esencia, las API consisten en reglas y protocolos definidos que dictan cómo interactúan los
distintos sistemas. Especifican los requisitos de formato de datos, definen los métodos de acceso a
los recursos y definen las estructuras de respuesta esperadas. Las API se clasifican, en general, en
públicas (accesibles a terceros) y privadas (restringidas a organizaciones o grupos de sistemas
específicos).

Estilos de construcción de API

Las API web se pueden crear utilizando varios estilos arquitectónicos,

incluidos REST, SOAP, GraphQL, y gRPC, cada uno con sus propias fortalezas y casos de uso:

 La Transferencia de Estado Representacional ( REST) es el estilo de API más popular. Utiliza

un client-servermodelo en el que los clientes realizan solicitudes a recursos en un servidor
mediante métodos HTTP estándar ( GET, POST, PUT, DELETE). RESTfulLas API no tienen
estado, lo que significa que cada solicitud contiene toda la información necesaria para que
el servidor la procese, y las respuestas suelen serializarse como JSON o XML.

 El Protocolo Simple de Acceso a Objetos (SSO SOAP) utiliza XML para el intercambio de
mensajes entre sistemas. SOAPLas API están altamente estandarizadas y ofrecen funciones
integrales de seguridad, transacciones y gestión de errores, pero generalmente son más
complejas de implementar y usar que RESTfullas API.

 GraphQL es un estilo alternativo que ofrece una forma más flexible y eficiente de obtener y
actualizar datos. En lugar de devolver un conjunto fijo de campos para cada
recurso, GraphQLpermite a los clientes especificar exactamente los datos que necesitan, lo
que reduce la sobrecaptura y la subcaptura de datos. GraphQLLas API utilizan un único
punto final y un lenguaje de consulta fuertemente tipado para recuperar datos.

 gRPC es un estilo más reciente que utiliza búferes de protocolo para la serialización de
mensajes, lo que proporciona una forma eficiente y de alto rendimiento de comunicarse
entre sistemas. gRPCLas API se pueden desarrollar en diversos lenguajes de programación
y son especialmente útiles para microservicios y sistemas distribuidos.

En este módulo, nos centraremos en los ataques contra una API web RESTful . Sin embargo, las
vulnerabilidades demostradas también podrían existir en APIs desarrolladas con otros estilos
arquitectónicos.

Ataques de API

Debido a su versatilidad y ubicuidad, las API son un arma de doble filo. Si bien son un componente
crítico de la arquitectura de software moderna, también presentan una amplia superficie de
ataque. La naturaleza misma de las API, que facilitan el intercambio de datos y la comunicación
entre diversos sistemas, introduce vulnerabilidades, como Exposure of Sensitive Data[ errores de
configuración], Authentication and Authorization Issues[ errores de configuración Insufficient Rate
Limiting] Improper Error Handling, [errores de configuración] y otras configuraciones de seguridad
incorrectas.

Los 10 principales riesgos de seguridad de las API de OWASP

Para categorizar y estandarizar las vulnerabilidades de seguridad y las configuraciones incorrectas

que pueden enfrentar las API, OWASP ha creado el OWASP API Security Top 10 , una lista completa
de los riesgos de seguridad más críticos relacionados específicamente con las API:

Riesgo Descripción

API1:2023 - Autorización a nivel La API permite a los usuarios autenticados acceder a datos que
de objeto roto no están autorizados a ver.

API2:2023 - Autenticación Los mecanismos de autenticación de la API se pueden eludir o

interrumpida eludir, permitiendo el acceso no autorizado.

API3:2023 - Autorización de La API revela datos confidenciales a usuarios autorizados a los

nivel de propiedad de objeto que no deben acceder o les permite manipular propiedades
roto confidenciales.

API4:2023 - Consumo de La API no limita la cantidad de recursos que los usuarios

recursos sin restricciones pueden consumir.

API5:2023 - Autorización de La API permite que usuarios no autorizados realicen

nivel de función interrumpida operaciones autorizadas.

API6:2023 - Acceso sin La API expone flujos comerciales sensibles, lo que puede
restricciones a flujos comerciales generar posibles pérdidas financieras y otros daños.
sensibles

API7:2023 - Falsificación de La API no valida adecuadamente las solicitudes, lo que permite

solicitudes del lado del servidor a los atacantes enviar solicitudes maliciosas e interactuar con
recursos internos.

API8:2023 - Configuración La API sufre configuraciones de seguridad incorrectas, incluidas

incorrecta de seguridad vulnerabilidades que conducen a ataques de inyección.

API9:2023 - Gestión inadecuada La API no administra el inventario de versiones de forma

del inventario adecuada y segura.

API10:2023 - Consumo inseguro La API consume otra API de forma insegura, lo que genera
de API posibles riesgos de seguridad.

Este módulo se centrará en explotar todos estos riesgos de seguridad y comprender cómo
prevenirlos.
Introducción al laboratorio

A medida que avancemos en el módulo, practicaremos la identificación y explotación de cada uno

de los 10 principales riesgos de seguridad de la API de OWASP utilizando una RESTfulAPI web para
comprender completamente estas vulnerabilidades.

Mercado de comercio electrónico de Inlanefreight

Nuestro fiel cliente, Inlanefreight, se ha adentrado en el mundo de los marketplaces de comercio

electrónico con [nombre del proveedor] Inlanefreight E-Commerce Marketplace. El modelo de
negocio del marketplace permite a los clientes explorar y comprar productos ofrecidos por
proveedores. Cada proveedor está asociado a una empresa específica. El marketplace genera
ingresos cobrando una tarifa por cada producto que un cliente compra a un proveedor.

Para operar el mercado y facilitar las transacciones entre clientes y proveedores, Inlanefreight ha
desarrollado una API web multiusuario que utiliza Role-based Access Control( RBAC) como política
de control de acceso. A lo largo de las secciones, interactuaremos con la API utilizando diferentes
usuarios con distintos roles. Las credenciales asociadas al [Link] dominio
representan cuentas de proveedor, mientras que las que tienen [Link] se identifican
como cuentas de cliente.

Cada usuario que autentiquemos tendrá roles preasignados, determinados por el administrador
de Inlanefreight E-Commerce Marketplace. El administrador ha adoptado una convención de
nomenclatura sencilla para los roles: comparten el mismo nombre que los endpoints a los que
proporcionan acceso. Por ejemplo, si un usuario tiene el rol Suppliers_GetAll, implica que está
autorizado a interactuar con el endpoint que recupera todos los registros de proveedores (que, en
este caso, es /api/v1/suppliers).

Nuestro objetivo es informar al administrador de cualquier vulnerabilidad detectada Inlanefreight

E-Commerce Marketplace. Un informe detallado de todas las vulnerabilidades descubiertas
ayudará al administrador a tomar las medidas necesarias para proteger la API. Cada vulnerabilidad
se asignará a su debilidad CWE correspondiente .

Interfaz de usuario de la API de Swagger

Aunque el frontend Inlanefreight E-Commerce Marketplace aún se encuentra en desarrollo activo,

se puede acceder a la API web mediante una interfaz de usuario de Swagger en la /swagger ruta
(asegúrese de incluirla después del puerto de la máquina de destino generada). Utilizaremos esta
interfaz a lo largo del módulo para explorar y evaluar la seguridad de la API del marketplace, que
incluye más de 60 endpoints:
Las entidades clave que abarca el mercado incluyen Customers, Products, Supplier-
Companiesy Suppliers. También interactuaremos con otras entidades a medida que avancemos en
las secciones.
Autorización de nivel de objeto roto (1 Broken Object Level Authorization)

Las API web permiten a los usuarios solicitar datos o registros mediante el envío de diversos
parámetros, incluyendo identificadores únicos como Universally Unique Identifiers( UUIDs),
también conocidos como Globally Unique Identifiers( GUIDs), e identificadores enteros. Sin
embargo, no verificar de forma correcta y segura que un usuario posee la propiedad y el permiso
para ver un recurso específico object-level authorization mechanismspuede provocar la exposición
de datos y vulnerabilidades de seguridad.

Un punto final de API web es vulnerable a Broken Object Level Authorization( BOLA), también
conocido como Insecure Direct Object Reference( IDOR), si sus verificaciones de autorización
(implementadas en el nivel del código fuente) no logran garantizar correctamente que un usuario
autenticado tenga suficientes permisos o privilegios para solicitar y ver datos específicos o realizar
ciertas operaciones.

Omisión de autorización mediante clave controlada por el usuario

El punto final contra el que practicaremos es vulnerable a CWE-639: omisión de autorización a

través de una clave controlada por el usuario .

Scenario

El administrador Inlanefreight E-Commerce Marketplacenos ha proporcionado las

credenciales htbpentester1@[Link]:HTBPentester1 y quiere que evaluemos qué
vulnerabilidades de API puede explotar el usuario con sus roles asignados.

Dado que la cuenta pertenece a un proveedor, utilizaremos

el /api/v1/authentication/suppliers/sign-inpunto final para iniciar sesión y obtener un JWT:
Para autenticarnos con el JWT, lo copiaremos de la respuesta y haremos clic en el Authorizebotón.
Observe el icono del candado, actualmente desbloqueado, que indica que no estamos
autenticados. A continuación, pegaremos el JWT en el Valuecampo de texto de la Available
authorizationsventana emergente y haremos clic en Authorize. Al finalizar, el icono del candado
estará completamente bloqueado, confirmando nuestra autenticación.
Al examinar los puntos finales dentro del grupo Proveedores (observe cómo tienen un candado en
su extremo derecho, lo que indica que se requiere autenticación), notaremos uno
llamado /api/v1/suppliers/current-user:

Los endpoints que contienen current-user en su ruta indican que utilizan el JWT del usuario
autenticado para realizar la operación especificada, que en este caso es recuperar los datos del
usuario actual. Al invocar el endpoint, recuperaremos la empresa de nuestro usuario
actual ID, b75a7c76-e149-4ca7-9c55-d9fc4ffa87be un Guid valor:

Recuperemos entonces los roles de nuestro usuario actual. Tras invocar el /api/v1/roles/current-
userendpoint, este responde con el rol SupplierCompanies_GetYearlyReportByID:
En el Supplier-Companiesgrupo, encontramos un endpoint relacionado con el
rol SupplierCompanies_GetYearlyReportByID que acepta un parámetro GET /api/v1/supplier-
companies/yearly-reports/{ID}:

Al expandirlo, notaremos que requiere el rol SupplierCompanies_GetYearlyReportByID y acepta

el parámetro ID como un entero y no un Guid:
Si usamos 1como ID, recibiremos un informe anual perteneciente a una empresa con el
ID f9e58492-b594-4d82-a4de-16e4f230fce1, que no es al que pertenecemos, b75a7c76-e149-
4ca7-9c55-d9fc4ffa87be:

Al probar otras identificaciones, aún podemos acceder a informes anuales de otras empresas
proveedoras, lo que nos permite acceder a datos comerciales potencialmente confidenciales:
Además, podemos abusar masivamente de la BOLA vulnerabilidad y obtener los primeros 20
informes anuales de las empresas proveedoras:

Los únicos cambios que debemos realizar al comando cURL copiado desde la Swaggerinterfaz son
usar un Bash for-loopcon variable interpolation, agregar una nueva línea después de cada
respuesta usando el indicador -w "\n", silenciar el progreso usando el indicador -sy canalizar la
salida a jq :
AGB@htb[/htb]$ for ((i=1; i<= 20; i++)); do

Prevención

Para mitigar la BOLA vulnerabilidad, el endpoint /api/v1/supplier-companies/yearly-reports debe

implementar una verificación (a nivel de código fuente) para garantizar que los usuarios
autorizados solo puedan acceder a los informes anuales asociados a su empresa afiliada. Esta
verificación implica comparar el companyID campo del informe con el del proveedor
autenticado companyID. El acceso solo debe concederse si estos valores coinciden; de lo contrario,
se deniega la solicitud. Este enfoque mantiene eficazmente la segregación de datos entre los
informes anuales de las empresas proveedoras.

Comandos:

Instalar jq

apt install jq

En el endpoint o punto final Authentication, Ingresamos las credenciales correspondientes para

loguearnos:
Al loguearnos, en la respuesta nos genera un JWT, el cual copiamos sin las comillas.

Subimos hasta el Authorize con el candado abierto (Significa que aún no estas logueados)
Al presionar en el candado (Authorize) nos pedirá el token JWT que se generó anteriormente al
ingresar las credenciales.

Una vez ingresado el icono del candado se vera cerrado, como se ve a continuación.

Con todo lo anterior estaremos logueados correctamente.

Todo endpoint o punto final (en este ejemplo Suppliers) que sea current-user, al consultarlo
veremos siempre la información del usuario actual logueado.

Al presionar en ejecutar (Execute) la respuesta del servidor nos mostrara la información del
usuario actual, información como ID, CompanyID, name, email y phoneNumber.
Solución

/api/v1/suppliers/quarterly-reports/{ID}

Al expandirlo, notaremos que requiere el rol Suppliers_GetQuarterlyReportByID y acepta

el parámetro ID como un entero y no un Guid:

Al probar otras identificaciones (1 o 2, etc), aún podemos acceder a informes (reportes) anuales de
otras empresas proveedoras, lo que nos permite acceder a datos comerciales potencialmente
confidenciales:
Ahora creemos un for-loop en bash para traer información de múltiples reportes automáticamente
y de esta forma no hacerlo manualmente uno por uno.

Para ello debemos copiar el curl

Código de script de bash

for ((i=1; i<= 32; i++)); do

curl -s -w "\n" -X 'GET' \
'[Link] \
-H 'accept: application/json' \
-H 'Authorization: Bearer
eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8y
MDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1laWRlbnRpZmllciI6Imh0YnBlbnRlc3RlcjJAcGVudGVz
dGVyY29tcGFueS5jb20iLCJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3dzLzIwMDgvMDYv
aWRlbnRpdHkvY2xhaW1zL3JvbGUiOlsiU3VwcGxpZXJDb21wYW5pZXNfR2V0WWVhcmx5UmVwb
3J0QnlJRCIsIlN1cHBsaWVyc19HZXRRdWFydGVybHlSZXBvcnRCeUlEIl0sImV4cCI6MTc1NDcxNTM3
MiwiaXNzIjoiaHR0cDovL2FwaS5pbmxhbmVmcmVpZ2h0Lmh0YiIsImF1ZCI6Imh0dHA6Ly9hcGkua
W5sYW5lZnJlaWdodC5odGIifQ.0Ihdlhyew5A4R6PWFewatBGdkIixTyhM1sadsMCM6y0IyrUfSB8-
APw8b9ssT2gPBFiQ6p8BeiLDGT97gGR74Q' | jq
done

Los únicos cambios que debemos realizar al comando cURL copiado desde la interfaz Swagger,
agregar una nueva línea después de cada respuesta usando el indicador -w "\n", silenciar el
progreso usando el indicador -s y canalizar la salida a jq (apt install jq).

Nota: mirar el cuadro anterior y fijarse que todo lo que este en rojo este correctamente en tu for-
loop, no olvidar poner al final el (done) y en la url el ($i'').

Otras notas personales (NO CPTS)

[Link] (Descargar diccionarios para FUZZ de APIs)

[Link]

Del inglés al español:

Customers: Clientes
Current: Actual
Current users: Usuario Actual
Suppliers: Proveedores
Editar JWT Online: [Link]

APIS y JWT hacking - POSTMAN: [Link]

Autenticación rota – (2 Broken Authentication)

La autenticación es un pilar fundamental de la seguridad de las API web. Estas utilizan diversos
mecanismos de autenticación para garantizar la confidencialidad de los datos. Una API se ve
afectada Broken Authentication si alguno de sus mecanismos de autenticación puede ser eludido o
evadido.

Restricción inadecuada de intentos excesivos de autenticación

El punto final contra el que practicaremos es vulnerable a CWE-307: Restricción inadecuada de

intentos de autenticación excesivos .

Scenario

El administrador Inlanefreight E-Commerce Marketplace nos ha proporcionado las

credenciales htbpentester3@[Link]:HTBPentester3 y quiere que evaluemos qué
vulnerabilidades de API puede explotar el usuario con sus roles asignados.

Dado que la cuenta pertenece a un cliente, utilizaremos

el /api/v1/authentication/customers/sign-in punto final para obtener un JWT y luego nos
autenticaremos con él:

Al invocar el /api/v1/customers/current-user punto final, recuperamos la información de nuestro

usuario actualmente autenticado:
El /api/v1/roles/current-user punto final revela que al usuario se le asignan tres
roles: Customers_UpdateByCurrentUser, Customers_Get, y Customers_GetAll:

Customers_GetAll nos permite utilizar el /api/v1/customers punto final, que devuelve los registros
de todos los clientes:
Aunque el punto final sufre Broken Object Property Level Authorization(lo cual abordaremos en la
próxima sección) porque expone información confidencial sobre otros clientes,
como email, phoneNumber, y birthDate, no nos permite directamente secuestrar ninguna otra
cuenta.

Al expandir el /api/v1/customers/current-user PATCH endpoint, descubrimos que nos permite

actualizar nuestros campos de información, incluida la contraseña de la cuenta:
Si proporcionamos una contraseña débil como "pass", la API rechaza la actualización, indicando
que las contraseñas deben tener al menos seis caracteres:

El mensaje de validación proporciona información valiosa, ya que revela que la API utiliza una
política de contraseñas débil, que no garantiza la seguridad criptográfica de las contraseñas. Si
intentamos configurar la contraseña como '123456', observaremos que la API ahora muestra true
el estado de éxito, lo que indica que se realizó la actualización.
Dado que la API utiliza una política de contraseñas débil, es posible que otras cuentas de clientes
hayan usado contraseñas criptográficamente inseguras al registrarse. Por lo tanto, realizaremos
pruebas de fuerza bruta de contraseñas contra los clientes que utilicen ffuf.

Primero, necesitamos obtener el mensaje (de error) que

el /api/v1/authentication/customers/sign-in punto final devuelve cuando se le proporcionan
credenciales incorrectas, que en este caso es "Credenciales no válidas":

En lugar de atacar a los 107 clientes, el administrador Inlanefreight E-Commerce Marketplacenos

ha proporcionado los correos electrónicos de tres objetivos de alto valor (que debemos guardar en
un archivo):

 OlawaleJones@[Link]

 IsabellaRichardson@[Link]

 WenSalazar@[Link]

Para la lista de palabras de contraseña, utilizaremos xato-net-10-million-passwords-

10000 de SecLists .

Dado que estamos analizando dos parámetros simultáneamente (el correo electrónico y la
contraseña), necesitamos usar la -w bandera de ffuf y asignar las palabras clave EMAIL y PASS a las
listas de palabras de los correos electrónicos y las contraseñas de los clientes, respectivamente.
Una vez ffuf finalizado, descubriremos que la contraseña de IsabellaRichardson@[Link]
es qwerasdfzxcv:
AGB@htb[/htb]$ ffuf -w /opt/useful/seclists/Passwords/xato-net-10-million-passwords-
[Link]:PASS -w [Link]:EMAIL -u
[Link] -X POST -H "Content-Type:
application/json" -d '{"Email": "EMAIL", "Password": "PASS"}' -fr "Invalid Credentials" -t 100

Ahora que hemos forzado la contraseña, podemos usar

el /api/v1/authentication/customers/sign-in punto final con las
credenciales IsabellaRichardson@[Link]:qwerasdfzxcv para obtener un JWT de Isabella y ver
toda su información confidencial en Inlanefreight E-Commerce Marketplace.

OTP de fuerza bruta y respuestas a preguntas de seguridad

Las aplicaciones permiten a los usuarios restablecer sus contraseñas solicitando un One Time
Password (OTP) enviado a un dispositivo propio o respondiendo a una pregunta de seguridad
elegida durante el registro. Si la fuerza bruta de las contraseñas no es viable debido a políticas de
contraseñas robustas, podemos intentar forzar las OTP o las respuestas a las preguntas de
seguridad, siempre que tengan baja entropía o sean fáciles de adivinar (además de que no se
implementa la limitación de velocidad).

Prevención

Para mitigar la Broken Authentication vulnerabilidad, el /api/v1/authentication/customers/sign-

in endpoint debe implementar una limitación de velocidad para evitar ataques de fuerza bruta.
Esto se puede lograr limitando el número de intentos de inicio de sesión desde una sola dirección
IP o cuenta de usuario dentro de un plazo específico.

Además, la API web debe implementar una política de contraseñas robusta para las credenciales
de usuario (incluyendo clientes y proveedores) durante el registro y las actualizaciones,
permitiendo únicamente contraseñas criptográficamente seguras. Esta política debe incluir:
 1. Minimum password length(por ejemplo, al menos 12 caracteres)

2. Complexity requirements(por ejemplo, una combinación de letras mayúsculas y

minúsculas, números y caracteres especiales)

3. Prohibition of commonly used or easily guessable passwords (como los que se encuentran
en bases de datos de contraseñas filtradas)

4. Enforcement of password history to prevent reuse of recent passwords

5. Regular password expiration and mandatory changes

Además, el punto final de la API web debe implementar autenticación multifactor (MFA) para
mayor seguridad, solicitando un OTPantes de autenticar completamente a los usuarios.
Solución:

Con las credenciales que nos dieron (htbpentester3@[Link]:HTBPentester3) nos

logueamos en (/api/v1/authentication/customers/sign-in) en Authorize pegamos el JWT.

Enviamos el codigo OTP al correo del usuario en el endpoint

(/api/v1/authentication/customers/passwords/resets/email-otps) esto con el fin realizar el
posterior ataque de fuerza bruta de para adivinar el OTP de 4 dígitos (Números)

Interceptamos con BurpSuite la solicitud del endpoint

(/api/v1/authentication/customers/passwords/resets)

Ejecutamos:

Capturamos y enviamos al intruder, donde enviaremos el ataque de fuerza bruta de tipo numerico:
Luego con el correo y nuevo password nos logueamos en
(/api/v1/authentication/customers/sign-in)

Y vemos los datos de la tarjeta del usuario en (/api/v1/customers/payment-options/current-

user):

Recuerden que en (/api/v1/customers/current-user) podemos validar el numero de caracteres

requeridos para las credenciales.
Autorización de nivel de propiedad de objeto roto (3 Broken Object Property Level
Authorization)

Broken Object Property Level Authorizationes una categoría de vulnerabilidades que abarca dos
subclases: Excessive Data Exposurey Mass Assignment.

Un punto final de API es vulnerable Excessive Data Exposuresi revela datos confidenciales a
usuarios autorizados a los que no deberían tener acceso.

Por otro lado, un punto final de API es vulnerable Mass Assignmentsi permite a los usuarios
autorizados manipular propiedades sensibles de objetos más allá de su alcance autorizado, lo que
incluye modificar, agregar o eliminar valores.

Exposición de información confidencial debido a políticas incompatibles

El primer punto final contra el que practicaremos es vulnerable a CWE-213 .Exposure of Sensitive
Information Due to Incompatible Policies

SCENA

El administrador Inlanefreight E-Commerce Marketplace nos ha proporcionado las

credenciales htbpentester4@[Link]:HTBPentester4 y quiere que evaluemos qué
vulnerabilidades de API puede explotar el usuario con sus roles asignados.

Después de invocar /api/v1/authentication/customers/sign-in para iniciar sesión como cliente y

obtener un JWT, el /api/v1/roles/current-user punto final muestra que tenemos los
roles Suppliers_Gety Suppliers_GetAll:
Es habitual que los mercados de comercio electrónico permitan a los clientes ver los detalles de los
proveedores. Sin embargo, tras invocar el /api/v1/suppliers GET endpoint, observamos que la
respuesta incluye no solo los campos id, companyID, y, name sino también los campos email
y phoneNumber de los proveedores:

Estos campos sensibles no deben exponerse a los clientes, ya que esto les permite eludir por
completo el mercado y contactar directamente con los proveedores para comprar productos (con
descuento). Además, esta vulnerabilidad beneficia económicamente a los proveedores,
permitiéndoles generar mayores ingresos sin pagar la tarifa del mercado. Sin embargo, para las
partes interesadas de [nombre del mercado] Inlanefreight E-Commerce Marketplace, esto afectará
negativamente sus ingresos.

Prevención

Para mitigar la vulnerabilidad Excessive Data Exposure, el /api/v1/suppliers endpoint solo debe
devolver los campos necesarios desde la perspectiva del cliente. Esto se puede lograr devolviendo
un Objeto de Transferencia de Datos (DTO) de respuesta específico que incluya únicamente los
campos destinados a la visibilidad del cliente, en lugar de exponer todo el modelo de dominio
utilizado para la interacción con la base de datos.

Modificación controlada incorrectamente de atributos de objetos determinados dinámicamente

El segundo punto final de API con el que practicaremos es vulnerable a CWE-915 .Improperly
Controlled Modification of Dynamically-Determined Object Attributes
SCENARIO

El administrador Inlanefreight E-Commerce Marketplace nos ha proporcionado las

credenciales htbpentester6@[Link]:HTBPentester6 y quiere que evaluemos qué
vulnerabilidades de API puede explotar el usuario con sus roles asignados.

Después de invocar /api/v1/authentication/suppliers/sign-in para iniciar sesión como Proveedor y

obtener un JWT, el /api/v1/roles/current-user punto final muestra que tenemos los
roles SupplierCompanies_Updatey SupplierCompanies_Get:

El /api/v1/supplier-companies/current-user punto final muestra que la empresa proveedora a la

que pertenece el proveedor actualmente autenticado, 'PentesterCompany', tiene
el isExemptedFromMarketplaceFee campo establecido en 0, lo que equivale a false:
Por lo tanto, esto implica que Inlanefreight E-Commerce Marketplace'PentesterCompany' cobrará
una tarifa de mercado por cada producto que venda.

Al expandir el endpoint /api/v1/supplier-companies PATCH, observamos que requiere

el SupplierCompanies_Updaterol, establece que el proveedor que realiza la actualización debe ser
un miembro del personal y permite enviar un valor para el isExemptedFromMarketplaceFeecampo:
Establezcamos lo en 1, de modo que 'PentesterCompany' no se incluya entre las empresas
obligadas a pagar la tarifa del mercado; después de invocarlo, el punto final devuelve un mensaje
de éxito:

Luego, al verificar nuevamente la información de nuestra empresa usando /api/v1/supplier-

companies/current-user, notaremos que el isExemptedFromMarketplaceFee campo se ha
convertido en 1:
Dado que el endpoint permite erróneamente a los proveedores actualizar el valor de un campo al
que no deberían tener acceso, esta vulnerabilidad permite a las empresas proveedoras generar
más ingresos por todas las ventas realizadas a través de [ Inlanefreight E-Commerce Marketplace
nombre del sitio web], ya que no se les cobrará una tarifa de mercado. Sin embargo, de forma
similar a las repercusiones de la Exposure of Sensitive Information Due to Incompatible Policies
vulnerabilidad anterior, los ingresos de las partes interesadas Inlanefreight E-Commerce
Marketplace se verán afectados negativamente.

Prevención

Para mitigar la Mass Assignment vulnerabilidad, el /api/v1/supplier-companies PATCH endpoint

debe impedir que los invocadores actualicen campos sensibles. De forma similar al
direccionamiento Excessive Data Exposure, esto se puede lograr implementando una solicitud
dedicada DTO que incluya solo los campos que los proveedores deben modificar.