Webサーバーがあるとします。サーバーの起動時間は、サーバープロセスが開始された時間です。
たとえば、応答の生成中に現在の時刻を取得しないことによるプログラマの不注意により、起動時間は応答ヘッダーを介してリークされていました。プログラマーは、「リスニング」ループに入る前に初期化した時間変数を使用しています。これは、プロセスが開始された時間であるプロセスの存続期間を通して同じままです。
ご存知のように dateフィールドは応答が生成された日付と時刻でなければなりません これは現在の状況ではありません。
この情報は攻撃者にとって有用ですか?どうやって?
はい、これは情報源として価値があるかもしれません。
攻撃者がDoSが機能しているかどうかを確認している場合、サーバーの稼働時間は成功に関するデータを提供できます。または、サーバーが非常に長い間稼働していることを知っている場合は、リソースが不足しているか、パッチが適用されていない可能性があります。
また、負荷に対するインフラストラクチャの応答を把握するためにも使用できます。新しいサーバーを生成するDevOpsシナリオの場合、一意のサーバーのマッピングを開始し、スポーンする可能性のあるサーバーの数(小さなプールの場合)または新しいサーバーをスポーンし始める負荷を推定します。 。
稼働時間は、クラスター内の1つのサーバーを一意に識別するためにも使用できます。
本当の問題は、これは攻撃者にとってどれほどの価値があるかということです。それはあなたの特定の環境に依存します。
「機密情報」という言葉を押し返すかもしれませんが、そうではないと思います。他の表現「有用な情報」は、それ自体には本質的な価値がないため、むしろ使用したいと思いますが、攻撃者が他の目標を追求する際に確実に利用できる二次情報を提供するのに役立ちます。
ユーザーは知る必要がありますサーバーの起動時間ですか?そうでない場合は、非表示にしておくこともできます。それがそのような質問に対する一般的な答えです。
あなたが説明したシナリオは、誤ってそれを明らかにした不注意な開発者です。確かに、それは起こります、大したことではありません。しかし、情報漏えいを知り、それが簡単に修正できる場合は、修正することにします。
攻撃者が起動時間を情報としてのみサーバーをハッキングできる単一の常に存在する脆弱性はありませんが、さまざまなシナリオで役立ちます。
シュローダーが説明したシナリオに加えて、ランダムエンジンに初期化時の現在の時刻をシードするコードを見つけることなく、コードレビューをいくつか行っています。通常、サービスの初期化はサーバーの起動時に行われるため、アップタイムにより、初期化が形成されたおおよその時間がわかります。数年に及ぶ可能性のある起動時間を検索する代わりに、数秒に絞り込むことができます。また、セッショントークン、ワンタイムログイントークン、パスワードリセットトークンなどのセキュリティトークンを生成するためにランダムエンジンをまだ何人使用しているのか知りたくありません(安全でないトークンの生成は実際の脆弱性ですが、起動時間が攻撃を実用的にする)。
シュローダーの優れた答えに加えて、これが明らかなエラーである場合、アプリケーションが不注意にプログラムされたことを攻撃者に示しています。これにより、他の脆弱性を探すためにより多くの時間を投資するようになる可能性があります。