APISIX如何防范OWASP十大API安全威胁
October 6, 2023
今日の相互接続されたデジタル環境において、APIの使用と依存が増加するにつれ、それらを標的としたセキュリティ脅威も年々増加しています。2023年、Open Web Application Security Project (OWASP) は、APIセキュリティに対する新しいトップ10の脅威を特定しました。このブログ記事では、各脅威を探り、APISIXがそれらをどのように防ぐことができるかを例を交えて学びます。
OWASP は、定期的にサイバーセキュリティ関連の研究を公開する世界的に認知されたコミュニティです。
以下は、OWASPが挙げたセキュリティリスクのリストです：
- 壊れたオブジェクトレベルの認可
- 壊れた認証
- 壊れたオブジェクトプロパティレベルの認可
- 無制限なリソース消費
- 壊れた機能レベルの認可
- 機密ビジネスフローへの無制限なアクセス
- サーバーサイドリクエストフォージェリ
- セキュリティの設定ミス
- 不適切なインベントリ管理
- APIの安全でない消費
1. 壊れたオブジェクトレベルの認可
脅威: APIはしばしばオブジェクト識別子を扱うエンドポイントを公開し、これがオブジェクトレベルのアクセス制御の問題を引き起こす可能性があります。攻撃者はこれらの脆弱性を悪用して、データへの不正アクセスを獲得することができます。
例: ある医療機関がオンライン患者ポータルを提供しています。ポータルの設計上の欠陥により、患者が認証されると、URLやリクエストパラメータを変更して、別の患者IDに関連する医療記録にアクセスできるようになります。例えば、患者のスティーブが患者ポータルにログインして自分の医療記録を閲覧します。彼の記録は https://healthportal.com/patient/123 というURLでアクセス可能です。好奇心から、スティーブはURLを https://healthportal.com/patient/124 に変更し、別の患者の医療記録を閲覧できることを発見します。これは重大なプライバシー侵害であり、Health Insurance Portability and Accountability Act (HIPAA) などの規制に違反します。
推奨事項: ユーザーポリシーと階層に基づいた適切な認可メカニズムを実装します。APISIXゲートウェイは、プラグインを使用してOAuth2またはJWTベースの認可フローをサポートしています。OAuth2ポリシーを使用して、各リクエストでトークンを検証することができます。
APISIXのロールベースアクセス制御（RBAC）システムをOpen Policy Agent (OPA) と統合して、細かいアクセス制御を行います。APISIXで特定のロールと権限を設定し、これらのロールを特定のユーザーやトークンに関連付けることで、機密性の高いエンドポイントへのリクエストが適切に認可されることを保証できます。
2. 壊れた認証
脅威: 誤って実装された認証メカニズムにより、攻撃者が認証トークンを侵害したり、単にログインエンドポイントをブルートフォース攻撃したりする可能性があります。これは、レートリミットがないためです。
例: 銀行システムがカスタム認証メカニズムを実装しました。しかし、適切なセキュリティレビューとテストが行われなかったため、認証フローに脆弱性がありました。具体的には、ユーザーがユーザー名とパスワードを入力した後、システムがユーザー名とタイムスタンプの組み合わせなど、予測可能なセッショントークンを生成していました。この欠陥を知っている攻撃者は、他のユーザーのセッショントークンを簡単に予測できました。
推奨事項: まず、APIへのすべての可能な認証フローを理解し、認証において車輪の再発明をしないようにします。APISIXは標準のOpenID Connect (OIDC) 認可フローをサポートしています。予測可能なセッショントークンの代わりに、APISIXはKeycloakなどの外部IDプロバイダーやプラグインを使用してセッション管理システムと統合し、セッショントークンがランダムで暗号化され、寿命が限られていることを保証します。
ユーザーアカウントに対するブルートフォース攻撃を防ぐために、APISIXのレートリミットプラグインを使用できます。これにより、短時間に複数のログイン試行が失敗した場合、IPまたはユーザーが一時的にブロックされます。データのプライバシーと整合性を保証するために、APISIXはSSL/TLS暗号化をサポートしています。これにより、ユーザーの資格情報やその他の機密データが転送中に暗号化されます。
3. 壊れたオブジェクトプロパティレベルの認可
脅威: この脅威は、オブジェクトプロパティレベルでの認可検証が欠如しているか不適切であることから生じ、不正な情報の露出や操作を引き起こします。
例: オンラインショッピングプラットフォームのAPIは、登録ユーザーが名前、メールアドレス、配送先住所、支払い詳細などのプロファイル詳細を更新できるようにしています。さらに、各ユーザープロファイルには userType というプロパティがあり、regular または admin のいずれかです。APIの設計上の問題により、ユーザーはプロファイル更新リクエストで userType プロパティも変更できます。通常ユーザーのアリスが、ブラウザの開発者ツールを使用してAPIリクエストを検査しているときにこの欠陥を発見します。彼女は、プロファイルを更新する際にサーバーに送信されるJSONペイロードに気づきます。アリスは userType の値を admin に変更してリクエストを送信します。驚いたことに、彼女のプロファイルが更新され、プラットフォーム上で管理者権限を獲得し、機密データにアクセスしたり、製品リストを変更したり、他のユーザーの注文履歴を閲覧したりできるようになります。
推奨事項: 公開されているオブジェクトプロパティがユーザーにアクセス可能であることを確認し、ビジネス要件に基づいて返されるデータ構造を最小限に保ちます。これを実現するために、APISIXのリクエスト検証プラグインを使用して、事前定義されたスキーマに対して着信リクエストを検証できます。または、APISIXのRBACシステムを使用して、通常ユーザーと管理者のロールを設定します。クライアントに公開される不要なデータを削除するために、APISIXはレスポンス書き換えプラグインを提供しており、APIレスポンスをリアルタイムで変更できます。
4. 無制限なリソース消費
脅威: 攻撃者はAPIを悪用して過剰なリソースを消費し、サービス拒否攻撃や運用コストの増加を引き起こす可能性があります。
例: クラウドベースのファイルストレージサービスは、ユーザーがファイルをアップロードして保存し、他のユーザーと共有し、どこからでもアクセスできるようにしています。このサービスには、ユーザーが同時にアップロードできるファイル数や各ファイルのサイズに制限がありません。その結果、悪意のあるユーザーやボットが非常に大きなファイルを急速に連続してアップロードし、サーバーリソースを大量に消費することができます。これにより、他のユーザーの応答時間が遅くなり、サーバーがクラッシュする可能性があり、サービスプロバイダーのインフラストラクチャコストが増加します。
推奨事項:
- すべての着信パラメータとペイロードの最大データサイズを定義し、強制します。client-controlプラグインを使用して、リクエストボディの最大サイズを設定し、ユーザーが過度に大きなファイルをアップロードできないようにします。または、リクエスト検証プラグインを使用して、返されるレコード数を制御するクエリ文字列を検証します。不要なデータを送信するボット、スクリプト、またはユーザーエージェントをブロックするために、ua-restrictionプラグインを活用できます。
- ビジネスニーズに基づいてレートリミットを実装します。APISIXはlimit-req、limit-conn、limit-countプラグインを提供しており、個々のユーザーやIPアドレスがリクエストを送信する速度を制限できます。これにより、ユーザーがシステムに大量のリクエストを送信できないようにします。
5. 壊れた機能レベルの認可
脅威: アクセス制御ポリシーが複雑すぎて、さまざまなレベル、グループ、ロールがあり、管理機能と標準機能の区別が曖昧であることが多く、権限の脆弱性を引き起こします。攻撃者はこれらの弱点を利用して、他のユーザーのリソースや管理機能にアクセスすることができます。
例: オンライン学習プラットフォームは、学生にさまざまなコースを提供しています。プラットフォームの設計上の問題により、学生がURLやAPIエンドポイントを操作して、インストラクター専用の機能にアクセスできます。例えば、学生が /student/dashboard から /instructor/dashboard にURLを変更すると、インストラクターダッシュボードにアクセスでき、コース内容を変更したり、課題を採点したり、コースを追加/削除したりできます。
推奨事項:
- デフォルトですべてのアクセスを拒否し、特定のロールに対して明示的な許可を要求します。APISIXでは、コンシューマまたはコンシューマグループを作成して、ユーザーに異なるアクセス制御を提供できます。次に、JWT認証プラグインを設定して、JWTトークンにロール情報を含めることができます。ユーザーがログインすると、受け取るJWTトークンにはロール（
studentまたはinstructor）が含まれます。APISIXは、特定の機能へのアクセスを許可する前に、JWTトークンからユーザーのロールを検証できます。 - 管理コントローラが、ユーザーロールに基づいて認可チェックを実装するコントローラから継承することを確認します。API7エンタープライズを使用している場合、管理者は特定のユーザー/グループにAPIアクセスを制限し、リクエストごとおよびユーザーごとにアクセスを設定できます。
6. 機密ビジネスフローへの無制限なアクセス
脅威: 機密性の高いビジネスフローが、自動化され過剰に使用された場合にビジネスにどのような損害を与えるかというリスク評価なしに公開されています。
例: 攻撃者は、プロキシと自動化スクリプト（ボット）を組み合わせて、複数の実際のユーザーが購入するのをシミュレートします。スクリプトは迅速に商品をカートに追加し、チェックアウトプロセスを完了させ、実際の顧客が購入する前に在庫を完売させます。攻撃者はその後、これらの商品を他のプラットフォームで高値で転売します。販売プラットフォームは、意図した価格で実際の顧客に商品を販売できないため、潜在的な収益を失います。
推奨事項:
- デバイスフィンガープリントを実装して、予期しないクライアントデバイスへのサービスを拒否します。APISIXはAuth0、AuthgearなどのIDおよびアクセス管理プラットフォームと統合して、デバイス上の生体認証ログイン機能を含むさまざまな認証メカニズムを有効にできます。
- CAPTCHAや高度な生体認証ソリューションなどの人間検出メカニズムを使用します。上記と同じです。
- ユーザーフローを分析して、非人間的なパターンを検出します。API7エンタープライズを使用して、異なるログイン場所間の高速移動やボットの検出など、非人間的なパターンに関連するリクエストに対して追加の認証要素を強制できます。
- 既知の悪意のあるソースのIPアドレスをブロックします。APISIXにはip-restrictionプラグインがあり、単一または複数のIPアドレスからのアクセスをブロックできます。
7. サーバーサイドリクエストフォージェリ (SSRF)
脅威: SSRF攻撃により、攻撃者はサーバーの内部リソースにリクエストを送信し、内部ネットワーク、ファイルシステム、さらにはコマンドの実行にアクセスする可能性があります。これは、APIエンドポイントがURLまたはその一部を入力として受け取り、適切な検証なしにそれを取得する場合に発生します。
例: APIエンドポイントがインターネットから画像を取得するためにURLを受け入れます。悪意のあるユーザーが http://169.254.169.254/latest/meta-data/ （クラウド環境での典型的なメタデータエンドポイント）のようなURLを送信します。サービスは、それが画像であると思ってURLを取得しますが、代わりにIAMロール、シークレットキー、その他の内部設定詳細などの機密データを取得します。攻撃者はその後、この情報を使用して、権限昇格やデータ侵害などのさらなる攻撃を行います。
推奨事項:
- 入力検証 - 常に入力を検証し、サニタイズします。信頼できないソースからの完全なURLを受け入れないようにします。APISIXでは、uri-blockerプラグインを設定して、内部リソースにブロックルールを適用できます。
- ホワイトリスト - 既知で信頼できるドメインまたはIPのみに接続を許可します。APISIXのip-restrictionプラグインを使用するか、referer-restrictionを有効にして、許容可能なドメインまたはURLパターンのホワイトリストを作成します。ホワイトリストに一致しないURLは拒否されます。
- ネットワークセグメンテーション - サーバーがセグメント化され、機密性の高い内部リソースが直接アクセスできないようにします。
8. セキュリティの設定ミス
脅威: これは、APIが安全に設定されていない場合に発生し、機密情報が露出したり、不要な権限が付与されたりする可能性があります。例としては、サーバーの詳細を明らかにするエラーメッセージのログ、不要なHTTPメソッドの有効化、デフォルトの資格情報が変更されていないなどがあります。
例: 簡単な例として、APIが誤って .git ディレクトリを公開し、ソースコードやコミット履歴が露出する場合があります。別の例として、悪意のあるユーザーがプラットフォームを使用中にエラーメッセージに遭遇します。一般的なエラーメッセージではなく、データベース構造、ソフトウェアバージョン、ファイルパスを明らかにする詳細なスタックトレースが表示されます。この情報を使用して、彼はプラットフォームの潜在的な脆弱性を特定します。さらに、そのようなプラットフォームの一般的な設定ミスを調査し、テストアカウントでログインを試みて成功し、管理者アクセスを獲得します。
推奨事項:
- 定期的な監査 - 定期的に設定を確認し、更新します。一般的な設定ミスをスキャンする自動化ツールを使用します。APISIXのロギングプラグインを使用して、すべてのアクセスとシステムアクティビティをログに記録します。繰り返しのログイン失敗や制限されたエンドポイントへのアクセスなどの異常なアクティビティは、レビューのためにフラグを立てることができます。
- 最小権限の原則 - 必要な権限のみを付与し、過度に寛容な設定を避けます。
- デフォルトのセキュリティヘッダー - APISIXは、Content Security Policy (CSP) やHTTP Strict Transport Security (HSTS) などの必須のセキュリティヘッダーを設定して、安全なデフォルトを強制します。これにより、特定のウェブベースの攻撃のリスクが軽減されます。
- エラーマスキング - エラーメッセージが一般的で、機密情報を漏らさないようにします。APISIXは、レスポンス書き換えプラグインまたはカスタムデータマスクプラグインを使用して、詳細なエラーメッセージをマスクするように設定できます。
9. 不適切なインベントリ管理
脅威: 組織が成長するにつれて、特に集中管理がない場合、すべてのAPIを追跡できなくなることがよくあります。これにより、忘れられた、古くなった、または保護されていないAPIが悪用される可能性があります。
例: 複数のバージョンのAPIが監視されずに残されていることがよくあります。攻撃者は、古いAPIバージョンやパッチが適用されていないアクセスポイントを標的にする可能性があります。また、サードパーティ接続の脆弱性を通じて不正アクセスを獲得することもできます。
推奨事項: APISIXのAdmin APIを使用して、不要になったルートを定期的に確認し、非アクティブ化し、すべてのAPIバージョンをクライアントアプリに影響を与えずに追跡します。API7ポータルは、すべてのAPIを監視および管理できる集中管理ダッシュボードを提供します。古いバージョンのAPIがまだ実行されているが、使用されていない場合があります。ダッシュボードを通じて、このAPIを特定し、バックエンドサービス自体にコード変更を加えることなくシャットダウンできます。
10. APIの安全でない消費
脅威: サードパーティAPIや内部APIを統合する際に、安全に行われない場合、アプリケーションが上流APIに存在する脆弱性にさらされる可能性があります。
例: ユーザーが心拍数、睡眠パターン、身体活動などの健康指標を監視できるモバイルアプリケーションを考えてみましょう。このアプリケーションは、これらのサードパーティAPIを消費する際に厳密な検証とセキュリティチェックを行いません。攻撃者は、統合された栄養トラッカーAPIの1つが脆弱であり、悪意のあるデータを返す可能性があることを特定します。アプリケーションがこのAPIから食事プランの提案を取得すると、悪意のあるペイロードを取得して処理し、データ侵害やアプリケーションの誤動作を引き起こす可能性があります。
推奨事項: サードパーティAPIを統合する前に、それが信頼できるソースからのものであり、セキュリティ評価が行われているかどうかを確認します。
- エラーハンドリング - 消費されたAPIからの予期しない応答や動作を、脆弱性を露出させずに処理します。
- データ検証 - サードパーティAPIから受信したデータを常に検証し、サニタイズします。APISIXはWeb Application Firewalls (WAF) と統合して、サードパーティAPIからの着信データを検査およびフィルタリングできます。これにより、既知の悪意のあるパターンやペイロードを検出してブロックできます。また、上流サービスに対してTLS/mTLSを有効化して、内部ネットワークを通過するトラフィックの安全性を保証することも可能です。
まとめ
OWASP API 2023の推奨されるセキュリティガイドラインを適用することは、APIを保護するための基礎的な出発点を提供します。APISIXゲートウェイの機能を使用することで、このプロセスを簡素化し、OWASPが推奨する予防メカニズムの実装コストを大幅に削減できます。