imperva/automatic-api-attack-toolLa herramienta de ataque API personalizable de Imperva toma una especificación de API como entrada, genera y ejecuta ataques basados en ella como salida.
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.
./gradlew build o gradlew.bat build en Windowsrunnable.sh de la carpeta src/main/resources al mismo directorio que el archivo jar.cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh-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
-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
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
bad_requests, para que pueda analizarla más tarde (por ejemplo, si se ejecuta en un servidor CI/CD, por ejemplo, y no tiene acceso inmediato a la máquina)***** Testing API Endpoint *****
***** Test ID: 1575128763286-74212
Testing: Bad Property: /username (STRING), value: {, URL encoded: %7B
--> Url: /user/{
--> Method: GET
--> Headers: []
----------**----------
Request was: GET /user/{ [Accept: application/json], Response status code: 200(UNEXPECTED)
Response (non parsed):
{"id":0,"username":"string","firstName":"string","lastName":"string","email":"string","password":"string","phone":"string","userStatus":0}
¿Por qué falló la comprobación? La solicitud obtuvo 200, a pesar de que no contenía una URL legal
***** Testing API Endpoint *****
***** Test ID: 1575128763286-25078
Testing: Bad Property: /body/quantity (INTEGER), value: 0.4188493, URL encoded: 0.4188493
--> Url: /store/order
--> Method: POST
--> Headers: []
--> Body: {"petId":-2511515111206893939,"quantity":0.4188493,"id":698757161286106823,"shipDate":"�s","complete":"true","status":"approved"}
----------**----------
Request was: POST /store/order [Accept: application/json], Response status code: 200(UNEXPECTED)
Response (non parsed):
{"id":0,"petId":0,"quantity":0,"shipDate":"2019-11-30T15:46:03Z","status":"placed","complete":false}
El servidor esperaba recibir un entero, pero aceptó un valor doble. Este podría ser un buen lugar para intentar explotar algún desbordamiento de búfer en el servidor.
***** Testing API Endpoint *****
***** Test ID: 1575128763137-43035
Testing: /user/{username}
--> Url: /user/%E68E97EDB4Oq-(!BbG,Y$p'A-KW%65f9FA6jt5vvDz-cW.QGsLS+AA~RIHC3wgy25lDJsGzcT.;kJ+(
--> Method: GET
--> Headers: []
----------**----------
Request was: GET /user/%E68E97EDB4Oq-(!BbG,Y$p'A-KW%65f9FA6jt5vvDz-cW.QGsLS+AA~RIHC3wgy25lDJsGzcT.;kJ+( [Accept: application/json], Response status code: 404
Response (non parsed):
{"statusCode":404,"error":"Not Found","message":"Not Found"}
Proporcionamos un nombre de usuario que no existía pero era legal, según la especificación de la API. El servidor supo cómo manejar esta solicitud y devolver un error legal.
Usaremos el término endpoint aquí, como la tupla de URL de endpoint y método.
Estamos trabajando en migrar nuestros otros escenarios a la herramienta de código abierto, en beneficio de la comunidad. Estén atentos para actualizaciones.
La herramienta está escrita de una manera que facilita la extensión de su funcionalidad de fuzzing y generación de solicitudes para satisfacer sus necesidades específicas. No dude en sugerir cualquier adición que pueda beneficiar a otros mediante la creación de un pull request.
Si tiene preguntas sobre la biblioteca, asegúrese de consultar la documentación del código fuente. Si aún tiene preguntas, comuníquese conmigo por correo electrónico a boris.serebro(at)imperva(dot)com.
Abra un Git Issue e incluya tanta información como sea posible. Si es posible, proporcione un código de muestra que ilustre el problema que está encontrando. Si está experimentando un error solo en un repositorio específico, proporcione un enlace a él, si es posible. No abra un Git Issue para obtener ayuda, solo para informes de errores.