Coders Conquer Security OWASP Top 10 API Series - Lack of Resources and Rate Limiting
リソースの不足とレートの制限により、APIの脆弱性は、タイトルで説明されていることとほぼ同じように振る舞います。すべてのAPIは、その環境に応じて利用可能なリソースとコンピューティングパワーが制限されています。また、多くのAPIは、ユーザーや他のプログラムからの要求に応じて、必要な機能を実行する必要があります。この脆弱性は、あまりにも多くのリクエストが同時に来て、APIがそれらのリクエストを処理するための十分なコンピューティングリソースを持っていない場合に発生します。その結果、APIは新たな要求に対応できなくなり、利用できなくなります。
APIは、レートやリソースの制限が正しく設定されていなかったり、コード内で制限が定義されていなかったりすると、この問題の影響を受けやすくなります。例えば、ビジネスが特に忙しい時期になると、APIが過負荷になる可能性があります。しかし、これはセキュリティ上の脆弱性でもあります。なぜなら、脅威となるアクターは、サービス拒否（DDoS）攻撃を行うために、保護されていないAPIに意図的にリクエストを過負荷にすることができるからです。
ところで、これまでのAPIゲーミフィケーションのチャレンジはいかがでしたか？もしあなたが、今すぐレート制限のある脆弱性を扱うスキルを試したいなら、アリーナに足を踏み入れてください。
さて、もう少し踏み込んでみましょう。
リソースの不足やレートの制限によるAPIの脆弱性の例を教えてください。
この脆弱性がAPIに潜り込む方法は2つあります。1つ目は、コーダーがAPIのスロットルレートを単純に定義していない場合です。インフラのどこかにスロットルレートのデフォルト設定があるかもしれませんが、それに頼るのは良いポリシーとは言えません。そうではなく、それぞれのAPIに個別にレートを設定する必要があります。特に、APIは機能や利用可能なリソースが大きく異なる場合があるからです。
例えば、数人のユーザーにしかサービスを提供しないように設計された内部APIであれば、非常に低いスロットルレートでも問題なく動作します。しかし、ライブの E コマースサイトの一部である一般向けの API では、同時ユーザー数の急増の可能性を補うために、特別に高いレートを定義する必要があるでしょう。いずれの場合も、予想されるニーズ、潜在的なユーザー数、利用可能なコンピューティングパワーに基づいて、スロットルレートを定義する必要がある。
特にトラフィックの多い API では、パフォーマンスを最大化するために、レートを無制限に設定したくなるかもしれません。これは、簡単なコードで実現できます（例として、Python Django REST フレームワークを使用します）。
"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リクエストと、より大きな余裕が与えられます。しかし、これらの制限は、ピーク時の偶発的な過負荷を防ぐためや、ユーザーアカウントが漏洩してサービス妨害攻撃に使用された場合の補償のためのものである。
最後に考慮すべきグッドプラクティスとして、ユーザーがスロットリングの限界に達したときには、その限界がいつリセットされるかについての説明とともに、ユーザーに通知を表示することをお勧めします。これにより、有効なユーザーは、アプリケーションがリクエストを拒否する理由を知ることができます。また、承認されたタスクを実行している有効なユーザーがAPIへのアクセスを拒否された場合にも、スロットリングを増加させる必要があることをオペレーション担当者に知らせることができるため、この方法は役に立つ。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
マティアス・マドゥ博士
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
セキュアコーディングに関する最新の知見をブログでご紹介しています。
当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。
開発者主導のセキュリティに関する最新の研究成果を入手する
ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。
Coders Conquer Security OWASP Top 10 API Series - Lack of Resources and Rate Limiting
リソースの不足とレートの制限により、APIの脆弱性は、タイトルで説明されていることとほぼ同じように振る舞います。すべてのAPIは、その環境に応じて利用可能なリソースとコンピューティングパワーが制限されています。また、多くのAPIは、ユーザーや他のプログラムからの要求に応じて、必要な機能を実行する必要があります。この脆弱性は、あまりにも多くのリクエストが同時に来て、APIがそれらのリクエストを処理するための十分なコンピューティングリソースを持っていない場合に発生します。その結果、APIは新たな要求に対応できなくなり、利用できなくなります。
APIは、レートやリソースの制限が正しく設定されていなかったり、コード内で制限が定義されていなかったりすると、この問題の影響を受けやすくなります。例えば、ビジネスが特に忙しい時期になると、APIが過負荷になる可能性があります。しかし、これはセキュリティ上の脆弱性でもあります。なぜなら、脅威となるアクターは、サービス拒否（DDoS）攻撃を行うために、保護されていないAPIに意図的にリクエストを過負荷にすることができるからです。
ところで、これまでのAPIゲーミフィケーションのチャレンジはいかがでしたか？もしあなたが、今すぐレート制限のある脆弱性を扱うスキルを試したいなら、アリーナに足を踏み入れてください。
さて、もう少し踏み込んでみましょう。
リソースの不足やレートの制限によるAPIの脆弱性の例を教えてください。
この脆弱性がAPIに潜り込む方法は2つあります。1つ目は、コーダーがAPIのスロットルレートを単純に定義していない場合です。インフラのどこかにスロットルレートのデフォルト設定があるかもしれませんが、それに頼るのは良いポリシーとは言えません。そうではなく、それぞれのAPIに個別にレートを設定する必要があります。特に、APIは機能や利用可能なリソースが大きく異なる場合があるからです。
例えば、数人のユーザーにしかサービスを提供しないように設計された内部APIであれば、非常に低いスロットルレートでも問題なく動作します。しかし、ライブの E コマースサイトの一部である一般向けの API では、同時ユーザー数の急増の可能性を補うために、特別に高いレートを定義する必要があるでしょう。いずれの場合も、予想されるニーズ、潜在的なユーザー数、利用可能なコンピューティングパワーに基づいて、スロットルレートを定義する必要がある。
特にトラフィックの多い API では、パフォーマンスを最大化するために、レートを無制限に設定したくなるかもしれません。これは、簡単なコードで実現できます（例として、Python Django REST フレームワークを使用します）。
"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リクエストと、より大きな余裕が与えられます。しかし、これらの制限は、ピーク時の偶発的な過負荷を防ぐためや、ユーザーアカウントが漏洩してサービス妨害攻撃に使用された場合の補償のためのものである。
最後に考慮すべきグッドプラクティスとして、ユーザーがスロットリングの限界に達したときには、その限界がいつリセットされるかについての説明とともに、ユーザーに通知を表示することをお勧めします。これにより、有効なユーザーは、アプリケーションがリクエストを拒否する理由を知ることができます。また、承認されたタスクを実行している有効なユーザーがAPIへのアクセスを拒否された場合にも、スロットリングを増加させる必要があることをオペレーション担当者に知らせることができるため、この方法は役に立つ。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
