脆弱性スキャナーでは RESTful API 仕様が重要です
APIGit
2023-07-27
Web アプリケーションの脆弱性を見つけるにはどうすればよいですか?
現在、サービスにアクセスするために Web API を提供する企業が増えています。通常、これらは REST スタイルに従います。このような RESTful Web サービスは、通常の Web アプリケーションのように見えます。 HTTP リクエストを受け入れ、何らかの魔法を実行して、HTTP レスポンスで応答します。主な違いの 1 つは、通常、応答には Web ブラウザーで表示される HTML が含まれていないことです。代わりに、通常、応答には、別のアプリケーションで処理しやすい形式 (JSON や XML など) のデータが含まれます。
残念ながら、RESTful Web サービスは依然として Web アプリケーションであるため、SQL インジェクション、XXE などの Web アプリケーションの典型的なセキュリティ脆弱性が含まれている可能性があります。Web アプリケーションのセキュリティ問題を特定する方法の 1 つは、Web セキュリティ スキャナーを使用することです。幸いなことに、RESTful Web サービスは依然として Web アプリケーションであるため、Web セキュリティ スキャナーを使用して Web API のセキュリティ問題を探すことができます。
有名な Web セキュリティ スキャナーがいくつかあります。そのうちの 1 つは w3af です。
w3af はどのようにして脆弱性を見つけますか?
w3af は、Web アプリケーションの攻撃と監査のフレームワークです。このプロジェクトの目標は、Web アプリケーションのすべての脆弱性を見つけて悪用することで、Web アプリケーションのセキュリティを確保するのに役立つフレームワークを作成することです。このフレームワークには、脆弱性の発見に役立つ数百のプラグインが含まれています。
クロール プラグインは、さまざまな手法を使用して、監査フェーズやブルートフォース フェーズ中に使用できる可能性のある新しい URL、フォーム、その他のリソースを識別します。言い換えれば、これらのプラグインはアプリケーションを参照し、テストするエントリ ポイントを検出しようとします。
監査プラグインは、クロール プラグインによって作成された情報を使用して、リモート Web アプリケーションおよび Web サーバー上の脆弱性を検出します。これらのプラグインは、発見されたエントリ ポイントの脆弱性をテストします。
いくつかのプラグインを有効にすると、いくつかの脆弱性が見つかる可能性がありますが、それほど多くはありません。これは私の spring-boot Web プロジェクトの結果です。通常、Web スキャナは Web サイトを参照して、脆弱性をテストできる利用可能なすべてのページとパラメータを見つけようとします。典型的な Web サイトの場合、スキャナは多くの場合、ホームページから開始して、HTML コード内の他のページへのリンクを探します。ただし、このアプローチは Web API では機能しません。通常、API エンドポイントは HTML データを提供せず、API は通常、応答で相互に参照しないからです。
{
"items": [
{
"href": "/scans/1/kb/0",
"id": 0,
"name": "Strange HTTP Reason message",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/1/kb/1",
"id": 1,
"name": "Cross site tracing vulnerability",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/1/kb/2",
"id": 2,
"name": "Omitted server header",
"url": null
},
{
"href": "/scans/1/kb/3",
"id": 3,
"name": "Allowed HTTP methods",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/1/kb/4",
"id": 4,
"name": "Click-Jacking vulnerability",
"url": null
}
]
}
RESTful API 仕様はスキャナーにとって重要です
スキャンする API エンドポイントとパラメータのリストを取得するにはどうすればよいでしょうか?主に次の 2 つの方法があります。
- #1 RESTful API 仕様 Web サービスには、すべてのエンドポイント、パラメータ、応答、認証スキームなどを記述する OpenAPI 仕様がある場合があります。このような仕様は通常、開発者によって提供されます。
- #2 プロキシ プロキシを使用すると、クライアントによって API エンドポイントに送信された HTTP リクエストをキャプチャできます。次に、キャプチャされたリクエストを解析し、パラメータに関する情報を抽出できます。
#1 の方法は #2 よりもはるかに優れています。理想的な世界では、各 Web サービスには OpenAPI 仕様があり、常に最新の状態で利用できます。しかし現実の世界では、それはそれほど頻繁に起こることではないようです。開発者は API を変更しても仕様の更新を忘れたり、何らかの理由で仕様を公開していない可能性があります。ほとんどの場合、公開されている REST API には人間が読めるドキュメントが含まれており、これは便利ですが、自動化された方法で使用するのは通常困難です。
- しかし、APIGIT を使用するとこれが簡単になります。
APIGIT は、ネイティブ Git サポートを特徴とするコラボレーション プラットフォームです。これにより、API 開発プロセスとバージョン管理が簡素化され、ユーザーが API を簡単に設計、文書化、モック、テスト、共有できるようになります。このプラットフォームのビジュアルな OpenAPI エディターをネイティブの Git サポートと組み合わせることで、チームはシームレスかつ効率的な方法で共同作業し、作業を共有することが容易になります。
w3af は RESTful API 仕様に従ってどのように脆弱性を見つけますか?
これは私の RESTful API 仕様の一部です。
"paths": {
"/find_pet": {
"get": {
"summary": "List pet",
"operationId": "listPet",
"tags": [
"pet"
],
"parameters": [
{
"name": "version",
"in": "query",
"description": "Get pet by version",
"required": true,
"type": "string"
}
],
関連するプラグインを有効にして、RESTful API 仕様を使用してフィードします。
[crawl.open_api]
custom_spec_location = /var/log/wvs/openapi2.json
no_spec_validation = Trueさらに多くの脆弱性が見つかる可能性があります。
{
"items": [
{
"href": "/scans/0/kb/0",
"id": 0,
"name": "Strange HTTP Reason message",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/1",
"id": 1,
"name": "Omitted server header",
"url": null
},
{
"href": "/scans/0/kb/2",
"id": 2,
"name": "Cross site tracing vulnerability",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/3",
"id": 3,
"name": "Open API specification found",
"url": "file:///var/log/wvs/openapi2.json"
},
{
"href": "/scans/0/kb/4",
"id": 4,
"name": "Allowed HTTP methods",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/5",
"id": 5,
"name": "Cross site scripting vulnerability",
"url": "http://192.168.1.65:8181/find_pet"
},
{
"href": "/scans/0/kb/6",
"id": 6,
"name": "Unhandled error in web application",
"url": "http://192.168.1.65:8181/_pet"
},
{
"href": "/scans/0/kb/7",
"id": 7,
"name": "Unhandled error in web application",
"url": "http://192.168.1.65:8181/find_"
},
{
"href": "/scans/0/kb/8",
"id": 8,
"name": "Unhandled error in web application",
"url": "http://192.168.1.65:8181/"
},
{
"href": "/scans/0/kb/9",
"id": 9,
"name": "Strange HTTP response code",
"url": "http://192.168.1.65:8181/%2Fbin%2Fcat+%2Fetc%2Fpasswd_pet"
},
{
"href": "/scans/0/kb/10",
"id": 10,
"name": "Click-Jacking vulnerability",
"url": null
}
]
}
では、crawl.open_api プラグインについて話しましょう。プラグインの最初のバージョンは、次のような既知の場所のいずれかで OpenAPI 仕様を見つけようとしました。
/api/openapi.json
/api/v2/swagger.json
/api/v1/swagger.yaml
等々。とても素晴らしい機能です。テストする Web サービスが複数あり、その API 仕様がよく知られた場所で入手できる場合は、スキャナーにホスト名を入力するだけで済みます。スキャナーはすべての API エンドポイントを独自に検索し、テストします。残念ながら、Web サービスでは API 仕様が提供されていない場合があり、custom_spec_file パラメーターを使用して OpenAPI 仕様へのローカル パスを設定できます。ユーザーは API ドキュメントを使用して自分で仕様を構築できます。また、仕様が公開されていても、よく知られている場所にない場合もあります。
© 2024 APIGit Inc.