Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
automatic-api-attack-tool — Impervaのカスタマイズ可能なAPI攻撃ツールは、API仕様を入力として受け取り、それに基づいた攻撃を生成して実行します。 | Kitploit
ツール/GitHubGitHub/imperva/automatic-api-attack-tool
脆弱性スキャナーウェブアプリケーション悪用APIセキュリティテストファジング
GitHubimperva/automatic-api-attack-tool

automatic-api-attack-tool

Impervaのカスタマイズ可能なAPI攻撃ツールは、API仕様を入力として受け取り、それに基づいた攻撃を生成して実行します。

リポジトリを見る
495936年前Kitploit レビュー済み

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

自動API攻撃ツール

Impervaのカスタマイズ可能なAPI攻撃ツールは、API仕様を入力として受け取り、それに基づいた攻撃を生成して実行します。

このツールはAPI仕様を解析し、その仕様で定義された内容に基づいてファジング攻撃シナリオを作成できます。各エンドポイントには、仕様で定義された境界内で巧妙に生成された値が注入され、境界外では適切なリクエストが送信され、成功または失敗が詳細に報告されます。また、既存のエンドポイントや存在しないエンドポイントを対象とした、不正なリソースアクセス、XSS、SQLi、RFIなどのさまざまなセキュリティ攻撃ベクトルを実行するように拡張することもできます。 人間の介入は必要ありません。ツールを実行するだけで結果が得られます。

このツールは、APIをテストしたい開発者や、公開APIに対して定期的な脆弱性スキャンやポジティブセキュリティスキャンを実行したい組織など、さまざまなニーズに合わせて簡単に拡張できます。CI/CDを考慮して構築されています。

必要条件

  • Java 8以上
  • Gradle

実行方法

  • GitHubからコードをチェックアウトし、./gradlew build(Windowsの場合はgradlew.bat build)を実行します
  • 実行可能なjarファイルはbuild/libsフォルダにあります
  • 'java -jar imperva-api-attack-tool.jar'を実行してヘルプメニューを表示します

Linux実行可能ファイルの作成

  • src/main/resourcesフォルダからrunnable.shファイルをjarファイルと同じディレクトリにコピーします。
  • 次に実行: cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh
  • 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またはリポジトリのコードプッシュアクティビティによってトリガーされます。 TestNG プラグインがインストールされていることを確認してください。これにより、build/testng-results に書き込まれた結果が解析され、CI/CDシナリオでの可視性が向上します。

  • このAPIがファジング攻撃に対して脆弱かどうかを確認したい場合。ツールを実行して報告された失敗を確認するだけです。

チェック失敗の条件

  • ツールは、生成されたリクエストのレスポンスコードがswaggerで宣言されたレスポンスコードと一致することを検証します。 ただし、
  • ポジティブチェック: 明確なエラー(コードが5xx)の場合、たとえそのレスポンスコードが仕様で定義されていなくても、チェックは失敗とみなされます。ただし、上書きを指定した場合は除きます。
  • ネガティブチェック: レスポンスが正当なエラー(1xx、2xx、5xx)でない場合、上書きを指定しない限りチェックは失敗します。正当なエラーコードが仕様にない場合もチェックは失敗します。
  • swaggerのレスポンスセクションで'default'定義を使用することもできますが、推奨されません。常に正当な回答を正確に定義してください。

チェック失敗の条件

  • ツールは、生成されたリクエストのレスポンスコードがswaggerで宣言されたレスポンスコードと一致することを検証します。 ただし、
  • ポジティブチェック: 明確なエラー(コードが5xx)の場合、たとえそのレスポンスコードが仕様で定義されていなくても、チェックは失敗とみなされます。ただし、上書きを指定した場合は除きます。
  • ネガティブチェック: レスポンスが正当なエラー(1xx、2xx、5xx)でない場合、上書きを指定しない限りチェックは失敗します。正当なエラーコードが仕様にない場合もチェックは失敗します。
  • swaggerのレスポンスセクションで'default'定義を使用することもできますが、推奨されません。常に正当な回答を正確に定義してください。

期待される出力:

  • ツールはtestngレポートフレームワークを使用しているため、testng実行を処理するプラグインをここで使用できます。結果はbuild/testng-resultsフォルダに書き込まれることに注意してください。もちろん、これは変更可能です。
  • ツールはチェックスイートに従ってリクエストを生成し、各リクエストは特定の項目をチェックします。そのため、各チェックはコマンドライン出力に、チェック内容、レスポンス、期待通りかどうかを含むすべての関連詳細を表示します。
  • 不正なリクエストはbad_requestsフォルダに保存されるため、後で分析できます(例えば、CI/CDサーバーで実行中でマシンにすぐにアクセスできない場合など)。
  • 最後に、サマリーが提供されます。
失敗したネガティブチェックの例:
root@kitploit:~
***** 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}

なぜチェックは失敗したのでしょうか?リクエストは有効なURLを含んでいないにもかかわらず、200を取得しました。

別の例:
root@kitploit:~
***** 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値を受け入れました。これはサーバーのバッファオーバーフローを悪用しようとする際の良いポイントかもしれません。

成功したチェックの例:
root@kitploit:~
***** 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とメソッドのタプルとしてendpointという用語を使用します。

ポジティブシナリオ
  • 各エンドポイントに対して、すべてのパラメータに生成された値を持つリクエストを作成します。これらはランダムに生成されますが、API仕様で定義されたルールに従います。
  • 各エンドポイントに対して、必須パラメータのみのリクエストを作成し、上記と同様に値を生成します。
ネガティブシナリオ
  • 各エンドポイントに対して、異なるパラメータをチェックする複数のリクエストを作成します。ツールは、チェック対象のパラメータにランダムな不正な入力値を注入し、残りのパラメータをポジティブシナリオで説明したのと同じ方法で生成された「ポジティブ」な値で埋めることでこれを行います。
継続的な取り組み

コミュニティの利益のために、他のシナリオもオープンソースツールに移行する作業を進めています。今後のアップデートにご期待ください。

拡張性

このツールは、ファジングおよびリクエスト生成機能を特定のニーズに合わせて簡単に拡張できるように設計されています。プルリクエストを作成して、他の人にも役立つ追加機能を提案してください。

ヘルプの入手

ライブラリに関する質問がある場合は、ソースコードのドキュメントを確認してください。それでも質問がある場合は、メール 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