リソース不足とレート制限

‍リソース不足とレート制限とは何か?

APIがリクエストを受けるたび、応答が必要です。この応答を作成するには、CPU、RAM、ネットワーク、場合によってはディスクスペースなどのリソースが必要ですが、必要量は処理内容により大きく異なります。処理が複雑であったり、返すデータ量が多かったりすると、1回の呼び出しで消費するリソースが増え、あっという間に積み重なります。もしレート制限をAPIエンドポイントに適用しなければ、この問題はさらに深刻になります。さらに、多くのAPIが共有ホスト上に存在するため、全てが同じリソースを争い、攻撃者がリソースを使い果たすことで、無関係な別のAPIが利用不能になる恐れもあります。こうした問題を回避することは、APIセキュリティ企業にとっても有益です。

攻撃シナリオの例

レート制限がかかっていないエンドポイントに関連する単純な攻撃例は存在します。一例として、レート制限があるファイル作成用エンドポイントと、レート制限のないファイルコピー用エンドポイントを発見するユーザによる攻撃が考えられます。初めは悪用が難しいように思えますが、システム上に大きなファイルを作成してからそのコピーを行うと、サーバのリソースが枯渇する可能性がございます。

例:

POST /createDocument.php
[
    {
        "Name": "677",
        "Content": "AAAAA...AAAA",
        "fileSize":"21343243242343kb"
    }
]

次のようなIDが返されます:

id=12

この呼び出しを何度も実行すると、エンドポイントにレート制限がかかっていることが分かります。

GET /cloneDocument.php?id=12

しかし、レート制限が適用されていないGET呼び出しが存在する場合、それを繰り返すことでサーバ全体のリソースが使い果たされる恐れがあります。

さらに別の例を示します。例えば、次のURLでブログの最新100件の投稿を取得しようとする場合です。

GET /api/v1/posts?limit=100

このリクエストをlimit=99999というパラメータで実行すると、リソース不足が引き起こされ、これもまたエンドポイントのレート制限不足に該当します。

レート制限不足に対する予防策

• dockerコンテナの利用は非常に便利です。-mなどの内蔵フラグにより、各コンテナが使用できるメモリ量を正確に指定できます。また、異なるAPIの分離も容易になります。
• クライアントが一定期間内に実行できるリクエスト回数を制限する必要があります。ただし、レート制限に達した、または達しそうな際には、クライアントにその旨を通知できるようにする必要があります。この通知には、残りのリクエスト回数やレート制限の残り時間が含まれるべきです。
• クライアント側およびサーバ側で、リクエストボディやレスポンスのサイズが大きすぎないか確認する必要があります。特に、クライアントが指定した件数のレコードを返すエンドポイントでは重要です。クライアントが一度に過剰なレコードを要求すると、重大な問題を引き起こす恐れがあります。
• エンドポイントが受け付ける各データ型には上限を設けるべきです。例えば、整数の場合は5999に制限するなど、大量のデータ露出を防ぎます。

‍

結論

見落とされがちなこの脆弱性は把握しにくいですが、各APIエンドポイントの入力や出力の最大サイズ制限をチェックすることで、自動検出が可能です。ただし、各APIが何を受け入れ、何を返すべきかを十分に理解している必要があります。加えて、充実したドキュメントがあれば問題の特定が容易になり、長期的なコスト削減につながります。Wallarmの記事「OWASP Top-10 2021と2017の脆弱性の比較」をご参照ください。