imperva/automatic-api-attack-toolImperva의 사용자 정의 가능한 API 공격 도구는 API 사양을 입력으로 받아, 이를 기반으로 한 공격을 생성 및 실행하여 출력으로 제공합니다.
Imperva의 사용자 정의 가능한 API 공격 도구는 API 사양을 입력으로 받아 이를 기반으로 한 공격을 생성하고 실행합니다.
이 도구는 API 사양을 파싱하고, API 사양에 정의된 내용을 기반으로 퍼징 공격 시나리오를 생성할 수 있습니다. 각 엔드포인트에는 사양에 정의된 경계 내에서 그리고 그 외부에서 영리하게 생성된 값이 주입되며, 적절한 요청이 전송되고 성공 또는 실패 여부가 상세히 보고됩니다. 또한 불법 리소스 접근, XSS, SQLi, RFI와 같은 다양한 보안 공격 벡터를 실행하도록 확장할 수 있으며, 이는 기존 엔드포인트뿐만 아니라 존재하지 않는 엔드포인트에도 대상이 됩니다. 인간의 개입이 필요 없습니다. 도구를 실행하고 결과를 얻기만 하면 됩니다.
이 도구는 다양한 요구에 맞게 쉽게 확장할 수 있습니다. 예를 들어, 자신의 API를 테스트하려는 개발자나 공개 API에 대해 정기적인 취약점 또는 긍정적 보안 스캔을 실행하려는 조직에 적합합니다. CI/CD를 고려하여 구축되었습니다.
./gradlew build (Windows의 경우 gradlew.bat build)를 실행합니다.src/main/resources 폴더에서 runnable.sh 파일을 jar 파일과 같은 디렉토리로 복사합니다.cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.shapi-attack.sh 파일을 일반 실행 파일처럼 사용할 수 있습니다.-f, --specFile=specFilePath
실행할 API 사양 파일(swagger 2.0)입니다. JSON/YAML 형식입니다. 더 나은 결과를 위해 각 엔드포인트에 대한 응답이 잘 정의되어 있는지 확인하십시오.
-n, --hostName=hostName
연결할 호스트 이름입니다. IP 주소일 수도 있습니다.
-s, --hostScheme=hostScheme
이 스킴을 사용하여 호스트에 연결합니다. 예: https 또는 http
-p, --hostPort=hostPort
호스트가 API 호출을 수신하는 포트입니다. 기본값은 443입니다.
-ph, --proxyHost=proxyHost
프록시를 통해 요청을 보낼 프록시 호스트를 지정합니다.
-pp, --proxyPort=proxyPort
프록시 포트입니다. 기본값은 80입니다.
-rcn, --addNegativeRC=responseCode[,responseCode...]
부정적 공격(예: 잘못된 값 공격)에서 허용할 추가 응답 코드입니다. 쉼표로 구분하여 여러 값을 지원합니다.
-rcp, --addPositiveRC=responseCode[,responseCode...]
긍정적 검사(적법한 값 공격)에서 허용할 추가 응답 코드입니다. 쉼표로 구분하여 여러 값을 지원합니다.
API가 API 보안 솔루션에 의해 보호되는지 확인하려는 경우.
실행 예: api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -rcn=403
부정적 검사를 위해 403 응답 코드를 적법한 응답 코드로 추가했습니다. 이는 API 보안 솔루션이 이러한 요청을 차단하고 403 상태를 반환하기 때문입니다. 반면 사양은 어떤 엔드포인트에 대해서도 HTTP 코드 403의 응답을 반드시 정의하지는 않습니다. 이렇게 하면 사양에 없음에도 불구하고 이러한 응답이 적법하게 처리되어, 부정적 검사에서 해당 응답을 받지 못할 경우 경고가 표시됩니다. 이러한 경우는 API 보안 솔루션에 의해 보호되지 않고 있음을 의미합니다.
프록시가 API 공격을 어떻게 완화하는지 확인하고 싶지만, 그 뒤에 실제 사이트가 없는 경우.
실행 예: api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -ph 127.0.0.1 -pp=4010 -rcn=403 -rcp=404
이번에는 긍정적 시나리오에 404 상태 코드를 추가했습니다. 따라서 시나리오가 차단되지 않을 때 실패로 보고하지 않고, 적법한 404(리소스를 찾을 수 없음) 응답을 수락합니다.
API가 모든 입력을 올바르게 처리하는지 확인하려는 경우. 더 나아가, 매일 밤 또는 개발자가 프로젝트에 새 코드를 푸시할 때마다 실행하려는 경우.
실행 예: api-attack.sh -f myapi_swagger.yaml -n staging.myorg.com -s https
이번에는 제외 사항 없이 실행합니다. API 사양 파일은 응답 코드를 정확히 선언해야 합니다. 도구는 그 코드만 적법한 것으로 수락하며, 그렇지 않으면 검사를 실패 처리합니다. 검사 실패 조건에 대한 자세한 내용은 아래를 참조하십시오.
위 명령을 Jenkins 작업(또는 원하는 다른 CI/CD 소프트웨어)에서 실행하고, cron 또는 저장소 코드 푸시 활동에 의해 트리거되도록 설정합니다.
TestNG 플러그인이 설치되어 있는지 확인하십시오. 이 플러그인은 build/testng-results에 기록된 결과를 파싱하여 CI/CD 시나리오에서 더 나은 가시성을 제공합니다.
이 API가 퍼징 시도에 취약할 수 있는지 확인하려는 경우. 도구를 실행하고 보고된 실패를 확인하기만 하면 됩니다.
bad_requests 폴더에 저장되므로 나중에 분석할 수 있습니다(예: CI/CD 서버에서 실행 중이고 머신에 즉시 접근할 수 없는 경우).***** 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}
검사가 실패한 이유: 요청이 200을 받았지만, 올바른 URL을 포함하지 않았습니다.
***** 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}
서버는 정수를 받을 것으로 예상했지만 double 값을 수락했습니다. 이는 서버에서 버퍼 오버플로를 악용하려는 좋은 지점일 수 있습니다.
***** 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"}
API 사양에 따라 존재하지 않지만 적법한 사용자 이름을 제공했습니다. 서버는 이 요청을 처리하고 적법한 오류를 반환하는 방법을 알고 있었습니다.
여기서 endpoint는 엔드포인트 URL과 메서드의 쌍을 의미합니다.
커뮤니티의 이익을 위해 다른 시나리오를 오픈 소스 도구로 마이그레이션하는 작업을 진행 중입니다. 업데이트를 기대해 주세요.
이 도구는 특정 요구 사항을 충족하기 위해 퍼징 및 요청 생성 기능을 쉽게 확장할 수 있는 방식으로 작성되었습니다. 다른 사람들에게 도움이 될 수 있는 추가 사항이 있으면 풀 리퀘스트를 만들어 제안해 주세요.
라이브러리에 대한 질문이 있으면 소스 코드 문서를 확인하십시오. 여전히 질문이 있으면 boris.serebro(at)imperva(dot)com으로 이메일을 보내 문의하십시오.
Git Issue를 열고 가능한 한 많은 정보를 포함해 주십시오. 가능하면 문제를 설명하는 샘플 코드를 제공해 주십시오. 특정 저장소에서만 버그가 발생하는 경우 가능하면 해당 저장소에 대한 링크를 제공해 주십시오. 도움을 요청하기 위해 Git Issue를 열지 말고, 버그 보고서만 제출하십시오.
실행 예: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https
API가 서버 측에서 올바르게 구현되었는지, 또는 그 정의가 서버 구현과 일치하는지 확인하려는 경우.
실행 예: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https