imperva/automatic-api-attack-toolA ferramenta de ataque de API personalizável da Imperva recebe uma especificação de API como entrada, gera e executa ataques baseados nela como saída.
A ferramenta de ataque a APIs personalizável da Imperva recebe uma especificação de API como entrada, e gera e executa ataques baseados nela como saída.
A ferramenta é capaz de analisar uma especificação de API e criar cenários de ataque de fuzzing baseados no que é definido na especificação. Cada endpoint é injetado com valores gerados de forma inteligente dentro dos limites definidos pela especificação, e fora dela, as requisições apropriadas são enviadas e seu sucesso ou falha são reportados de forma detalhada. Você também pode estendê-la para executar vários vetores de ataque de segurança, como acesso ilegal a recursos, XSS, SQLi e RFI, direcionados aos endpoints existentes, ou até mesmo a endpoints inexistentes. Nenhuma intervenção humana é necessária. Basta executar a ferramenta e obter os resultados.
A ferramenta pode ser facilmente estendida para se adaptar a diversas necessidades, como para um desenvolvedor que deseja testar sua API, ou uma organização que deseja executar varreduras regulares de vulnerabilidade ou segurança positiva em sua API pública. Ela foi construída pensando em CI/CD.
./gradlew build ou gradlew.bat build no Windowsrunnable.sh da pasta src/main/resources para o mesmo diretório do arquivo jar.cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh-f, --specFile=caminhoDoArquivoEspecificacao
O arquivo de especificação da API (swagger 2.0) para executar. Formato JSON/YAML. Para melhores resultados, certifique-se de que as respostas estejam bem definidas para cada endpoint.
-n, --hostName=nomeDoHost
O nome do host para conectar. Pode ser também um IP
-s, --hostScheme=esquemaDoHost
A conexão com o host será feita usando este esquema; ex: https ou http
-p, --hostPort=portaDoHost
A porta em que o host está ouvindo para chamadas de API, padrão é: 443
-ph, --proxyHost=hostDoProxy
Especifica o host do proxy para enviar as requisições através de um proxy
-pp, --proxyPort=portaDoProxy
A porta do proxy, padrão é: 80
-rcn, --addNegativeRC=codigoDeResposta[,codigoDeResposta...]
Códigos de resposta adicionais a serem aceitos em ataques negativos (ex: ataques com valores inválidos). Vários valores são suportados, separados por vírgulas
-rcp, --addPositiveRC=codigoDeResposta[,codigoDeResposta...]
Códigos de resposta adicionais a serem aceitos em verificações positivas (ataques com valores legítimos). Vários valores são suportados, separados por vírgulas
Você gostaria de verificar se sua API está protegida por uma solução de Segurança de API.
Exemplo de execução: api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -rcn=403
Adicionamos o código de resposta 403 como um código de resposta legítimo para as verificações negativas. Isso porque a solução de Segurança de API bloqueia tais requisições e retorna um status 403. A especificação, por outro lado, não define necessariamente tal resposta com código HTTP 403 para nenhum de seus endpoints. Isso tornaria tais respostas legítimas, apesar de não estarem na especificação, e alertaria você quando tal resposta não for recebida de uma verificação negativa. Tais casos significam que você está desprotegido pela sua solução de segurança de API.
Você gostaria de verificar como seu proxy mitiga ataques de API, mas não tem um site real por trás dele.
Exemplo de execução: api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -ph 127.0.0.1 -pp=4010 -rcn=403 -rcp=404
Desta vez adicionamos o código de status 404 aos cenários positivos. Assim, quando um cenário não for bloqueado, não reportaremos uma falha, mas sim aceitaremos a resposta legítima 404 (recurso não encontrado).
Você gostaria de verificar se sua API lida corretamente com todas as entradas. Além disso, gostaria de executá-la diariamente, ou até mesmo após cada vez que um desenvolvedor envia novo código para o projeto.
Exemplo de execução: api-attack.sh -f myapi_swagger.yaml -n staging.myorg.com -s https
Desta vez estamos executando sem nenhuma exclusão. O arquivo de especificação da API deve declarar seus códigos de resposta com precisão. A ferramenta aceitará apenas eles como legítimos e falhará nas verificações caso contrário. Veja mais abaixo sobre as condições de falha nas verificações. Execute o comando acima em um job Jenkins (ou qualquer outro software de CI/CD de sua preferência), que será acionado por um cron, ou por uma atividade de push de código no repositório. Certifique-se de ter o plugin instalado, que deve analisar os resultados escritos em , para melhor visibilidade no cenário de CI/CD.
bad_requests, para que você possa analisá-las posteriormente (por exemplo, se estiver sendo executado em um servidor de CI/CD e você não tiver acesso imediato à 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 que a verificação falhou? A requisição obteve 200, mesmo não contendo uma URL válida
***** 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}
O servidor esperava receber um inteiro, mas aceitou um valor double. Este pode ser um bom ponto para tentar explorar algum buffer overflow no 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"}
Fornecemos um nome de usuário que era inexistente, mas legal, de acordo com a especificação da API. O servidor soube como lidar com esta requisição e retornou um erro legal.
Usaremos o termo endpoint aqui, como a tupla URL do endpoint e Método.
Estamos trabalhando na migração de nossos outros cenários para a ferramenta de código aberto, para benefício da comunidade. Fique atento para atualizações.
A ferramenta foi escrita de forma a facilitar a extensão de sua funcionalidade de fuzzing e geração de requisições para atender às suas necessidades específicas. Sinta-se à vontade para sugerir quaisquer adições que possam beneficiar outros, criando um pull request.
Se você tiver dúvidas sobre a biblioteca, certifique-se de verificar a documentação do código-fonte. Se ainda tiver dúvidas, entre em contato comigo por e-mail em boris.serebro(at)imperva(dot)com.
Por favor, abra uma Issue no Git e inclua o máximo de informações possível. Se possível, forneça um código de exemplo que ilustre o problema que você está enfrentando. Se você estiver enfrentando um bug apenas em um repositório específico, forneça um link para ele, se possível. Não abra uma Issue no Git para obter ajuda, apenas para relatórios de bugs.
TestNGbuild/testng-resultsVocê gostaria de verificar se esta API pode estar aberta a tentativas de fuzzing. Basta executar a ferramenta e verificar as falhas reportadas.
Exemplo de execução: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https
Você gostaria de verificar se sua API está implementada corretamente no lado do servidor, ou se sua definição corresponde à implementação do servidor.
Exemplo de execução: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https