API Testing
PreviousLaboratorio: Explotación de reglas de caché de coincidencia exacta para el engaño de caché webNextLaboratorio: Explotación de un punto final de API mediante documentación
Last updated
Las API (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 las vulnerabilidades de las API pueden socavar aspectos fundamentales de la confidencialidad, la integridad y la disponibilidad de un sitio web.
Todos los sitios web dinámicos están compuestos por API, por lo que las vulnerabilidades web clásicas, como la inyección SQL, podrían clasificarse como pruebas de API. En este tema, le enseñaremos a probar las API que no se utilizan por completo en el front-end del sitio web, con un enfoque en las API RESTful y JSON. También le enseñaremos a probar las vulnerabilidades de contaminación de parámetros del lado del servidor que pueden 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 .
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 comenzar, 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 GETsolicitud:
El punto final de la API para esta solicitud es /api/books. Esto da como resultado 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 que haya identificado los puntos finales, debe determinar cómo interactuar con ellos. Esto le permite crear solicitudes HTTP válidas para probar la API. Por ejemplo, debe 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.
Las API generalmente están documentadas para que los desarrolladores sepan cómo usarlas e integrarlas.
La documentación puede estar en formatos legibles para humanos y 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 que el software la procese para automatizar tareas como la integración y validación de API. Está escrita en formatos estructurados como JSON o XML.
La documentación de la API suele estar disponible públicamente, en particular si la API está destinada a ser utilizada por desarrolladores externos. Si este es el caso, comience siempre su análisis revisando la documentación.
Incluso si la documentación de la API no está disponible abiertamente, es posible acceder a ella explorando aplicaciones que usan la API.
Para ello, puede utilizar Burp Scanner para rastrear la API. También puede explorar aplicaciones manualmente utilizando 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, debe investigar las siguientes rutas:
/api/swagger/v1
/api/swagger
/api
También puede utilizar una lista de rutas comunes para encontrar documentación mediante Intruder.
Puede utilizar una variedad de herramientas automatizadas para analizar cualquier documentación API legible por máquina que encuentre.
Puede utilizar Burp Scanner para rastrear y auditar la documentación de OpenAPI o cualquier otra documentación en formato JSON o YAML. También puede analizar la documentación de OpenAPI mediante OpenAPI Parser BApp.
También puede utilizar una herramienta especializada para probar los puntos finales documentados, como Postman o SoapUI .
También puede recopilar mucha información explorando las aplicaciones que utilizan la API. Esto suele ser útil incluso si tiene acceso a la documentación de la API, ya que a veces la documentación 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.
Mientras explora la aplicación, busque patrones que sugieran puntos finales de API en la estructura de la URL, como /api/. También busque archivos JavaScript. Estos pueden contener referencias a puntos finales de API que no ha activado directamente a través del navegador web. Burp Scanner extrae automáticamente algunos puntos finales durante los rastreos, pero para una extracción más compleja, use la aplicación JS Link Finder BApp. También puede revisar manualmente los archivos JavaScript en Burp.
Una vez que haya identificado los puntos finales de la API, interactúe con ellos mediante Burp Repeater y Burp Intruder. Esto le permite observar el comportamiento de la API y descubrir superficies de ataque adicionales. Por ejemplo, podría investigar cómo responde la API al cambiar el método HTTP y el tipo de medio.
A medida que interactúa con los puntos finales de la API, revise atentamente los mensajes de error y otras respuestas. A veces, estos incluyen información que puede utilizar para crear una solicitud HTTP válida.
El método HTTP especifica la acción que se realizará en un recurso. Por ejemplo:
GET Recupera datos de un recurso.
PATCHAplica cambios parciales a un recurso.
OPTIONSRecupera información sobre los tipos de métodos de solicitud que se pueden utilizar en un recurso.
Un punto final de API puede admitir distintos métodos HTTP. Por lo tanto, es importante probar todos los métodos posibles cuando se investigan puntos finales de API. Esto puede permitirle identificar funciones adicionales del punto final, lo que abre más superficie de ataque.
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/1Elimina una tarea.
Puede utilizar la lista de verbos HTTP incorporada en Burp Intruder para recorrer automáticamente una variedad de métodos.
Al probar distintos métodos HTTP, elija objetos de baja prioridad. Esto le ayudará a asegurarse de evitar consecuencias no deseadas, como por ejemplo alterar elementos críticos o crear registros excesivos.
Los puntos finales de API suelen esperar datos en un formato específico. Por lo tanto, pueden comportarse de manera diferente según el tipo de contenido de los datos proporcionados en una solicitud. Cambiar el tipo de contenido puede permitirle:
Generar errores que revelen información útil.
Evitar defensas defectuosas.
Aproveche las diferencias en la lógica de procesamiento. Por ejemplo, una API puede ser segura cuando maneja datos JSON, pero susceptible a ataques de inyección cuando trabaja con XML.
Para cambiar el tipo de contenido, modifique el Content-Typeencabezado y luego vuelva a formatear el cuerpo de la solicitud según corresponda. Puede utilizar el convertidor de tipo de contenido BApp para convertir automáticamente los datos enviados dentro de las solicitudes entre XML y JSON.
Una vez que haya identificado algunos puntos finales de API iniciales, puede usar Intruder para descubrir puntos finales ocultos. Por ejemplo, considere un escenario en el que haya identificado el siguiente punto final de API para actualizar la información del usuario:
PUT /api/user/update
Para identificar puntos finales ocultos, puede utilizar Burp Intruder para buscar otros recursos con la misma estructura. Por ejemplo, puede agregar una carga útil a la /updateposición de la ruta con una lista de otras funciones comunes, como deletey add.
Al buscar puntos finales 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 que sean relevantes para la aplicación, según su reconocimiento inicial.
Cuando estés realizando un reconocimiento de API, es posible que encuentres parámetros no documentados que la API admita. Puedes intentar usarlos para cambiar el comportamiento de la aplicación. Burp incluye numerosas herramientas que pueden ayudarte a identificar parámetros ocultos:
Burp Intruder le permite descubrir automáticamente parámetros ocultos, utilizando una lista de palabras con nombres de parámetros comunes para reemplazar parámetros existentes o agregar parámetros nuevos. Asegúrese de incluir también nombres que sean relevantes para la aplicación, según su reconocimiento inicial.
El minero de parámetros BApp le permite adivinar automáticamente hasta 65 536 nombres de parámetros por solicitud. El minero de parámetros adivina automáticamente los nombres que son relevantes para la aplicación, en función de la información extraída del ámbito.
La herramienta de descubrimiento de contenido permite descubrir contenido que no está vinculado desde el contenido visible al que puede acceder, incluidos los parámetros.
La asignación masiva (también conocida como vinculación automática) puede crear parámetros ocultos de forma inadvertida. Esto ocurre cuando los marcos de software vinculan 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 la intención de procesar.
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:
Una GET /api/users/123solicitud simultánea devuelve el siguiente JSON:
Esto puede indicar que los parámetros ocultos id y isAdmin están vinculados al objeto de usuario interno, junto con los parámetros de nombre de usuario y correo electrónico actualizados.
Para probar si puede modificar el isAdminvalor del parámetro enumerado, agréguelo a la PATCHsolicitud:
Además, envíe una PATCHsolicitud con un isAdminvalor de parámetro no válido:
Si la aplicación se comporta de forma diferente, esto puede sugerir que el valor no válido afecta la lógica de la consulta, pero el valor válido no. Esto puede indicar que el usuario puede actualizar correctamente el parámetro.
Luego puede enviar una PATCHsolicitud con el isAdminvalor del parámetro establecido en true, para intentar explotar la vulnerabilidad:
Si el isAdminvalor de la solicitud está vinculado al objeto de usuario sin una validación y un saneamiento adecuados, wieneres posible que se le otorguen al usuario privilegios de administrador de forma incorrecta. Para determinar si este es el caso, navegue por la aplicación para wienerver si puede acceder a la función de administrador.
Al diseñar API, asegúrese de tener en cuenta la seguridad desde el principio. En particular, asegúrese de lo siguiente:
Proteja su documentación si no desea que su API sea accesible públicamente.
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 de propiedades permitidas las que el usuario puede actualizar y en la lista de propiedades confidenciales las que no debe actualizar.
Parameter Pollution Server Side ”Contaminación de parametros del lado del servidor”Algunos sistemas contienen API internas a las que no se puede acceder directamente desde Internet. La contaminación de parámetros del lado del servidor se produce cuando un sitio web incorpora la entrada del usuario en una solicitud del lado del servidor a una API interna sin la codificación adecuada. Esto significa que un atacante puede manipular o inyectar parámetros, lo que puede permitirle, por ejemplo:
Anular parámetros existentes.
Modificar el comportamiento de la aplicación.
Acceder a datos no autorizados.
Puede comprobar si cualquier entrada del usuario contiene algún tipo de contaminación de parámetros. Por ejemplo, los parámetros de consulta, los campos de formulario, los encabezados y los parámetros de ruta URL pueden ser vulnerables.
Esta vulnerabilidad a veces se denomina contaminación de parámetros HTTP. Sin embargo, este término también se utiliza para referirse a una técnica de omisión del firewall de aplicaciones web (WAF). Para evitar confusiones, en este tema solo nos referiremos a la contaminación de parámetros del lado del servidor.
Además, a pesar del nombre similar, esta clase de vulnerabilidad tiene muy poco en común con la contaminación del prototipo del lado del servidor .
Para probar la contaminación de parámetros del lado del servidor en la cadena de consulta, coloque caracteres de sintaxis de consulta como #, &, y =en su entrada y observe cómo responde la aplicación.
Considere una aplicación vulnerable que le permite buscar otros usuarios en función de su nombre de usuario. Cuando busca un usuario, su navegador realiza la siguiente solicitud:
Para recuperar información del usuario, el servidor consulta una API interna con la siguiente solicitud:
Puede utilizar un #carácter codificado en la URL para intentar truncar la solicitud del lado del servidor. Para ayudarlo a interpretar la respuesta, también puede agregar una cadena después del #carácter.
Por ejemplo, podría modificar la cadena de consulta de la siguiente manera:
El front-end intentará acceder a la siguiente URL:
Es fundamental que codifiques el
#carácter en la URL. De lo contrario, la aplicación frontend lo interpretará como un identificador de fragmento y no se pasará a la API interna.
Revise la respuesta para encontrar pistas sobre si la consulta se ha truncado. Por ejemplo, si la respuesta devuelve el usuario peter, es posible que la consulta del lado del servidor se haya truncado. Si Invalid namese devuelve un mensaje de error, es posible que la aplicación lo haya tratado foocomo parte del nombre de usuario. Esto sugiere que es posible que la solicitud del lado del servidor no se haya truncado.
Si puede truncar la solicitud del lado del servidor, se eliminará el requisito de que el publicProfilecampo se configure como verdadero. Es posible que pueda aprovechar esta característica para devolver perfiles de usuario no públicos.
Puede utilizar un &carácter codificado en URL para intentar agregar un segundo parámetro a la solicitud del lado del servidor.
Por ejemplo, podría modificar la cadena de consulta de la siguiente manera:
Esto da como resultado la siguiente solicitud del lado del servidor a la API interna:
Revise la respuesta para obtener pistas sobre cómo se analiza el parámetro adicional. Por ejemplo, si la respuesta no cambia, esto puede indicar que el parámetro se inyectó correctamente pero la aplicación lo ignoró.
Para tener una visión más completa, será necesario realizar más pruebas.
Si puede modificar la cadena de consulta, puede intentar agregar un segundo parámetro válido a la solicitud del lado del servidor.
The Param miner BApp enables you to automatically guess up to 65,536 param names per request. Param miner automatically guesses names that are relevant to the application, based on information taken from the scope.
Por ejemplo, si ha identificado el emailparámetro, puede agregarlo a la cadena de consulta de la siguiente manera:
Esto da como resultado la siguiente solicitud del lado del servidor a la API interna:
Revise la respuesta para obtener pistas sobre cómo se analiza el parámetro adicional.
Para confirmar si la aplicación es vulnerable a la contaminación de parámetros del lado del servidor, puede intentar anular el parámetro original. Para ello, inyecte un segundo parámetro con el mismo nombre.
Por ejemplo, podría modificar la cadena de consulta de la siguiente manera:
Esto da como resultado la siguiente solicitud del lado del servidor a la API interna:
La API interna interpreta dos nameparámetros. El impacto de esto depende de cómo la aplicación procesa el segundo parámetro. Esto varía según las diferentes tecnologías web. Por ejemplo:
PHP analiza únicamente el último parámetro. Esto generaría una búsqueda del usuario de carlos.
ASP.NET combina ambos parámetros. Esto provocaría una búsqueda del usuario de peter,carlos , lo que podría generar un mensaje de error.Invalid username
Node.js/express analiza únicamente el primer parámetro. Esto generaría una búsqueda del usuario de peter, que arrojaría un resultado sin cambios.
Si puedo anular el parámetro original, es posible que pueda realizar una explotación. Por ejemplo, podría agregar name=administratora la solicitud. Esto podría permitirle iniciar sesión como usuario administrador.
Una API RESTful puede colocar los nombres y valores de los parámetros en la ruta de la URL, en lugar de en la cadena de consulta. Por ejemplo, considere la siguiente ruta:
La ruta URL se puede desglosar de la siguiente manera:
/apies el punto final de la API raíz.
/usersrepresenta un recurso, en este caso.
/123representa un parámetro, aquí un identificador para el usuario específico.
Considere una aplicación que le permita editar perfiles de usuario según su nombre de usuario. Las solicitudes se envían al siguiente punto final:
Esto da como resultado la siguiente solicitud del lado del servidor:
Un atacante podría manipular los parámetros de ruta de URL del lado del servidor para explotar la API. Para probar esta vulnerabilidad, agregue secuencias de recorrido de ruta para modificar los parámetros y observe cómo responde la aplicación.
Puede enviar la URL codificada peter/../admincomo valor del nameparámetro:
Esto puede generar la siguiente solicitud del lado del servidor:
Si el cliente del lado del servidor o la API del back-end normalizan esta ruta, se puede resolver como /api/private/users/admin.
Un atacante podría manipular parámetros para explotar vulnerabilidades en el procesamiento de otros formatos de datos estructurados por parte del servidor, como JSON o XML. Para comprobarlo, inyecte datos estructurados inesperados en las entradas del usuario y observe cómo responde el servidor.
Considere una aplicación que permite a los usuarios editar su perfil y luego aplica los cambios con una solicitud a una API del lado del servidor. Cuando edita su nombre, su navegador realiza la siguiente solicitud:
Esto da como resultado la siguiente solicitud del lado del servidor:
Puede intentar agregar el access_levelparámetro a la solicitud de la siguiente manera:
Si la entrada del usuario se agrega a los datos JSON del lado del servidor sin una validación o desinfección adecuada, esto da como resultado la siguiente solicitud del lado del servidor:
Esto puede provocar que al usuario peterse le otorgue acceso de administrador.
Considere un ejemplo similar, pero donde la entrada del usuario del lado del cliente está en datos JSON. Cuando edita su nombre, su navegador realiza la siguiente solicitud:
Esto da como resultado la siguiente solicitud del lado del servidor:
Puede intentar agregar el access_levelparámetro a la solicitud de la siguiente manera:
Si se decodifica la entrada del usuario y luego se agrega a los datos JSON del lado del servidor sin una codificación adecuada, esto da como resultado la siguiente solicitud del lado del servidor:
Nuevamente, esto puede resultar en que al usuario peterse le otorgue acceso de administrador.
La inyección de formato estructurado también puede ocurrir en las respuestas. Por ejemplo, esto puede ocurrir si la entrada del usuario se almacena de forma segura en una base de datos y luego se integra en una respuesta JSON desde una API de back-end sin la codificación adecuada. Por lo general, puede detectar y explotar la inyección de formato estructurado en las respuestas de la misma manera que en las solicitudes.
Burp incluye herramientas automatizadas que pueden ayudarle a detectar vulnerabilidades de contaminación de parámetros del lado del servidor.
Burp Scanner detecta automáticamente transformaciones de entrada sospechosas al realizar una auditoría. Estas ocurren cuando una aplicación recibe una entrada del usuario, la transforma de alguna manera y luego realiza un procesamiento adicional del resultado. Este comportamiento no constituye necesariamente una vulnerabilidad, por lo que deberá realizar más pruebas utilizando las técnicas manuales descritas anteriormente. Para obtener más información, consulte la definición del problema de transformación de entrada sospechosa .
También puede utilizar la aplicación Backslash Powered Scanner BApp para identificar vulnerabilidades de inyección del lado del servidor. El escáner clasifica las entradas como aburridas, interesantes o vulnerables. Deberá investigar las entradas interesantes utilizando las técnicas manuales descritas anteriormente. Para obtener más información, consulte el documento técnico Backslash Powered Scanning: hunting unknown vulnerability classes .
Para evitar la contaminación de parámetros del lado del servidor, utilice una lista de permitidos para definir caracteres que no necesitan codificación y asegúrese de que todos los demás datos ingresados por el usuario estén codificados antes de incluirlos en una solicitud del lado del servidor. También debe asegurarse de que todos los datos ingresados cumplan con el formato y la estructura esperados.
