ウェブアプリケーションセキュリティ 第2版

第32章. DoSから身を守る

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

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

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

第14章で論じたように、DoS攻撃は以下の結果の1つ以上を念頭に置いて構成されている：

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

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

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

• リソースへのアクセスを拒否する

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

正規表現DoSから身を守る

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

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

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

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

論理DoSから守る

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