Herramienta Automática de Ataque a APIs

La herramienta de ataque a API personalizable de Imperva toma una especificación de API como entrada, y genera y ejecuta ataques basados en ella como salida.

La herramienta es capaz de analizar una especificación de API y crear escenarios de ataque de fuzzing basados en lo que está definido en la especificación de la API. Cada endpoint se inyecta con valores generados inteligentemente dentro de los límites definidos por la especificación, y fuera de ella, se envían las solicitudes apropiadas y su éxito o fracaso se reportan de manera detallada. También puede extenderla para ejecutar varios vectores de ataque de seguridad, como acceso ilegal a recursos, XSS, SQLi y RFI, que están dirigidos a los endpoints existentes, o incluso a los inexistentes. No se necesita intervención humana. Simplemente ejecute la herramienta y obtenga los resultados.

La herramienta se puede extender fácilmente para adaptarse a las diversas necesidades, como para un desarrollador que desea probar su API, o una organización que desea ejecutar escaneos regulares de vulnerabilidades o seguridad positiva en su API pública. Está construida pensando en CI/CD.

Requisitos

• Java 8 o superior
• Gradle

Ejecución

• Descargue el código de GitHub y ejecute ./gradlew build o gradlew.bat build en Windows
• Puede encontrar el jar ejecutable en la carpeta build/libs
• Ejecute 'java -jar imperva-api-attack-tool.jar' para ver el menú de ayuda

Creando un ejecutable de Linux

• Copie el archivo runnable.sh de la carpeta src/main/resources al mismo directorio que el archivo jar.
• Ahora ejecute: cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh
• Puede usar el archivo api-attack.sh como un ejecutable normal

Uso

Parámetros obligatorios:

-f, --specFile=specFilePath

El archivo de especificación de API (swagger 2.0) sobre el que ejecutar. Formato JSON/YAML. Para mejores resultados, asegúrese de que las respuestas estén bien definidas para cada endpoint.

-n, --hostName=hostName

El nombre del host al que conectarse. También puede ser una IP

-s, --hostScheme=hostScheme

La conexión al host se realizará utilizando este esquema; por ejemplo: https o http

Parámetros opcionales:

-p, --hostPort=hostPort

El puerto en el que el host está escuchando para llamadas API, por defecto es: 443

-ph, --proxyHost=proxyHost

Especifique el host proxy para enviar las solicitudes a través de un proxy

-pp, --proxyPort=proxyPort

El puerto del proxy, por defecto es: 80

-rcn, --addNegativeRC=responseCode[,responseCode...]

Códigos de respuesta adicionales que se aceptarán en ataques negativos (por ejemplo, ataques de valor incorrecto). Se admiten múltiples valores separados por comas

-rcp, --addPositiveRC=responseCode[,responseCode...]

Códigos de respuesta adicionales que se aceptarán en comprobaciones positivas (ataques de valor legítimo). Se admiten múltiples valores separados por comas

 

Escenarios típicos de uso:

• Desea comprobar si su API está protegida por una solución de seguridad de API.

  Ejemplo de ejecución: api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -rcn=403

  Hemos añadido el código de respuesta 403 como un código de respuesta legítimo para las comprobaciones negativas. Esto se debe a que la solución de seguridad de API bloquea dichas solicitudes y devuelve un estado 403. La especificación, por otro lado, no necesariamente define tal respuesta con código HTTP 403 para ninguno de sus endpoints. Esto haría que dichas respuestas sean legítimas, a pesar de no estar en la especificación, y le alertará cuando no se reciba dicha respuesta de una comprobación negativa. Tales casos significan que usted no está protegido por su solución de seguridad de API.

• Desea comprobar cómo su proxy mitiga los ataques a API, pero no tiene un sitio real detrás.

  Ejemplo de ejecución: api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -ph 127.0.0.1 -pp=4010 -rcn=403 -rcp=404

  Esta vez hemos añadido el código de estado 404 a los escenarios positivos. De modo que cuando un escenario no es bloqueado, no reportaremos una falla, sino que aceptaremos la respuesta legítima 404 (recurso no encontrado).

• Desea comprobar si su API maneja todas las entradas correctamente. Además, desea ejecutarlo diariamente, o incluso después de cada vez que un desarrollador sube nuevo código al proyecto.

  Ejemplo de ejecución: api-attack.sh -f myapi_swagger.yaml -n staging.myorg.com -s https

  Esta vez estamos ejecutando sin exclusiones. El archivo de especificación de API debe declarar sus códigos de respuesta con precisión. La herramienta solo los aceptará como legítimos y fallará las comprobaciones en caso contrario. Vea más abajo las condiciones para fallar las comprobaciones. Ejecute el comando anterior en un trabajo de Jenkins (o cualquier otro software de CI/CD que prefiera), que se active mediante un cron o una actividad de push de código en el repositorio. Asegúrese de tener instalado el plugin TestNG, que debe analizar los resultados escritos en build/testng-results, para una mejor visibilidad en el escenario CI/CD.

• Desea comprobar si esta API podría estar abierta a intentos de fuzzing. Simplemente ejecute la herramienta y verifique las fallas reportadas.

  Ejemplo de ejecución: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https

• Desea comprobar si su API está implementada correctamente en el lado del servidor, o que su definición corresponde a la implementación del servidor.

  Ejemplo de ejecución: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https

Condiciones para fallar las comprobaciones

• La herramienta verifica que el código de respuesta de la solicitud generada coincide con los códigos de respuesta declarados en el swagger. Sin embargo,
• Comprobaciones positivas: si es un error claro (código 5xx), aún así fallaremos la comprobación, incluso si este código de respuesta no está definido en la especificación, pero no si ha proporcionado una anulación.
• Comprobaciones negativas: si la respuesta no es un error legítimo (1xx, 2xx, 5xx), fallamos la comprobación a menos que haya proporcionado una anulación. Si el código de error legítimo no está en la especificación, la comprobación también fallará.
• Puede usar la definición 'default' en la sección de respuestas del swagger, pero no se recomienda. Siempre defina sus respuestas legítimas con precisión.

Condiciones para fallar las comprobaciones

• La herramienta verifica que el código de respuesta de la solicitud generada coincide con los códigos de respuesta declarados en el swagger. Sin embargo,
• Comprobaciones positivas: si es un error claro (código 5xx), aún así fallaremos la comprobación, incluso si este código de respuesta no está definido en la especificación, pero no si ha proporcionado una anulación.
• Comprobaciones negativas: si la respuesta no es un error legítimo (1xx, 2xx, 5xx), fallamos la comprobación. A menos que haya proporcionado una anulación. Si el código de error legítimo no está en la especificación, la comprobación también fallará.
• Puede usar la definición 'default' en la sección de respuestas del swagger, pero no se recomienda. Siempre defina sus respuestas legítimas con precisión.