オープンソースツールで60分でAPIをハックする方法
APIとは？
APIは、アプリ間の通信を可能にする仲介機能です。
参考リンク：
- APIセキュリティガイド（初心者・上級者向け）
- APIテストとは：その利点、種類、始め方
- OpenAPIチュートリアル：概要、例、ツール
API は利用者によって実際に異なる
本節では、API の概要や動作、また異なる目的で利用する方々の視点から解説します。
Back-end developer
- フレームワーク：一貫した操作方法
- 仕様：RESTの場合はswaggerベース、またはOpenAPI（サーキットバージョン3）やGraphQL、protobuf向けの別スキーマ、geo pcの記述など
- HTMLマークアップは不要。10年前はデータとマークアップが一体でしたが、現代のバックエンド開発者はモバイル、ブラウザ（シングルページアプリ）や企業間連携など、利用元ごとに明確な境界を設けています
- モバイル、ウェブ、連携に対応する統一バックエンド
DevOps
- 仕様と運用の一致：このエンドポイントが頻繁に502を返すべきか？すべての問題は軽減する必要があります。
- スケーリング：どのマイクロサービスをどう拡張し、このエンドポイントの504を解消するか？REST API情報、GraphQLなど、様々な方向で対応可能です。
Security
- 新しいプロトコル：従来のファイアウォールやスキャナーは機能しません。
- 東西のセキュリティ：ネットワーク内で相互に通信しているのですか？
- 新たなコンプライアンス
攻撃シミュレーションとファジングの違いは？
オープンソースのAPIセキュリティツールに詳しければ、多くがファジングであると容易に判断できるでしょう。要は、他者のファジングツールなのです。
Fuzzing payloads
基本的な違いは、ファジングペイロードにあります。
ファジングと攻撃シミュレーションを比較するのは、特定の惑星と宇宙全体を比較するようなものです。宇宙のように無限に広がるファジングペイロードは、さまざまなアイデア、テンプレート、ランダムなデータやフィールドを適用可能です。
技術的には、ファジングは無限の宇宙の一部、または攻撃シミュレーターとして扱える一部分のようなものですが、ペイロードの数だけが両者の唯一の違いではありません。
Attack behavior
攻撃の総和は挙動にも現れ、ファジングテストでリスク条件を見つけるのは難しいです。捉えやトリガーは可能でも、実際に発生するか、既に起きたのか、また認証情報の扱いやブルートフォース攻撃、API、ビジネスロジックの乱用など、判定は非常に困難です。ファジングはアプリのビジネスロジックと深く統合し、理解する必要がありますが、APIスキーマやOpenAPIがあっても、APIエンドポイント間の相互作用を定義するのは難しいのです。
Attack payloads
これには、テンプレート、プリセット、既知の攻撃などが含まれ（既知の攻撃のみ）、構成されます。
オープンソースの API セキュリティツール
ツールは3種類に分類可能です：
The fuzzing:
ファジングは、状態を持たないエンドポイントに対応した手法です。たとえば、状態の変更なく決まった動作が保証されるエンドポイントでは利用できますが、カート内のアイテムを保持したまま一部削除するなど、より複雑な操作には対応できません。これらのツールは、単純にデータ送信に特化しているため、図やGraphQLの記述情報を活用できません。
Speed limit attacks:
レートリミット、すなわちAPIリクエストの制限は重要です。DDoS攻撃が制限なしのリクエストでシステムを圧倒する可能性があるためです。APIの柔軟性を確保するためにも必要です。
Known statement attacks:
既知のステートメント攻撃とは、送信すべき内容と攻撃時に発動するトリガーが既に決まっている攻撃です。
| 状態を持たない単一エンドポイントのファジング | レート制限攻撃（ブルートフォース、レース型） | 既知の無状態攻撃シミュレーション | |
|---|---|---|---|
| REST | RESTler, Dredd, schemathesis, ZAP | ZAP, ab, curl | ZAP, GoTestWAF |
| GraphQL | Schemathesis, ZAP | ZAP, ab, curl | ZAP, GoTestWAF |
| gRPC | - | - | GoTestWAF |
| WebSocket | ZAP | ZAP, ab, curl | ZAP, GoTestWAF |
| XMLRPC | ZAP | ZAP, ab, curl | ZAP, GoTestWAF |
| SOAP | ZAP | ZAP, ab, curl | ZAP, GoTestWAF |
| Custom API | ZAP with extensions | ZAP, ab, curl with row requests | ZAP, GoTestWAF |
APIセキュリティテストツールの概要
ZAP
効果的で強力なプロキシで、明瞭なGUIを備えていますが、gRPCはサポートせず、自動化が難しい面があります。適切に動作させるにはサンプル生成が必要です。
RESTler, Dredd
Swagger/OpenAPIベースのファジングツールです。Swagger editorを活用しており、状態を持たない単一エンドポイントのテストに適しています。
Schemathesis
RESTler/DreddにGraphQLサポートを加えたツールです。
ab/jmeter/yandex-tank
レートリミットチェック、credential stuffing、レース条件、ブルートフォース攻撃に利用できる負荷ジェネレーターです。
印象的な攻撃シミュレーションCLIツールです。すぐに使えるPDFレポートや、gRPC、GraphQL、WebSocket、Restのサポートを備えており、唯一のgRPC攻撃ジェネレーターです。
ファジングの手法
ファジングについての基本事項を紹介します。
- メソッドの抽出 (/user/debug、SET / HTTP/1.1 等)
すべてを確認するための最初のステップです。スラッシュやエラーなどもチェックし、RESTなどのHTTPSリクエストメソッドやHTTPベースのAPIも試す必要があります。ドキュメントだけに頼らず、実際に検証することが大切です。
- 型の不一致 ( {"login":true} )
型の不一致は非常に強力な攻撃手法です。HTTPリクエスト内に機能呼び出しを囲む形で、ブール値などの5種類の型変換を利用し、アプリのビジネスロジックに影響を及ぼす可能性を検討します。
- ラストバイトの変更：?username=admi%00
メモリ問題などの理由から、ラストバイトに着目した非常に強力なファジング手法です。1バイトの変更で大きな影響を及ぼします。
- ランダムバイトの変更：?username=ad%00in
ランダムな位置のバイト変更は複数箇所で可能ですが、ラストバイトは常に迅速に検知されるべきです。
- ペイロードの追加：?username=admin%27
5番目の手法は、XSSコードや特定API用のシリアライズペイロードなど、既知のペイロードを末尾に追加する方法です。
- 他のリクエストからのパラメータ（例：ログアウト時のパスワード）
他のリクエストのパラメータを利用する発想は、異なるリクエスト間でデータを変異させる優れた方法です。
- 数値の増減：/user/100001/status
負の数値や極大な数値など、数の操作に対応します。
- fuzz.txt のファイル名
Githubで容易に見つかるfuzz.txt内のファイル名を利用します。
ファジングテストの利点
- ファジングテストはセキュリティテスト手法の発展に寄与します。
- ファジングで発見されるバグは、クラッシュ、メモリリーク、例外未処理など、重大な問題につながる場合があります。
- 審査ツールで検出されなかったバグも、ファジングで見つかる可能性があります。
ファジングテストの欠点
- ファジングテスト単体では、全体のセキュリティリスクやバグを網羅できません。
- クラッシュを引き起こさない脅威（ウイルス、ワーム、トロイの木馬など）への対策は不十分です。
- 基本的な欠陥やリスクしか検出できません。
- 効果的に実施するには十分な時間が必要です。
- 不規則な情報源で境界値を定義するのはリスクが高く、多くの審査ツールはクライアント入力に基づく定量計算を用いています。
リストのファジング最適化
まずデータ構造を理解し、次の対策を講じます：
- 機械学習（HMMからRNNまで）
- 言語パターン（動詞と名詞）
- テンプレート（正規表現、シラブル）
APIファザーの例
例 1. 1バイトファザー
?ref=http://aaa/%00aaaaaaaaaaaaaaaaaaa aaNginxモジュール内でのメモリ破損。ランダムなメモリ読み取り（heartbleed類似）。
プロキシ応答において、HTTPヘッダーの処理に脆弱性があり、キーまたは値にNULLバイトが含まれると情報漏洩が発生します。
ngx_http_proxy_process_headerは、HTTPヘッダー内のNULLバイトを正しく処理するngx_http_parse_header_lineを呼び出します。しかし、ヘッダーキー／値をコピーする際にngx_cpystrnを使用し、最初のNULLバイトでコピーが停止するため、残りのデータバッファがそのままとなり、情報が漏れる可能性があります。
金融系サイトで実際に確認されました。GETパラメータの変更により、nginxプロキシサーバがNULLバイトを含むLocationヘッダーを返し、クッキー、ログ出力、（推測ですが）他のリクエストのボディ内容が漏洩しました。
例 2. 1バイトファザー
{"method":"test%26method%3ddeleteUser"}
SSRF がURL文字列内のバックエンドAPIに影響
727 call('/api/?method='+$data) …
GET /api/?method=test&method=deleteUser
HOST internal.api.host例 3. 1バイトファザー
<Image><![CDATA[http://test.com\n
rm -rf / ;]]</Image>改行文字の挿入によるRCE
また、Yandex RCE（2014）Re: [Ticket#13111203410381979]
Market feedparser - Pythonでの別のRCE（例3）
標準ペイロード（例：`id` $((id)) |id|）ではカバーされません。
この例は約7年前に発見され、WallarmのCEOが当時のxmlやpcに基づくYandexインフラにおけるコード実行を確認しました。改行の1バイトでURLを超えるデータ送信が可能となり、Pythonスクリプトにデータが渡され実行された、リモートコード実行攻撃です。
例 4. 1バイトファザー
https://research.facebook.com/search?q=a%20 HTTP 200
https://research.facebook.com/search?q=a%22 HTTP 500
ElasticSearchのJSONにインジェクション。$1000の報奨金。場合によってはRCEの可能性も…
Facebookに関連した1バイトファザーの例です。research.facebook内部で実行される内部JSONリクエストにおいて、特定のダブルクォートがリクエストを破壊し、任意のJSONフィールドのインジェクションが可能でした。
例 5. 1バイトファザー
GET / HTTP/1.1
COOKIE: sessionid=a8cf5d724a7f56e490cab37%0a改行バイトがサーバタイムアウト（504）を引き起こします。
%0aset+key+0+1+3600+10%0a1234567890%0aこれはMemcacheに関連した例で、対象サービスは脆弱であり、1文字のファザーで発見されました。
例 6. リストベースファザー
Salesforceの良い例です。約4年前、内部APIの詳細ログを返す非公開のエラーエンドポイントを発見しました。
例 7. リストベースファザー
SET /user/data HTTP/1.1
Host: api.test.comこれはRESTや非CRUD APIに関連し、HTTPリクエスト（送信、設定、削除、下書きなど）により予測不能な挙動を引き起こす可能性があります。フレームワークの特性や実装の違いによるもので、レガシーAPIに対する有力なファジング手法です。
例 8. 名詞のファジング
https://github.com/wallarm/fast-detects/blob/master/spring-cloud-infoleaks.yaml
Artsploit（Veracode）によるJolokiaに関連（CVE-2019-xxx）。
POST /endpoint/env HTTP/1.1この例は予測不可能なエンドポイントに関するものです。Covid-19以前の約2年前に発見され、Veracodeの別担当がJuklaの脆弱性を利用する方法を確認しました。任意のエンドポイントにメソッドを送信してデータダンプを取得します。
例 9. 型キャスト
POST /user/login HTTP/1.1
HOST: api.somethings.com
{"token":true, ...}
{"token":{} [] ...REST、JSON、その他の要素では、送信可能な領域、オブジェクト、真偽値、数値などを考慮する必要があります。文字列の境界も検証し、エンドポイントの反応を確認することで、認証回避などのエラーや論理バイパスを発見できます。
例 10. 型キャスト
PUT /api/v1/user HTTP/1.1
Content-Type: application/JSON
PUT /api/v1/user HTTP/1.1
Content-Type: application/xml型キャストはAPIフレームワークに関連し、JSONからXMLまたはその逆に切り替えることで、本来設計されていないエンドポイントに異なる形式のデータを送ることができます。フレームワークやAPIゲートウェイによって、想定外の利用が発生する可能性があるため、確認が必要です。
HTTPの非CRUDメソッド、CRUDの別名、およびWebDAV風の手法
- SET
- REMOVE（DELETEの代わり）
- DEBUG
- TRACK
- FORWARD
- MOVE
- INFO
見つけ方は、すべての動詞を使ってファジングを実施することです。
ハッカーの視点によるAPIリクエスト
GET /user/7456438/add HTTP/1.1
HTTP/1.1 入力された文字列やデータを、ハッカーとして技術的に解析することが重要です。動詞であれば動詞辞書、区切り文字であればその記号として、名詞なら名詞辞書、識別子や数値なら負の数や特定シナリオのテンプレートを適用することで、より効果的なファジングが可能です。
また、前述のツールも役立ちます。テンプレートやペイロードの定義は重要で、これはREST APIエンドポイントの解析に関する個人的なチートシートともいえます。
結果の解析
スキャナーは脆弱性と偽陽性を検出し、ファザーは異常値を検出します。
これらのデータをどのように解析するか？
誰がこの作業を行うのか？
統合テストや協力体制の例
- 5xxエラーなし
- 1ms以上の応答なし
ファザーは多数のロックを生成するため、その解析には個別の観点が必要です。
APIシミュレーションのベストプラクティス
脅威に対処する最善の方法は、全体のセキュリティ意識を高めることです。脅威の存在を示すことは、セキュリティを重視する第一歩です。以下は、脅威モデル作成や再評価の際に採用できる基本的な手順です：
調査の深度と範囲を明確にする
関係者と共に脅威の規模を評価し、各グループに明確な調査目標を設定することで、製品の脅威をより効果的に把握できます。
脅威の内容を視覚的に把握する
アプリ、データセンター、クライアント、データベースなど、主要な要素とその相互作用の概要を図示してください。
攻撃の可能性をモデリングする
システムリソース、脅威専門家、セキュリティコントロールの関係を図にしてセキュリティモデルを構築すると、STRIDEなどの手法で問題点を指摘しやすくなります。
脅威を区別する
システムに対する攻撃の可能性を評価するため、以下の問いを設定してください：
適切なコントロールなしでリソースにアクセスできる可能性はあるか？
脅威専門家はこのセキュリティコントロールを突破できるか？
この種の攻撃に対して、どのように対応すべきか？
欠如または脆弱なセキュリティコントロールの一覧を作成する
脅威専門家の意見を参考にし、不適切なセキュリティプロトコルが使用されていないか確認してください。これは潜在的な攻撃の兆候です。コントロールが突破されるかどうかを十分に検討することが求められます。
オープンソースのGoTestWAFツールを用いたAPI攻撃シミュレーション
ペイロードやファジングテンプレートに煩わされることなく、攻撃シミュレーション専用に開発されたツールのデモを紹介します。これらのシンプルなツールを用いて、APIのセキュリティが十分か、またシステムが粒状攻撃に対して脆弱かどうかを確認できます。次に、GoTestWAFを使ったAPIハッキングの手法を説明します。
GoTestWAF - API/WAFテストの自動化
オープンソース：
ダウンロードと実行が簡単なオープンソースツールです。
偽陰性と偽陽性の両方をテスト：
パスの検証や、ウェブアプリケーションファイアウォールなどのプロキシが効果的に動作しているかをチェックするためのツールです。
REST、GraphQL、SOAP/XML、WebSocket、JSON、gRPC：
様々なAPI機能に対応し、gRPCのような未対応ケースにも応じる形で攻撃シミュレーションのフレームワークが構築されています。
多重エンコーディング対応（JSON内のbase64など）：
全プロトコルに対応し、必要に応じてさらに追加することも可能です。
コーディング不要のチェック（YAMLファイル）：
YAMLファイル内のコード不要なチェックに対応して設計されており、チェック内容を自由に選択し、該当ファイルを例としてリクエストを生成します。
ツールはYAMLファイルに定義されたチェックをもとにリクエストを生成します。
Docker対応：
Docker上で動作します。
初期設定でのPDFレポート：
ツールは初期設定で動作し、開発者やチームとの協議時に有用なPDFレポートを提供します。
コミュニティペイロード（Vulnersに感謝）：
コミュニティによって提供されたツールです。Vulnersチームの尽力により、多数のコミュニティペイロードが利用可能となりました。
動作の仕組み
./testcase →
testcase →
testset (yaml file) →
[ [payload], [encoder], [placeholder] ]これは、テストケース名に加え、プレースホルダー、ペイロード、エンコーダという3つの独自パラメータを持つ基本構造です。
つまり、ペイロードテスト（有害な攻撃テスト、例：XSS文字列 "< script>alert(1)< /script>"）は最初にエンコードされ、HTTPリクエストに配置されます。文字列をそのまま保持するエンコーダを選ぶことも可能です。
テストを分かりやすくするために、YAML DSL（payload→encoder→placeholder）の構造を採用しています。各項目ごとに段階的にテストを実施します。
Payload
送信する文字列はペイロードと呼ばれます。例：< script>alert(111)< /script> など。基本的にマクロは使いませんが、必要であれば対応してください。
Encoder
ペイロードは、このツールでエンコードされます。Base64、JSONユニコード（u0027形式）など、多様な形式に対応しています。
Placeholder
エンコードされたペイロードは、HTTPリクエスト内のURLパラメータ、URI、POSTフォーム、またはJSON POSTなどの該当部分に格納されます。
Testing for false positives
次のステップでは、偽陰性をチェックする際より厳格なプロトコルで偽陽性を検証します。これにより、本番環境での予測不可能な変数を回避できます。
効果的な偽陽性対策は、実際の利用者がアクセス拒否される前に早期検出することです。ModSecurity、libinjection、正規表現ベースのオープンソースWAFにおける明白な偽陽性を検証するため、Gutenbergライブラリの899行ごとに分割された書籍を利用しました。
次のフォルダは偽陽性を特定するために設計されています：
./testcases/
false-pos は偽陽性テストケースの予約名
testcases/false-pos:
texts.yml
testcases/owasp:
ldap-injection.yml nosql-injection.yml shell-injection.yml ss-include.yml xml-injection.yml
mail-injection.yml path-traversal.yml sql-injection.yml sst-injection.yml xss-scripting.yml
testcases/owasp-api:
graphql.yml rest.yml soap.yml
各テストケースは、ペイロード、エンコーダ、プレースホルダーの3つのセクションを持つYAMLファイルで構成されます。
- Payload
- Encoder
- Placeholder
GoTestWAFが送信可能なリクエスト数は、ペイロード1、エンコーダ2、プレースホルダー3の組み合わせ、すなわち1x2x3x6件に依存します。
PDF及びコンソール出力レポート
ツールがリクエスト送信後に特定のレスポンスを取得した際のレポートです。統計情報を集約し、検出件数とスキャン件数を示します。
.jpeg)
更新：オンラインスキャナー公開 - GoTestAPI
まとめ
2021年以降、単にAPIが安全であると断言するだけでは不十分です。パンデミック以降、API侵害が増加しており、直接アプリやデータにアクセスできるため、APIを守ることはこれまで以上に重要です。だからこそ、高度なAPIセキュリティが求められます。WallarmはエンタープライズAPIセキュリティを提供しており、本稿では必要な高度なAPIプロトコルについて解説しました。
FAQ
参考資料
最新情報を購読
