APIセキュリティテストツールの4つのカテゴリ
スキャナー
既知の脆弱性クラスや設定の不備を探索します。
網羅範囲は広い一方で、自社のビジネスルールは理解していません。
プロキシとインターセプター
人がトラフィックを観察し、改変できるようにします。
強力ですが、操作する人の力量に完全に依存します。
ファザー
不正な形式の入力をエンドポイントに送り込み、クラッシュを探します。
堅牢性の問題を見つけられますが、トリアージを要するノイズも生み出します。
4つ目が 振る舞いの検証です。APIが拒否すべきものを拒否しているか、という観点です。認証されていない呼び出し、アカウントをまたいだアクセス、ロールの境界、期限切れのトークン。これらはスキャナーでは確認できません。何を権限とみなすかが、自社のプロダクトの定義に依存するからです。
多くのチームが抱えている空白
多くのチームは、パイプラインにスキャナーを組み込み、年に一度ペネトレーションテストを実施しています。どちらも有用です。しかし、先週の火曜日にリリースされたエンドポイントがオブジェクトレベルの認可を適用しているかは、どちらも確認しません。そしてそれこそが、実際のAPIで最も多く悪用される欠陥です。
これが確認されないままになる理由は、技術的なものではなく組織的なものです。セキュリティの問題に見えるため、四半期ごとに回るセキュリティのプロセス待ちになります。しかし実際には、変更のたびに実行されるテストスイートに属する、振る舞いのチェックです。
自社の空白がどれかを見分ける方法
ユーザーAがユーザーBのデータを読み取れないことを、最後に誰かが検証したのはいつか、答えられますか。 その答えが年次のペネトレーションテストであれば、最も起こりやすい欠陥に対して12か月の空白期間があることになります。
新しいエンドポイントには、権限のチェックが自動的に付きますか。 実装者が覚えているかどうかに委ねられているなら、いずれ漏れます。
スキャナーの検出結果は、トリアージされていますか。それとも溜まる一方ですか。 誰も読まない検出結果を出し続けるスキャナーは、スキャナーがない状態よりも悪い状態です。カバーできているように見えてしまうからです。
振る舞いの空白を埋める
生成されるAPIのテスト計画には認可と境界値のカテゴリが含まれるため、権限のチェックは別枠の作業としてではなく、機能面のカバレッジと並んで存在します。これにより、権限のチェックは変更のたびに実行される頻度になります。新しいエンドポイントに追随できる頻度は、これだけです。
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
ローカルに何もインストールしたくない場合は、TestSpriteのダッシュボードからも同じ設定を行えます。CLIのその他の機能については、 CLIリポジトリをご覧ください。
具体的な仕組みは、 APIテストのドキュメントに記載しています。
トリアージ、あるいはスキャナーが意味を失っていく理由
スキャナーには、よくある特有の失敗の仕方があります。ツールは動き続けているのに、誰もその出力を読まなくなるのです。これはツールの問題ではないため、理解しておく価値があります。
最初の実行では長いリストが出力され、その多くは自社には当てはまりません。すべてに目を通す時間はないため、ざっと眺めるだけになります。次の実行では同じリストに新しい項目が2件加わりますが、既存のノイズに紛れて見えません。四半期も経てば、レポートは生成されてアーカイブされるだけの成果物になり、本物の検出結果が1年間そこに埋もれたままということも起こり得ます。
対処法は地味です。最初のリストを一度だけ、きちんとトリアージし、当てはまらないものは理由を書き添えて抑制します。そうすればレポートには変化した点だけが表示され、これなら実際に読んでもらえます。トリアージされていないスキャナーは、ない場合よりも悪い状態です。カバーできているという見かけだけを生み出すからです。
何を、どこで実行するか
振る舞いのチェックは、プルリクエストのたびに。スキャナーは、定期的なスケジュールで。プロキシとファザーは、集中して調査にあたる担当者の手に。ペネトレーションテストは、カレンダーが告げたときではなく、脅威モデルが変わったときに。
パイプラインが他のチームの管轄であれば、 GitHub App が最も抵抗の少ない方法です。webhookとして動作し、リポジトリには何の変更も加えず、ビルドが新しいバージョンの公開を通知した時点で起動します。チェックをリポジトリ上で見えるようにしたい場合は、 GitHub Actions のステップで同じことができます。
4つ目のカテゴリでTestSpriteが提供するもの
振る舞いの検証、つまりAPIが拒否すべきものを拒否しているかの確認です。生成されるテスト計画には認可と境界値のカテゴリが含まれるため、すべてのエンドポイントについて、認証なしのアクセス、アカウントをまたいだ読み取り、ロールの境界、期限切れの認証情報が、変更のたびにチェックされます。
テストは、稼働中のサービスに対してそのインターフェース経由で実行され、何が存在するかは探索のパスと利用者の仕様から把握します。Auto-Authenticationは実行中のセッションを維持し、Dynamic Variablesは呼び出し間で値を引き渡し、Dependency Chainsは各テストケースが必要とするものと生成するものから実行順序を導き、Auto-Cleanupはその実行が作成したものだけを削除します。
得られるのは、オブジェクトレベルの認可が誰かの記憶頼みでなくなることです。スキャナーは依存関係やインジェクション系のクラスを、ペネトレーションテストは創意工夫を要する悪用を、それぞれ引き続き担当し、その間にあるカテゴリが誰の担当でもない状態ではなくなります。
TestSpriteはAPIセキュリティテストツールですか。
振る舞いのカテゴリ、すなわち認可、ロールの境界、境界値、エラー処理の適切さをカバーします。スキャナーではなく、脆弱性クラスを探索するものでもありません。
それでもスキャナーは必要ですか。
必要です。依存関係の脆弱性やインジェクション系のクラスは実在するものであり、それらにはスキャナーが適した道具です。各カテゴリは互いを補完する関係にあります。
オブジェクトレベルの認可とは何ですか。
識別子を書き換えることで、あるユーザーが別のユーザーのレコードにアクセスできてしまうかどうかを指します。APIにおける深刻な欠陥として最も多く、同時に最もテストしやすいものの一つです。
スキャナーのノイズはどうすれば止められますか。
決まったスケジュールでトリアージし、理由を添えて抑制してください。トリアージされていないバックログは、スキャナーがない状態と見分けがつきません。
振る舞いのチェックは本番環境に対して実行できますか。
本番を代表する環境に対して実行するのが、多くの場合は正解です。権限をテストするために本番でレコードを作成・削除することには、それ自体のリスクが伴います。