不適切な資産管理

不適切な資産管理とは何か？

各APIについて、そのエンドポイントが本当に必要か、内部通信だけで十分かを検討する必要があります。Wallarmでは、対象のAPIが本番環境で必要か、誰がアクセスすべきかを問い直すことが大切です。また、本番で稼働させる場合、古いバージョンを使っていないか、機密情報が漏れていないか、アプリ内やAPI間でデータがどのように流れているかも確認します。

ドキュメント不足は多くの企業が抱える問題です。流量を発生させない未記録のAPIは、長期間発見されない恐れがあります。

不要な古いAPIの廃止を容易にするため、廃止計画を検討することも一案です。さらに、全APIとそのバージョンを管理するインベントリ管理システムを活用することで、定期的なチェックが可能になります。

これらの古いAPIやライブラリにパッチが当たらない限り、システムは不適切な資産管理のリスクに晒されます。

‍

攻撃シナリオの例

最初の例は、本番環境で確認された事例です。ディレクトリブルートフォーサーでAPIを走査したところ、何も見つからないかと思われましたが、URLからAPIがバージョン2で運用されていることに気付きました。

<http://WEBSITE:5000/api/v2/resources/books/all>

URL中の v2 を v1 に変更し、再度ブルートフォースを実施すると、管理者用のURLが発見されました。

<http://WEBSITE:5000/api/v1/admin>

管理画面は内部ネットワークからのみアクセス可能な設計でしたが、「x-forwarded-from」ヘッダーに 127.0.0.1 を設定するだけで容易に突破されました。

2つ目の例は、サードパーティベンダーで確認されたケースです。新機能の実現には、特定のライブラリが必要でしたが、そのライブラリは古いAPIを利用していました。不十分な資産管理のため、対象システムではこれらAPIの存在が把握されず、結果として管理外のエンドポイントからRCEを含む追加機能が露出しました。

‍

不適切な資産管理への対策は？

Wallarmでは、各APIエンドポイントの特徴、環境、アクセス可能なネットワークなどを含む全APIエンドポイントを管理する適切なインベントリ管理システムの構築が必要です。また、これらAPIに関するサードパーティの連携情報も把握し、必要な関係者が容易に参照できる体制を整えるべきです。

ソフトウェアはますます動的になっているため、インベントリシステムを定期的に見直し評価する必要があります。

記録すべき興味深い事項は以下の通りです：

• エラー
• 認証フロー
• レート制限
• リダイレクト
• CORSポリシーの発動

近年、Open APIなどの仕様採用によりドキュメント自動生成が可能になりました。これにより、不正なAPIの見落としは低減されますが、完全に防げるわけではありません。このドキュメントは利用者が参照できる状態にすべきです。

さらに、APIファイアウォールなどの外部セキュリティ対策を活用することも有効です。これらは本番環境のみならず、テスト環境にも適用する必要があります。特に、パンデミックや在宅勤務の普及に伴い、テスト環境がインターネットに公開されるケースがあるためです。

データを扱う際、本番外の環境で本番データを使用しないことが重要です。やむを得ず使用する場合でも、エンドポイントは本番APIと同様の厳重な基準で管理すべきです。

新たなAPIバージョンがリリースされた際、セキュリティ更新が含まれているなら十分なリスク分析を実施する必要があります。更新が本当に必要であれば速やかに展開し、利用者に影響がなければ安全修正の延期も選択肢となります。

‍

‍

結論

どのAPIがどのバージョンで運用されているかを把握するのは非常に難しいです。攻撃者は放置されたエントリポイントを狙うため、各APIの管理の重要性は計り知れません。本番環境では必要なものだけを有効にするのが賢明です。APIの安全性向上を目指す際は、APIセキュリティソリューションの導入を検討してはいかがでしょうか。