¿Cómo iniciar un

Pentesting en
una API?

by Jorge Jara*

*Desarrollador de Software y Pentester de Open-Sec enfocado en

aplicaciones y pruebas de seguridad bajo la práctica de DevSecOps.
Cuenta con las certificaciones eJPT y eWPT. Trainer para cursos de
Seguridad Ofensiva a nivel de infraestructura y aplicaciones. (https://
www.linkedin.com/in/jorlujarlin/)

Artículo #10
Hoy en día muchas aplicaciones implementan o hacen uso de APIs para interactuar y compartir
información con otras aplicaciones. El crecimiento constante de las APIs también genera un
crecimiento de los riesgos y amenazas de seguridad; por lo tanto, las APIs también son vulnerables al
abuso, manipulación y divulgación de información. Es aquí donde entran en juego las pruebas de
seguridad en APIs para identificar sus vulnerabilidades.

Las APIs (Interfaz de programación de aplicaciones) son un conjunto de definiciones y protocolos que
se usan para integrar distintos tipos de software, estos protocolos van a definir cómo se comunican
(mediante solicitudes y respuestas) las aplicaciones para transferir datos. Las pruebas de pentest en
una API se pueden realizar en una amplia variedad de protocolos como: RPC, SOAP y REST. Los tipos
de servicios API más utilizadas hoy en día son:

● API SOAP (XML): Es un protocolo que nos permitirá realizar servicios web sin estado, a través de
TCP, el cliente y el servidor intercambian mensajes mediante XML. La documentación usa el
formato WSDL y generalmente se encuentran en rutas como:
https://api.example.com/api/?wsdl

● API REST (JSON): Son las APIs más utilizadas actualmente. El cliente envía las solicitudes al
servidor como datos y el servidor utiliza esta entrada del cliente para iniciar funciones internas y
genera los datos de salida hacia el cliente. Los datos transferidos por lo general utilizan el
formato JSON.

● API GRAPHQL: Es un lenguaje de consultas para API que prioriza brindar a los clientes solo los
datos que se solicitan. GraphQL está diseñado para hacer que las APIs sean rápidas, flexibles y
fáciles de usar para los desarrolladores. GraphQL brinda la facilidad para los desarrolladores de
crear solicitudes que extraen datos de múltiples fuentes de datos en una sola llamada a la API.

Principales vulnerabilidades encontradas en una API

OWASP ha publicado una lista de las diez principales amenazas para las APIs que podemos consultar
en su API Security Top 10. Dentro de estas incluiremos las más comunes encontradas durante las
pruebas de pentest realizadas, las cuales son:

● Exposición excesiva de datos

Por lo general los programadores tienden a proporcionar la mayor cantidad de datos en las
respuestas de la API de lo que realmente se requiere, delegando posteriormente a la aplicación del
cliente la responsabilidad de filtrar y mostrar la información al usuario. Esto da como resultado una
exposición excesiva de datos, lo que puede conducir a un abuso de la API. 

● Configuración de seguridad incorrecta

Los encabezados HTTP mal configurados, mensajes de error que muestran o exponen información
confidencial, el almacenamiento en la nube abierta y otros problemas similares son ejemplos de este
tipo de vulnerabilidades. Los atacantes pueden utilizarlos para obtener más información sobre los
componentes de la API y luego utilizar estos conocimientos para aprovecharse de la mala
configuración como parte de su ataque.

● Pérdida del nivel de Autorización

Los usuarios de la API pueden estar autorizados a hacer demasiadas cosas, lo cual puede provocar la
exposición de los datos. Las políticas de control de acceso con jerarquías y grupos complicados y una
separación poco clara de los roles pueden generar errores o pérdida de autorización. Los atacantes
pueden obtener acceso a estas funciones administrativas y explotar sus usos.

● Gestión inadecuada de activos

Generalmente se produce cuando no hay un seguimiento adecuado de las APIs actuales, las de
producción así como también de las que han quedado obsoletas. Las versiones de APIs
desactualizadas y los endpoints (puntos finales) expuestos aumentan los niveles de exposición de la
API.

1
● Inyección

En un ataque de inyección, los atacantes envían comandos especializados a la API que pueden
revelar datos o ejecutar acciones inesperadas. La inyección SQL, la inyección de comandos y la
inyección NoSQL son los tipos de fallas de inyección más comunes. Estos ataques pueden permitir el
acceso a cualquier información sin autorización.

Las pruebas de penetración de API consisten en una serie de procesos para tratar de identificar y
probar las vulnerabilidades de seguridad que puedan existir en una API. Antes de iniciar este proceso
debemos tener muy en claro cuál es nuestra superficie de ataque y posteriormente iniciar las
pruebas de pentest en la API.

Identificación de la Superficie de Ataque

Es muy importante identificar y comprender la funcionalidad de la API, para esto debemos

interactuar con la propia API e identificar sus endpoints, los parámetros y encabezados que son
transferidos, así como analizar los mensajes de respuesta y el comportamiento de la API. Por lo
general, las APIs no tienen un frontend por lo que debemos interactuar con los endpoints y los
recursos que provee la propia API.

Podemos hacer uso de los siguientes métodos para recopilar información de la API que estamos
evaluando:

● Analizar Metadatos: Podemos recurrir a la documentación o repositorios de los desarrolladores

o a través de información expuesta en: api-docs.json, WSDL, Swagger, API-Blueprint, ioDocs y
otros..

● Descubrimiento (Discovery): Haciendo uso de herramienta tipo proxy como ZAP Proxy o
BurpSuite podemos grabar el tráfico del consumo de la API para analizar a detalle cada uno de los
encabezados, datos y parámetros transferidos en cada solicitud.

● Búsqueda con diccionarios: Haciendo uso de herramientas para realizar pruebas de ataque de
diccionario podemos identificar endpoints que se pueden estar utilizando en la API. Estas
herramientas muchas veces nos ayudan a detectar endpoints que por lo general no se
encuentran expuestos en la documentación. También podemos realizar pruebas manuales de
endpoints más comunes, por ejemplo:

https://www.example.com/api/

https://www.example.com/api/login

https://api.example.com/api/?wsdl

https://api.example.com/api/?wsdl

https://www.example.com/api/v1

https://www.example.com/api/v2

https://www.example.com/api/v1/login

https://www.example.com/api/v2/login

https://test.example.com/api/v1

https://test.example.com/api/v2

2
Principales pruebas para realizar en una API

Una vez que hemos identificado la superficie de ataque podemos realizar las siguientes pruebas para
detectar vulnerabilidades en una API.

● API Fuzzing

Esta técnica consiste en proporcionar datos inválidos, aleatorios e inesperados para identificar
vulnerabilidades relacionadas con la validación de entradas y el manejo de errores. Debemos probar
todos los valores posibles para cada entrada de datos que proporciona la API, números fuera de
rango, datos en formatos no válidos, fechas inválidas y otros. Luego debemos comprobar la
respuesta brindada para identificar que la API brinde los mensajes de error adecuados y no realice
ninguna divulgación de información.

● Pruebas de Ataques de Inyección

Las fallas de inyección, como SQL, NoSQL, Inyección de Comandos y otros, ocurren cuando se envían
datos que no son de confianza a un intérprete como parte de un comando o consulta. Debemos
proporcionar datos maliciosos a la API a través de cualquier dato de entrada disponible, esperando
que sean enviados a algún intérprete. Las fallas de inyección son muy comunes y se encuentran a
menudo en consultas SQL, LDAP o NoSQL, comandos del sistema operativo, analizadores XML y ORM.
Para esta técnica debemos haber identificado el funcionamiento de la API, y según las tecnologías
empleadas debemos realizar pruebas de inyección que correspondan. Podemos ayudarnos de
herramientas de tipo escáneres y fuzzers para identificar estas vulnerabilidades.

● Pruebas de ataques con Contenido Malicioso

Si la API brinda opciones de subir archivos o imágenes podemos intentar subir archivos ejecutables,
scripts o webshells. Debemos intentar cargar archivos que no dañen la información pero que permita
validar el correcto manejo del proceso de carga de archivos y validar si se obtienen los mensajes de
error adecuados.

● Prueba de Configuración TLS

En esta prueba debemos verificar que la API implemente el protocolo de seguridad HTTPS haciendo
uso de TLS. En ocasiones algunas APIs todavía permiten el uso de HTTP. Debemos confirmar que la
API no permita el consumo vía HTTP, Validar los certificados TLS utilizados: fecha de expiración,
validez, auto firmado, y los algoritmos empleados.

● Pruebas de manejo de Autenticación

En estas pruebas debemos verificar el adecuado manejo del proceso de autenticación para acceder a
los recursos que proporciona la API. Debemos comprobar cada endpoint para identificar cuál de ellos
requiere autenticación y cuáles no lo requieren, realizar pruebas para verificar si los tokens de sesión
son reutilizados, si se hace uso de tokens secuenciales, comprobar el tiempo de vigencia o la
caducidad de los tokens sean adecuados, e identificar cómo se transmiten los tokens (a través de la
URL, como parámetros del encabezado o como parte de la data).

● Probar CORS

Es una de las pruebas que siempre debemos realizar para comprobar si la configuración de CORS de
la API es correcta, ya que si permite concretar una solicitud con credenciales desde otro dominio,
puede causar mucho daño a través de CSRF de víctimas autenticadas.

Podemos probar la configuración de CORS de una API revisando los encabezados de CORS en la
respuesta de la API. Los siguientes encabezados pueden determinar si la API admite CORS:

Access-Control-Allow-Origin

Access-Control-Allow-Headers

3
Access-Control-Allow-Methods

● Pruebas IDOR

Otra de las pruebas que debemos realizar en una API es la Referencia Directa a Objetos de forma
Insegura (IDOR). Es un tipo de vulnerabilidad de control de acceso que surge cuando una aplicación
utiliza la entrada proporcionada por el usuario para acceder a los objetos directamente. Las
verificaciones de autorización a nivel de objeto deben considerarse en todas las funciones que
acceden a una fuente de datos mediante la entrada del usuario.

Estas pruebas podemos realizarlas en parámetros que son predecibles y utilizados como
identificadores, debemos enviar algunos datos auto generados para obtener acceso al sistema o
información sin autorización o invocar a métodos u operaciones a los que no se debería tener acceso.

● Pruebas SSRF

Si identificamos que la API realiza el envío de parámetros URL debemos realizar pruebas de
vulnerabilidad de falsificación de solicitud del lado del servidor (SSRF). Esta es unas de las
vulnerabilidades que actualmente se han agregado al OWASP API Security Top 10 2023 RC. Debemos
encontrar un endpoint de la API que reciba una URL como parámetro y luego acceda a la URL
proporcionada. Una explotación exitosa podría conducir a la enumeración de servicios internos (por
ejemplo, escaneo de puertos) o divulgación de información, pasando por alto los firewalls u otros
mecanismos de seguridad. Por ejemplo, si hemos encontrado un endpoint vulnerable a SSRF en el
parámetro url y quisiéramos saber si el servidor API puede tener SSH habilitado en la red interna,
podríamos enviar la siguiente url y comprobar la respuesta para ver si nos devuelve un banner SSH.

https://api.example.com/?url=http://127.0.0.1:22

Otro ejemplo, puede ser reemplazando el protocolo http:// con file://, lo que permite acceder a
los archivos en el servidor. Podemos realizar pruebas enviando parámetros como:

https://api.example.com/?url=file:///etc/passwd

https://api.example.com/?url=file://C:/boot.ini

● Pruebas de Evasión de Rate-Limit

Generalmente las API están limitadas a una determinada cantidad de solicitudes que podemos
realizar, superado este límite debemos esperar o realizar un pago adicional para continuar
consumiendo la API. Existen algunos métodos que podemos utilizar para tratar de evadir este límite
de consumo dependiendo del tipo de control aplicado.

Evasión de Rate-Limit con Header: Podemos tratar de eludir la limitación haciendo uso de algunos
encabezados en las solicitudes, por ejemplo:

X-Host: 127.0.0.1

X-Originating-IP: 127.0.0.1

X-Forwarded-For: 127.0.0.1

X-Remote-IP: 127.0.0.1

X-Forwarded-Host: 127.0.0.1

X-Remote-Addr: 127.0.0.1

X-Client-IP: 127.0.0.1

# También Podemos usar doble header: X-Forwarded-For

X-Forwarded-For:

4
X-Forwarded-For: 127.0.0.1

# Podemos cambiar la IP cuando la petición se vuelva a bloquear.

# A veces es añadir múltiples cabeceras puede ayudar a evadir un Rate-Limit

# También debemos probar cambiando el User-Agent, Cookies, y cualquier otro

parámetro que pueda ser utilizado como identificación.

Añadiendo Parámetros extras a la ruta

Si el límite está en la ruta: /resetpwd, debemos intentar consultas a la API con el siguiente
parámetro: /resetpwd?someparam=1

Evadir el Rate-Limit con algunos caracteres:

Podemos evadir el límite de consumo añadiendo algunos caracteres especiales al endpoint como:
%00, %0d, %0a, %0d, %09, %0C, %20, %2e

Por ejemplo:

/api/v1/user?code=1234%0a

/api/v1/user?code=1234%2e

/api/v1/user?code=1234%0C