タイで効果的なAPIペネトレーションテスト

アプリケーションが「ウェブサイト」だったのは何年も前です。今はAPIです。マイクロサービスがマイクロサービスを呼び、片端にモバイルクライアント、もう片端に決済インフラ。しかしセキュリティの議論はまだ追いついていません。努力の80%がフロントエンドに費やされる「ウェブアプリケーションペネトレーションテスト」を依然購入し、その背後のAPI、お金とデータが実際に動く場所は過小テストのままです。

APIがスキャナーを退ける理由 #

自動Webスキャナーはページモデルを前提に作られています。リンクを巡回し、フォームを見つけ、ペイロードを注入する。APIはページを提示しません。ルートとメソッドとスキーマを提示し、興味深い動作はその間のビジネスロジックにあります。

オブジェクトレベルアクセス欠陥を考えてください。ユーザーがリクエストのuser_id=1024をuser_id=1025に変えて他人のレコードを読む。シグネチャは鳴らず、悪性ペイロードもありません。スキャナーは正常なリクエストと見て先へ進みます。これがBroken Object Level Authorisation(BOLA)、 OWASP API Security Top 10の第1位であり、ほぼすべての自動ツールに見えないものです。

これがヒューマン主導APIテストの核心的論拠です。最も被害の大きい欠陥は設計欠陥であり、設計欠陥の発見には業務文脈を理解するアナリストが必要です。

有効なAPIテストが実際にカバーするもの #

意味のあるAPI評価はOpenAPI仕様へのスキャナー実行を大きく超えます:

認証と認可: トークン処理、スコープ確認、あらゆる役割境界でのオブジェクトレベルアクセス。
ビジネスロジック: ユーザーは注文に負の価格を設定できるか、支払いコールバックを再生できるか、次のエンドポイント直呼び出しでワークフローステップを飛ばせるか?
データ露出: どのエンドポイントが過剰にフィールドを返すか、クライアントが送るべきでないフィールドを受け付けるのはどこか。
レート制限と濫用: 列挙、クレデンシャルスタッフィング、弱いスロットリングを突くアカウント乗っ取り経路。
統合境界: webhook、サードパーティコールバック、メッセージキュー。信頼が暗黙に仮定され、検証されない場所たち。

だからこそ最高のエンゲージメントは手動攻撃技術とAI支援のリコン・ファジングを組み合わせます。自動化がカバレッジを広げ、人が重大度と文脈を判断します。

年次ではなく、継続で #

年に一度のAPIテストは、週次でデプロイされるシステムの時点スナップショットです。報告書が書き上がる頃にはエンドポイントは変わっています。現代的アプローチはAPIセキュリティチェックを配信パイプラインに折り込みます:

CIでの静的解析とスキーマ検証によるシフトレフト。
リリースごとのテスト: API表面が変わったときの焦点を絞ったレビュー。
年次ディープダイブ: 監査証跡と、パイプラインが判断できないビジネスロジックのための全面的なヒューマン主導評価。

カードデータに触れる組織にとってPCI DSS 要件6と要件11.4はともにこの方向を推し進め、タイ中央銀行のデジタルチャネルセキュリティ指示も同様です。

flowchart LR A[CIのスキーマ・SAST] --> B[リリース単位のAPIレビュー] B --> C[人が主導する深層評価] C --> D[対策と再テスト] D --> A style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px

自動スキャナーが見えないもの #

自動化が何を見落とすかを具体的に語る価値があります。その隙間は無作為ではなく、まさに金が流れる場所に集中しているからです。

実戦のBOLA。 スキャナーは発見したエンドポイントと理解したパラメータしか試しません。請求書APIを例に: GET /invoices/8842は呼び出し者自身の請求書を返すのでスキャナーは合格を記録します。しかしGET /invoices/8843(他人の請求書)も同じく快く返るかもしれず、どのスキャナーも試しません。8843が他人のものだと知るには所有権が貴社ビジネスで何を意味するかの理解が要るからです。テナント境界を越えるすべてのオブジェクト識別子が潜在BOLAで、アカウントをまたいでオブジェクトを列挙するアナリストだけが見つけられます。

ビジネスロジック欠陥。 スキャナーはリクエストの成否を試します。ロジック欠陥は成功すべきでないのに成功するリクエストに住んでいます。engagementから出た実例: 紐付け確認が決済キャプチャ後に行われるためクーポンコードが二度使える; 再認証なしで予約を別アカウントへ移せる; キャンセルエンドポイントが履行状態を確認しないため出荷済みの有料注文を取り消せる。どれもHTTP 200を返します。どれもエラーメッセージひとつない金銭損失です。

マイクロサービス間の信頼前提。 マイクロサービス環境では、あるサービスは「呼び出し側」が提示するヘッダーやトークン、内部エンドポイントを慣習的に信用します。設計図では呼び出し側は常に内部サービスだったからです。そしてある日、一つのサービスが侵害されるか、ある内部エンドポイントがより信頼度の低いネットワーク区画から到達可能になると、受け継がれた信頼前提が攻撃者の梯子になります: 弱いエッジサービスで先に認証し、その正体を価値あるAPIがいる下流へ差し出すのです。これを見つけるには設計者の意図通りにアーキテクチャを読み、攻撃者が通る経路として試す必要があります。

この三つはどれもスキャナー出力に現れません。全部、貴社APIが実際に何のために作られたかを理解する時間を使ったアナリストの報告に現れます。

あなたのAPIが攻撃者にどう見えているか知りたいですか? 気軽に簡易チェックをご相談ください。LINE(@PureSecurity)またはメール(hello@puresecurity.com)まで。

当社のAPI & アプリケーションセキュリティレビューは手動ソースコード分析と文脈化されたペネトレーションテストを組み合わせ、開発者がすぐ使える是正ガイダンスを提供します。境界やセグメンテーションの幅広い検証が必要でしたらヒューマン主導ペネトレーションテストをご覧ください。