
Impervaのカスタマイズ可能なAPI攻撃ツールは、API仕様を入力として受け取り、それに基づいた攻撃を生成して実行します。
Impervaのカスタマイズ可能な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.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}
なぜチェックは失敗したのでしょうか?リクエストは有効なURLを含んでいないにもかかわらず、200を取得しました。
***** 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仕様に従って、存在しないが有効なユーザー名を指定しました。サーバーはこのリクエストを適切に処理し、正当なエラーを返しました。
ここでは、エンドポイントURLとメソッドのタプルとしてendpointという用語を使用します。
コミュニティの利益のために、他のシナリオもオープンソースツールに移行する作業を進めています。今後のアップデートにご期待ください。
このツールは、ファジングおよびリクエスト生成機能を特定のニーズに合わせて簡単に拡張できるように設計されています。プルリクエストを作成して、他の人にも役立つ追加機能を提案してください。
ライブラリに関する質問がある場合は、ソースコードのドキュメントを確認してください。それでも質問がある場合は、メール 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