API（アプリケーションプログラミングインターフェース）は、ソフトウェアプログラム間の通信を可能にするゲートウェイとして普及しています。異なるシステム間で情報をやり取りするデジタルブリッジのように機能します。APIは、アプリ間の通信と連携を可能にすることで、現代のソフトウェアにおいて極めて重要な役割を果たしています。APIセキュリティは、こうしたデータ接続を不正アクセスや攻撃から保護します。優れたAPIセキュリティフレームワークは、機密データを保護し、悪意のあるリクエストをブロックし、APIへのアクセス権限を持つ者だけが利用できるようにします。企業が主要サービスをオンラインに移行する中、この保護が今日さらに重要であることは明らかです。本ブログでは、APIセキュリティリスクの具体的な内容を解説します。
基本的なセキュリティ概念、攻撃者が用いる一般的な脅威、そしてこれらの攻撃を防ぐ方法について議論します。
APIセキュリティとは？
APIセキュリティとは、組織のAPIとそのデータを様々なセキュリティ脅威から保護するために、様々な方法や手段を用いるプロセスを指します。これには、APIへのアクセス権限を持つ者の特定、システム間を移動するデータの保護、APIへのリクエストの安全性の確保が含まれます。
APIセキュリティが不可欠な理由とは？
APIセキュリティは、機密性の高いユーザー情報と組織のシステムを保護します。APIが安全である限り、攻撃者がデータを盗んだりシステムにアクセスしたりすることはできません。APIが安全に機能している場合、ビジネスへの信頼は損なわれません。多くのコンプライアンス基準も、APIの安全性を要求しており、これを満たさない組織は罰金を科せられます。
APIは、金銭、ユーザー、企業秘密を扱うビジネスシステムを接続します。APIのセキュリティが不十分だと、攻撃者が侵入してこのデータを奪う可能性があります。組織は金銭的損失を被り、顧客の信頼を失い、法的問題を引き起こします。API攻撃は年々増加しており、これらのエンドポイントを保護することがますます重要になっています。
14のAPIセキュリティリスクと対策
APIは日々数多くのセキュリティ脅威に晒されています。そのリスクはコードの基本的なバグからより巧妙な攻撃まで様々です。これらの脅威を理解することで、セキュリティチームは適切な防御策を容易に構築できます。最も一般的なAPIセキュリティ脆弱性と対策例を見ていきましょう。
1.アクセス制御の不備
アクセス制御の不備により、ユーザーは本来アクセス権限のないリソースを読み取ったり変更したりすることが可能になります。最も単純な例として、攻撃者がURL内のIDを改変し、他のユーザーのデータを取得することが挙げられます。これは、ログイン中のユーザーが要求されたデータを閲覧または更新する権限を持っているかどうかをAPIが検証しない場合に発生します。一部のAPIでは、攻撃者はアクセスチェックを全く受けずに自身のロールを昇格させたり設定を変更したりできます。
アクセス制御の不備を修正するには、組織はまずすべてのAPIリクエストでユーザーロールを確認すべきです。誰がどのデータを見るべきかを定義し、データセットの所有者を参照して表示が適切であることを確認します。正確なユーザー権限に整合したトークンを使用し、一貫したセキュリティ監査を実施してアクセス制御の問題を発見します。
2.認証の不備
APIがユーザーIDを十分に検証しない場合、アプリケーションは認証の不備に直面します。弱いパスワードや期限切れのない古いログイントークンは、APIでは許容される場合があります。認証が適切に機能しない場合、攻撃者は弱いパスワードを総当たり攻撃で破り、既存の認証メカニズムを迂回してユーザーデータを漏洩させることが可能です。
組織は、認証を強化するために強力なパスワードポリシーと重要な操作前の二段階認証を導入すべきです。また、一定時間後に失効するログイントークンを導入し、パスワード入力失敗が繰り返された場合にユーザーをロックアウトする必要があります。さらに、すべてのAPIリクエストでログイントークンを検証し、攻撃を示唆する可能性のある異常なログインパターンを監視すべきです。
3.データ漏洩
データ漏洩とは、組織のAPIが必要以上のデータを返す状態を指します。これにはデータベースフィールド、デバッグデータ、エラーメッセージ内のシステム詳細などが含まれます。特定のフィールドのみが要求された場合、レスポンスオブジェクトで期待された内容ではなく、完全なデータオブジェクトが返されることで問題が発生します。攻撃者はこの追加情報を偵察やさらなる攻撃に利用します。
機密データの漏洩を防ぐため、組織は各APIが返すべき内容のスキーマを作成すべきです。レスポンスは不要な詳細を削除し、エラーメッセージにはシステム情報を含めないようにします。ログやレスポンスから機密情報をスクランブルする処理を実装してください。
4.リソース制限
リソース制限問題は、APIがユーザーから過剰なリクエストを受ける際に発生します。攻撃者はこれを悪用し、サーバーに偽のリクエストを送信します。特定のAPIでは、単一呼び出しで大規模なペイロードを要求することも可能です。これによりシステムリソースが消費され、正規ユーザー向けのサービスが遅延または停止する可能性があります。
組織はリソース管理のため、ユーザーまたはIPベースのリクエスト上限を設定すべきです。過剰な呼び出しを行うURLに対しては、リクエストの実行に大幅な遅延を実装し、ブラックリスト登録を実施します。異常な特性を持つ攻撃型リクエストパターンに警戒してください。
5. インジェクション攻撃
追加検証なしにユーザー入力を信頼するAPIは、インジェクション攻撃を招きます。クライアント側では、攻撃者が登録フォームなどの標準的なペイロードに特殊コマンドを隠して送信します。このようなコマンド/ペイロードにより、データベースから機密情報が漏洩したり、システムコマンドが実行されたり、保存データが改ざんされたりする可能性があります。これは開発者がユーザー入力に対する入力サニタイズや検証を実装していない場合に発生します。
組織は、インジェクション攻撃を防ぐため、入力データが使用される前にすべてを検証するチェックを実装すべきです。「<」や「>」などの特殊文字をブロックして悪意のあるペイロードを防止します。データベースとの通信には安全な方法を使用します。入力サイズに制限を設け、各 API で許可される入力タイプのリストを維持します。
6.不適切な資産管理
開発チームが新機能や新バージョンを継続的にデプロイするため、APIは急速に進化します。これにより、下位互換性のために古いバージョンが稼働したまま、複数のAPIバージョンが同時に実行されることがよくあります。
開発チームはテスト用APIを本番環境にデプロイすることがあり、追加のセキュリティリスクを生み出します。こうした忘れられた、未使用の、あるいはテスト用の API は、しばしば「シャドー API」や「ゾンビ API」と呼ばれ、通常、時代遅れのコードを含み、最新のセキュリティ対策が欠けています。既知の脆弱性と時代遅れのセキュリティ対策により、抵抗が最も少ない経路を求める攻撃者にとって格好の標的となります。
組織の API をより適切に管理する 1 つの方法は、API インベントリを使用することです。これにより、API のすべてのバージョンとそれらが実行される場所を記録できます。新しいバージョンの API が機能し始めたら、古いバージョンを廃止してください。API がテスト用である場合は、テストサーバー上に残してください。すべてのAPIエンドポイントを頻繁にスキャンし、セキュリティ上の問題を検出します。ネットワーク内の隠れたAPI、シャドーAPI、ゾンビAPIを特定するツールを活用しましょう。
7. マスアサインメント
マスアサインメントの脆弱性は、APIがクライアントから提供されたデータを適切なフィルタリングなしに内部オブジェクトやデータベースレコードに自動的にバインドする際に発生します。APIが更新用のデータオブジェクトを受け入れる際、ユーザー変更を意図しない機密フィールドを含む、一致する全フィールドを無条件に更新する可能性があります。攻撃者は制限されたフィールドをリクエストに追加することでこれを悪用し、権限昇格や重要なシステム値の改ざんを引き起こす恐れがあります。
マスアサインメントを防ぐには、組織は各APIが更新可能なフィールドをリスト化すべきです。リストにないフィールドをブロックする実装を行ってください。一般ユーザー向けと管理者レベルのアクション用APIを分離する。各フィールド更新をユーザー権限で検証する。リクエストに追加フィールドを含めてAPIをテストするか、ファジングツールを導入して問題を捕捉する。
8.クロスオリジンリソース共有
クロスオリジンリソース共有（CORS）ルールは、組織のAPIにアクセスできるウェブサイトを規制します。簡単に言えば、CORS設定が脆弱だと、あらゆるサイトがそのAPIを呼び出せる状態になります。開発中は、CORSはすべてのオリジンを許可するように設定されます。しかし、多くの場合、組織は後でこれを変更することを忘れてしまいます。
CORSの問題を克服するには、組織のAPIを利用できるウェブサイトに関する特定のルールを実装する必要があります。本番環境のAPIに「allow-all」設定を絶対に設定しないでください。APIを有効にする方法に関するCORSルールを検証してください。
9.エンドポイント保護の欠如
API のエンドポイント間でセキュリティ制御に一貫性がない場合、不十分な エンドポイント保護 が発生します。組織は主要なエンドポイントに対して堅牢なセキュリティチェックを実施しているかもしれませんが、深くネストされたエンドポイントや可視性の低いエンドポイントでは、同レベルの保護が欠如している可能性があります。攻撃者は、確立されたセキュリティ制御を迂回し、不正アクセスを得るために、セキュリティカバレッジのギャップを積極的に探します。
組織は、可視性やネットワーク上の場所に関係なく、すべての API エンドポイントに一貫したセキュリティ制御を実装する必要があります。認証、認可、入力検証など、すべてのエンドポイントに同じセキュリティ基準を適用してください。ステージング環境やテスト環境などの内部ネットワーク上のエンドポイントも含め、すべてのエンドポイントを定期的にスキャンし、セキュリティカバレッジの均一性を確保する必要があります。
10. 不適切なエラー処理
エラーが適切に処理されない場合、攻撃者にデータベースの詳細、サーバーのパス、エラーダンプなどが露呈する可能性があります。また、エラー処理の不備はセキュリティチェックの機能を阻害することもあります。攻撃者はエラーメッセージを悪用し、APIに関する知見を得て、さらに悪用を進めます。
組織は、システムの詳細を隠蔽する標準的なエラーメッセージを定義し、エラー処理を改善すべきです。ログファイルとユーザーの両方に全く同じエラーを送信しないでください。エラーが発生した場合でも、セキュリティチェックは継続して機能する必要があります。攻撃の兆候を確認するため、組織は定期的にエラーログをチェックすべきである。
11. セキュリティ設定の不備
APIの設定がデフォルトのまま（例：パスワードがadmin123）の場合、セキュリティ設定の不備が発生する。多くのAPIはテスト用パスワード、開放ポート、その他の基本的なセキュリティルールで運用を開始する。論理的問題を解決するため、組織はセキュリティ機能を無効化し、再有効化を忘れる場合があります。一方、デフォルト設定は権限を必要以上に寛容にし、システムを問題化し得る不要な機能を追加する傾向があります。
組織はセキュリティ設定を適切に設定し、すべてのデフォルトパスワードとアクセスルールを変更すべきです。ユーザーが不要なAPI機能は無効化してください。APIの各部分について、その要件に応じてセキュリティルールを設定してください。問題を特定するために、APIの設定を定期的に見直してください。不正確または欠落したセキュリティ設定を検出するセキュリティスキャンツールを使用してください。
12. 安全でない依存関係
APIの開発では、時間とリソースを節約するために多くのサードパーティ製コードパッケージが使用されます。これらのパッケージにはセキュリティ上の問題が既知の場合が多いです。APIが内部で安全でないパッケージを使用している場合、攻撃者は既知の問題を悪用して不正アクセスを得ることが可能です。
依存関係を保護するため、組織は使用前にすべてのパッケージのセキュリティ問題を検証すべきです。新しいセキュリティ対策がリリースされたら、直ちにパッケージの更新をインストールしてください。組織は、安全でないパッケージについて警告を発するオープンソースの依存関係スキャンツール（SCAツール）を使用すべきです。
13. 適切なロギングの欠如
不十分なAPIログ記録はセキュリティ上の死角を生み出し、潜在的な脅威を内包する可能性があり、インシデント発生時の組織の対応能力を損なう恐れがあります。不十分なログ管理（例：アクセス不可能な場所にログを保存する、ログの完全性を保護できない）は、攻撃者が自身の痕跡を消去したり、機密情報を漏洩させたりする手助けとなる可能性があります。
強固なロギング慣行を確立するには、組織はすべてのAPI呼び出しを詳細に記録すべきです。これにはリクエストヘッダーやIPアドレス、使用された認証方法、レスポンスコードなどの情報が含まれます。これには、ログの保存に中央の安全な場所を使用し、各ログへのアクセス権を制御することが含まれます。
14. 脆弱な暗号化
API が脆弱な暗号化を使用している場合、攻撃者は機密データを読み取ったり変更したりできる可能性があります。一部の組織では、脆弱性を含む旧式の暗号化方式を採用したAPIが存在します。また、単純なデータを平文で送信するケースも見られます。強固な暗号化であっても、設定ミスによって弱体化される可能性があります。攻撃者は間違いなく、API暗号化の脆弱な点を狙って機密データにアクセスします。
APIと処理する機密データを保護するには、AESなどの強力な暗号化に依存すべきです。個人データを転送または保存する際は暗号化を実施し、セキュリティガイドを参照して新セキュリティパッチのリリース時に暗号化を適切に設定・更新してください。
FAQs
APIに対する3つの一般的な脅威は、アクセス制御の不備、認証の不備、およびインジェクション攻撃です。アクセス制御の問題により、ユーザーが機密データを閲覧できてしまいます。認証の脆弱性により、攻撃者は認証メカニズムを迂回できます。また、インジェクション攻撃では、悪意のあるペイロードが送信され、任意のコードの実行、データベースの読み取り/更新/削除など、さまざまな悪影響をもたらします。
認証の欠陥とは、APIが使用する認証メカニズムが何らかの形で誤設定されている状態を指します。これには、期限切れの古いログイントークンの使用、脆弱なパスワード、レスポンス本文に依存したユーザーログイン（レスポンス操作攻撃）などが含まれます。こうした問題により、ハッカーは認証を迂回して機密情報にアクセスすることが可能になります。
入力検証は周知のセキュリティベストプラクティスですが、API実装時には頻繁に無視されます。入力検証は、ユーザーからAPIに送信される全データを分析し、悪意のあるデータでないことを保証します。こうしたチェックがない場合、攻撃者は一見正常に見えるリクエストに悪意のあるペイロードを隠して含め、SQLインジェクションやクロスサイトスクリプティングなどのインジェクション攻撃を実行できます。
APIの脆弱な暗号化は、攻撃者がクライアントとサーバー間でやり取りされる機密データを傍受・復号することを可能にします。これにより、パスワードや支払い情報、その他の機密情報の窃取が可能となります。
ログ記録と監視は、異常なパターン、潜在的な侵害、不審な活動をリアルタイムで追跡することで、セキュリティ脅威の検出と対応を支援します。インシデント調査のための監査証跡を提供し、組織が自社のAPIがどのように使用または悪用されているかを理解するのに役立ちます。
セキュリティツールには、APIスキャナーやWebファイアウォール、前述のSentinelOneのような専門プラットフォームなどが含まれます。これらのツールを組み合わせることで、問題の特定、不要なトラフィックのフィルタリング、様々なセキュリティ攻撃に対するAPIの保護が可能になります。