Las APIs (Application Programming Interfaces) Interfaces de Programación de Aplicaciones, permiten que los sistemas de software y las aplicaciones se comuniquen y compartan datos. Las pruebas de API son importantes, ya que sus vulnerabilidades pueden comprometer aspectos fundamentales de la confidencialidad, integridad y disponibilidad de un sitio web.
Todos los sitios web dinámicos se componen de API, por lo que las vulnerabilidades web clásicas, como la inyección SQL, podrían clasificarse como pruebas de API. En este tema, te enseñaremos a probar API que no se utilizan completamente en el frontend del sitio web, centrándonos en las API RESTful y JSON. También te enseñaremos a detectar vulnerabilidades de contaminación de parámetros del lado del servidor que podrían afectar a las API internas.
Para ilustrar la superposición entre las pruebas de API y las pruebas web generales, hemos creado un mapeo entre nuestros temas existentes y el OWASP API Security Top 10 2023 .
Reconocimiento de API
Para comenzar a probar la API, primero debes encontrar la mayor cantidad de información posible sobre la API para descubrir su superficie de ataque.
Para empezar, debe identificar los puntos finales de la API. Estos son los lugares donde una API recibe solicitudes sobre un recurso específico en su servidor. Por ejemplo, considere la siguiente GET solicitud:
GET /api/books HTTP/1.1
Host: example.com
El punto final de la API para esta solicitud es /api/books. Esto genera una interacción con la API para recuperar una lista de libros de una biblioteca. Otro punto final de la API podría ser, por ejemplo, /api/books/mystery, que recuperaría una lista de libros de misterio.
Una vez identificados los endpoints, debe determinar cómo interactuar con ellos. Esto le permite generar solicitudes HTTP válidas para probar la API. Por ejemplo, debería buscar información sobre lo siguiente:
- Los datos de entrada que procesa la API, incluidos los parámetros obligatorios y opcionales.
- Los tipos de solicitudes que acepta la API, incluidos los métodos HTTP y formatos multimedia admitidos.
- Límites de velocidad y mecanismos de autenticación.
Documentación de la API
Escaneo DAST automatizado sin límites. Basado en la tecnología Burp en la que sus equipos de seguridad ya confían..
Conocer …
Las API generalmente están documentadas para que los desarrolladores sepan cómo usarlas e integrarlas.
La documentación puede ser legible tanto para humanos como para máquinas. La documentación legible para humanos está diseñada para que los desarrolladores comprendan cómo usar la API. Puede incluir explicaciones detalladas, ejemplos y escenarios de uso. La documentación legible para máquinas está diseñada para ser procesada por software para automatizar tareas como la integración y validación de la API. Está escrita en formatos estructurados como JSON o XML.
La documentación de la API suele estar disponible públicamente, sobre todo si está destinada a desarrolladores externos. En ese caso, comience siempre su análisis revisando la documentación.
Descubriendo la documentación de la API
Incluso si la documentación de la API no está disponible abiertamente, es posible que puedas acceder a ella explorando aplicaciones que usan la API.
Para ello, puede usar Burp Scanner para rastrear la API. También puede explorar las aplicaciones manualmente con el navegador de Burp. Busque puntos finales que puedan hacer referencia a la documentación de la API, por ejemplo:
/api/swagger/index.html/openapi.json
Si identifica un punto final para un recurso, asegúrese de investigar la ruta base. Por ejemplo, si identifica el punto final del recurso /api/swagger/v1/users/123, debería investigar las siguientes rutas:
/api/swagger/v1/api/swagger/api
También puede utilizar una lista de rutas comunes para encontrar documentación utilizando Intruder.
Uso de documentación legible por máquina
Puede utilizar una variedad de herramientas automatizadas para analizar cualquier documentación de API legible por máquina que encuentre.
Puedes usar Burp Scanner para rastrear y auditar la documentación de OpenAPI, o cualquier otra documentación en formato JSON o YAML. También puedes analizar la documentación de OpenAPI con OpenAPI Parser BApp.
También puede utilizar una herramienta especializada para probar los puntos finales documentados, como Postman o SoapUI .
Identificación de puntos finales de API
También puedes recopilar mucha información explorando las aplicaciones que usan la API. Esto suele ser útil incluso si tienes acceso a la documentación de la API, ya que a veces esta puede ser inexacta o estar desactualizada.
Puede utilizar Burp Scanner para rastrear la aplicación y luego investigar manualmente la superficie de ataque interesante utilizando el navegador de Burp.
Al explorar la aplicación, busque patrones que sugieran puntos de conexión de API en la estructura de la URL, como /api/. También busque archivos JavaScript. Estos pueden contener referencias a puntos de conexión de API que no haya activado directamente a través del navegador web. Burp Scanner extrae automáticamente algunos puntos de conexión durante los rastreos, pero para una extracción más exhaustiva, utilice la aplicación JS Link Finder BApp. También puede revisar manualmente los archivos JavaScript en Burp.
Interactuar con los puntos finales de la API
Una vez identificados los endpoints de la API, interactúe con ellos mediante Burp Repeater y Burp Intruder. Esto le permite observar el comportamiento de la API y descubrir nuevas áreas de ataque. Por ejemplo, podría investigar cómo responde la API al cambiar el método HTTP y el tipo de medio.
Al interactuar con los puntos finales de la API, revise atentamente los mensajes de error y otras respuestas. A veces, estos incluyen información que puede usar para crear una solicitud HTTP válida.
Identificación de métodos HTTP compatibles
El método HTTP especifica la acción que se realizará en un recurso. Por ejemplo:
GET– Recupera datos de un recurso.PATCH– Aplica cambios parciales a un recurso.OPTIONS– Recupera información sobre los tipos de métodos de solicitud que se pueden utilizar en un recurso.
Un endpoint de API puede admitir diferentes métodos HTTP. Por lo tanto, es importante probar todos los métodos posibles al investigar endpoints de API. Esto puede permitirle identificar funcionalidades adicionales del endpoint, lo que aumenta la vulnerabilidad a ataques.
Por ejemplo, el punto final /api/taskspuede admitir los siguientes métodos:
GET /api/tasks– Recupera una lista de tareas.POST /api/tasks– Crea una nueva tarea.DELETE /api/tasks/1– Elimina una tarea.
Puede utilizar la lista de verbos HTTP incorporada en Burp Intruder para recorrer automáticamente una variedad de métodos.
Identificación de los tipos de contenido admitidos
Los puntos finales de la API suelen esperar datos en un formato específico. Por lo tanto, pueden comportarse de forma diferente según el tipo de contenido de los datos proporcionados en una solicitud. Cambiar el tipo de contenido puede permitirle:
- Genera errores que revelan información útil.
- Evitar defensas defectuosas.
- Aproveche las diferencias en la lógica de procesamiento. Por ejemplo, una API puede ser segura al manejar datos JSON, pero susceptible a ataques de inyección al manejar XML.
Para cambiar el tipo de contenido, modifique el Content-Typeencabezado y luego reformatee el cuerpo de la solicitud según corresponda. Puede usar el convertidor de tipo de contenido BApp para convertir automáticamente los datos enviados en las solicitudes entre XML y JSON.
Cobalt Strike es una poderosa herramienta de emulación de amenazas que proporciona un agente posterior a la explotación y canales encubiertos ideales para simulaciones de adversarios y ejercicios del Red Team.
Conocer …
Uso de Intruder para encontrar puntos finales ocultos
Una vez identificados algunos puntos finales de API iniciales, puede usar Intruder para descubrir puntos finales ocultos. Por ejemplo, imagine un escenario en el que ha identificado el siguiente punto final de API para actualizar la información del usuario:
PUT /api/user/update
Para identificar endpoints ocultos, podría usar Burp Intruder para encontrar otros recursos con la misma estructura. Por ejemplo, podría agregar una carga útil a la /updateposición de la ruta con una lista de otras funciones comunes, como delete`y` add.
Al buscar endpoints ocultos, utilice listas de palabras basadas en convenciones de nomenclatura de API comunes y términos del sector. Asegúrese de incluir también términos relevantes para la aplicación, según su reconocimiento inicial.
Encontrar parámetros ocultos
Al realizar la reconstrucción de la API, es posible que encuentre parámetros no documentados que la API admite. Puede intentar usarlos para cambiar el comportamiento de la aplicación. Burp incluye numerosas herramientas que pueden ayudarle a identificar parámetros ocultos:
- Burp Intruder le permite descubrir automáticamente parámetros ocultos mediante una lista de nombres de parámetros comunes para reemplazar parámetros existentes o añadir nuevos. Asegúrese de incluir también nombres relevantes para la aplicación, según su reconocimiento inicial.
- El minero de parámetros BApp permite calcular automáticamente hasta 65 536 nombres de parámetros por solicitud. Calcula automáticamente los nombres relevantes para la aplicación, basándose en la información obtenida del ámbito.
- La herramienta de descubrimiento de contenido le permite descubrir contenido que no está vinculado desde el contenido visible al que puede acceder, incluidos los parámetros.
Vulnerabilidades de asignación masiva
La asignación masiva (también conocida como enlace automático) puede crear parámetros ocultos inadvertidamente. Esto ocurre cuando los frameworks de software enlazan automáticamente los parámetros de solicitud a los campos de un objeto interno. Por lo tanto, la asignación masiva puede provocar que la aplicación admita parámetros que el desarrollador nunca tuvo previsto procesar.
Identificación de parámetros ocultos
Dado que la asignación masiva crea parámetros a partir de campos de objetos, a menudo puedes identificar estos parámetros ocultos examinando manualmente los objetos devueltos por la API.
Por ejemplo, considere una PATCH /api/users/solicitud que permite a los usuarios actualizar su nombre de usuario y correo electrónico, e incluye el siguiente JSON:
{
"username": "wiener",
"email": "wiener@example.com",
}
Una solicitud simultánea GET /api/users/123devuelve el siguiente JSON:
{
"id": 123,
"name": "John Doe",
"email": "john@example.com",
"isAdmin": "false"
}
Esto puede indicar que los parámetros ocultos idestán isAdmin vinculados al objeto de usuario interno, junto con los parámetros de nombre de usuario y correo electrónico actualizados.
Prueba de vulnerabilidades de asignación masiva
Para probar si puede modificar el isAdmin valor del parámetro enumerado, agréguelo a la PATCHsolicitud:
{
"username": "wiener",
"email": "wiener@example.com",
"isAdmin": false,
}
Además, envíe una PATCH solicitud con un isAdmin valor de parámetro no válido:
{
"username": "wiener",
"email": "wiener@example.com",
"isAdmin": "foo",
}
Si la aplicación se comporta de forma diferente, esto podría indicar que el valor no válido afecta la lógica de la consulta, pero el valor válido no. Esto podría indicar que el usuario puede actualizar el parámetro correctamente.
Luego puede enviar una PATCH solicitud con el isAdmin valor del parámetro establecido en true, para intentar explotar la vulnerabilidad:
{
"username": "wiener",
"email": "wiener@example.com",
"isAdmin": true,
}
Si el isAdmin valor de la solicitud está vinculado al objeto de usuario sin la validación y el saneamiento adecuados, wiener es posible que se le otorguen privilegios de administrador incorrectamente. Para determinar si este es el caso, revise la aplicación para wiener comprobar si puede acceder a la función de administrador.
Prevención de vulnerabilidades en las API
Al diseñar API, asegúrese de que la seguridad sea una consideración desde el principio. En particular, asegúrese de:
- Proteja su documentación si no desea que su API sea de acceso público.
- Asegúrese de mantener su documentación actualizada para que los evaluadores legítimos tengan visibilidad completa de la superficie de ataque de la API.
- Aplicar una lista de métodos HTTP permitidos.
- Validar que el tipo de contenido sea el esperado para cada solicitud o respuesta.
- Utilice mensajes de error genéricos para evitar revelar información que pueda ser útil para un atacante.
- Utilice medidas de protección en todas las versiones de su API, no solo en la versión de producción actual.
Para evitar vulnerabilidades de asignación masiva, incluya en la lista blanca las propiedades que el usuario puede actualizar y bloquee las propiedades sensibles que el usuario no debe actualizar.
NORTH NETWORKS es Distribuidor Oficial y brinda licencias nuevas, renovaciones y servicios profesionales de las herramientas mas importantes.
Pongase en contacto y le ayudaremos a analizar sus necesidades para poder brindarle la herramienta que mejor se ajuste a sus requerimientos.
Si te ha gustado, ¡compártelo con tus amigos!
