Web アプリケーションセキュリティ

第26章. DoSから身を守る

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

DoS 攻撃は通常、システムリソースの使用を伴うため、堅牢性の高いサーバロギングがなければ、その検知は少々困難である。過去に発生したDoS攻撃が（エンドポイントのような）正当な経路で行われた場合、それを検知するのは難しいかもしれない。

このように、DoSスタイルの攻撃に対する最初の対策は、サーバに十分包括的な ロギングシステムを構築し、すべてのリクエストが応答するまでの時間と一緒に記録されるようにすることである。また、APIを通じて呼び出されるが、バックグラウンドで実行され、完了するとレスポンスを生成しないバックアップのような、非同期の "ジョブ "スタイルの関数のパフォーマンスも手動で記録すべきである。こうすることで、DoS脆弱性（サーバ側）を悪用しようとする試み（偶発的か悪意があるか）を発見することができる。

前述したように、DoS攻撃は以下の結果の1つ以上を念頭に置いて構成されている：

• サーバのリソースを使い果たす

• 顧客のリソースを使い果たす

• 利用できないリソースをリクエストする

最初の2つは、サーバ、クライアントのエコシステムを直接知らなくても悪用しやすい。DoSの脅威を軽減する計画を立てる際には、これら3つの潜在的な脅威をすべて考慮する必要がある。

正規表現DoSから身を守る

Regex DoS 攻撃は、防御するのが最も簡単なDoSの形態であると思われるが、（本書のパートIIで示したように）攻撃がどのような構造になっているかについての予備知識が必要である。 適切なコードレビュープロセスを行うことで、コードベースに正規表現DoSシンク（悪意 ある正規表現）が入り込むのを防ぐことができる。

繰り返されるグループに対して重要なバックトレースを行う正規表現を探す必要がある。これらの正規表現は通常、(a[ab]*)+ に似た形式をとる。+ は、貪欲なマッチ（マッチする可能性のあるものをすべて発見してから返す）を行うことを示唆し、* は、可能な限り何度も部分式にマッチすることを示唆する。

正規表現はこの技術に基づいて構築することができるが、DoSリスクはないため、誤検出なしに悪意のある正規表現のインスタンスをすべて発見するのは時間がかかり、困難な場合がある。正規表現に悪意のあるセグメントがないかスキャンするOSSツールを使うか、正規表現パフォーマンス・テスターを使って入力を手動でチェックすることが大いに役立つケースだ。もしコードベースにこれらの正規表現が入り込むのを阻止できれば、アプリケーションを正規表現によるDoSから安全に守るための第一歩を踏み出したことになる。

第二のステップは、ユーザが提供した正規表現が利用される場所がアプリケーション内にないことを確認することである。ユーザがアップロードした正規表現を許可することは、地雷原を歩き、安全なルートマップを正しく記憶していることを祈るようなものだ。そのようなシステムを維持するためには膨大な座標の労力が必要であり、セキュリティの観点からは一般的に良くない考えである。

また、統合するアプリケーションがユーザが提供する正規表現を利用したり、粗悪な正規表現を利用したりしないようにしたい。

論理DoSから守る

論理的な DoSは、正規表現DoSよりも検出と防止が難しい。正規表現DoSと同じように、論理DoSは、開発者がシステムリソースを消費するために悪用できるロジックのセグメントを誤って導入しない限り、ほとんどの状況で悪用できない。 ...