Coders Conquer Security OWASP Top 10 APIシリーズ - リソース不足とレート制限

リソース不足とレート制限の欠如によるAPIの脆弱性は、その名の通りです。すべてのAPIは、環境に応じて利用可能なリソースとコンピューティングパワーに制限があります。また、ほとんどのAPIは、ユーザーや他のプログラムからのリクエストに応答して機能を実行するよう求められます。この脆弱性は、短時間に過剰なリクエストが集中し、APIがそれを処理するための十分なコンピューティングリソースを確保できない場合に発生します。その結果、APIが利用不能になったり、新しいリクエストに応答できなくなったりします。

APIのレート制限やリソース制限が適切に設定されていない、あるいはコード内で制限が定義されていない場合、APIはこの問題に対して脆弱になります。例えば、ビジネスが繁忙期を迎えた際にAPIが過負荷状態になる可能性があります。しかし、これはセキュリティ上の脆弱性でもあります。攻撃者が意図的に保護されていないAPIへ大量のリクエストを送りつけ、サービス拒否（DDoS）攻撃を行う可能性があるからです。

ところで、APIのゲーミフィケーション・チャレンジの進み具合はいかがですか？レート制限の脆弱性への対処スキルを今すぐ試してみたい方は、ぜひアリーナへお越しください。

それでは、さらに詳しく見ていきましょう。

APIにおけるリソース不足やレート制限の脆弱性には、どのような例があるのでしょうか？

この脆弱性がAPIに紛れ込む経路は主に2つあります。1つ目は、コーダーがAPIのスロットルレート（制限速度）を定義し忘れるケースです。インフラ側にデフォルト設定が存在する場合もありますが、それに頼るのは賢明な方針ではありません。APIごとに個別にレートを設定すべきです。APIによって機能や利用可能なリソースが大きく異なるため、これは特に重要です。

例えば、少数のユーザーのみを対象とした内部APIであれば、スロットルレートを非常に低く設定しても問題なく動作します。しかし、ライブのeコマースサイトの一部である公開APIの場合、同時アクセス数の急増に備えて、非常に高いレートを設定する必要があるでしょう。いずれの場合も、スロットルレートは予想されるニーズ、潜在的なユーザー数、および利用可能なコンピューティングパワーに基づいて定義されるべきです。

特に非常に忙しくなることが予想されるAPIでは、パフォーマンスを最大化しようとして、レートを無制限に設定したくなるかもしれません。これは、以下のような簡単なコードで実現できてしまいます（例としてPython Django REST frameworkを使用します）。

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

この例では、匿名ユーザーもシステムに登録済みのユーザーも、時間あたりのリクエスト数に関係なく、無制限にAPIへアクセスできてしまいます。これは非常に危険です。APIがどれほど豊富なコンピューティングリソースを持っていても、攻撃者がボットネットなどを使用すれば、最終的にAPIの動作を極端に遅くしたり、完全にダウンさせたりすることが可能だからです。そうなれば、正当なユーザーはアクセスを拒否され、攻撃は成功してしまいます。

リソース不足とレート制限の問題を解消する

組織がデプロイするすべてのAPIは、コード内でスロットルレートを定義する必要があります。これには、実行タイムアウト、許容される最大メモリ量、ユーザーに返される1ページあたりのレコード数、あるいは一定期間内に許可されるプロセス数などが含まれます。

先ほどの例で言えば、スロットルレートを無制限にするのではなく、匿名ユーザーと登録済みユーザーで異なるレートを厳格に定義することができます。

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

この新しい例では、匿名ユーザーは1時間あたり200リクエストまでに制限されます。システムによって認証済みのユーザーには、1時間あたり5,000リクエストという余裕が与えられます。しかし、彼らであっても制限を設けることで、ピーク時の偶発的な過負荷を防いだり、ユーザーアカウントが乗っ取られてサービス拒否攻撃に悪用されたりする事態を回避できます。

最後に、推奨される優れたプラクティスとして、ユーザーがスロットル制限に達した際に通知を表示し、いつ制限が解除されるかを説明することが挙げられます。そうすれば、正当なユーザーはなぜアプリケーションがリクエストを拒否しているのかを理解できます。また、承認されたタスクを実行中の正当なユーザーがアクセスを拒否された場合、運用担当者にスロットル設定の引き上げが必要であることを知らせるシグナルとしても役立ちます。

この脆弱性に関する詳細や、その他のセキュリティ上の欠陥から組織や顧客を守る方法については、Secure Code Warriorのブログをご覧ください。また、デモを試して、Secure Code Warriorのトレーニングプラットフォームでサイバーセキュリティスキルを常に最新の状態に保つことも可能です。