imperva/automatic-api-attack-toolИнструмент Imperva для настраиваемых атак на API принимает в качестве входных данных спецификацию API, а в качестве выходных данных генерирует и запускает атаки, основанные на ней.
Настраиваемый инструмент для атак на API от Imperva принимает на вход спецификацию API, а на выходе генерирует и выполняет атаки на её основе.
Инструмент умеет анализировать спецификацию API и создавать сценарии фаззинга на основе того, что в ней определено. В каждую конечную точку внедряются грамотно сгенерированные значения в рамках границ, заданных спецификацией, а также за их пределами; отправляются соответствующие запросы, и их успех или неудача подробно фиксируются. Вы также можете расширить инструмент для выполнения различных векторов атак безопасности, таких как несанкционированный доступ к ресурсам, XSS, SQLi и RFI, направленных на существующие или даже несуществующие конечные точки. Вмешательство человека не требуется. Просто запустите инструмент и получите результаты.
Инструмент легко расширяется для адаптации к различным потребностям, например, для разработчика, желающего протестировать своё API, или организации, которая хочет регулярно проводить сканирование уязвимостей или позитивные проверки безопасности своего публичного API. Он создан с учётом CI/CD.
./gradlew build или gradlew.bat build в Windowsjava -jar imperva-api-attack-tool.jar, чтобы увидеть меню справкиrunnable.sh из папки src/main/resources в ту же директорию, где находится jar-файл.cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-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 или при push кода в репозиторий.
Убедитесь, что установлен плагин TestNG, который должен анализировать результаты, записанные в build/testng-results, для лучшей видимости в сценарии CI/CD.
Вы хотите проверить, не подвержено ли это API попыткам фаззинга. Просто запустите инструмент и посмотрите на зафиксированные ошибки.
Пример запуска: 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
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}
Сервер ожидал целое число, но принял значение с плавающей точкой. Это может быть хорошей возможностью попытаться использовать переполнение буфера на сервере.
***** 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. Сервер правильно обработал этот запрос и вернул легитимную ошибку.
Здесь мы используем термин конечная точка как пару URL конечной точки и метод.
Мы работаем над переносом других наших сценариев в инструмент с открытым исходным кодом на благо сообщества. Следите за обновлениями.
Инструмент написан таким образом, чтобы было легко расширить его функциональность фаззинга и генерации запросов в соответствии с вашими конкретными потребностями. Не стесняйтесь предлагать любые дополнения, которые могут быть полезны другим, создавая запрос на включение изменений.
Если у вас есть вопросы по библиотеке, обязательно ознакомьтесь с документацией по исходному коду. Если вопросы остались, свяжитесь со мной по электронной почте: boris.serebro(at)imperva(dot)com.
Пожалуйста, откройте Issue на GitHub и включите как можно больше информации. По возможности предоставьте пример кода, иллюстрирующий проблему, с которой вы столкнулись. Если ошибка возникает только в определённом репозитории, по возможности укажите ссылку на него. Не открывайте Issue на GitHub для получения помощи, только для сообщений об ошибках.