漏洩したETagの損傷
WebサーバーからETagが漏洩したことが情報漏洩の脆弱性と見なされていることを何度か読んだことがあります。
たとえば、サーバーの応答ヘッダーでは次のようになります。
ETag: X/"1234-56789"
しかし、これが問題である理由や、これがどのように悪用される可能性があるのか、理由はわかりません。
もちろん、アプリケーションが機能するために必要ではない追加情報は編集する必要がありますが、リークされたETag（したがってiノード）がどのような損害を与える可能性がありますか？
編集： Rapid7など 重大度が4の場合のこれを参照してください。
ETagヘッダーは、クライアントによるサーバー側リソースの効果的なキャッシュに使用されます。サーバーはHTTP応答でETagヘッダーを何らかの文字列に送信し、クライアントは応答コンテンツをキャッシュして、ETagヘッダーで指定された文字列をそれに関連付けます。クライアントが同じリソースに再度アクセスする場合は、HTTPリクエストのIf-None-Matchヘッダー内で指定された文字列を送信し、サーバーはリソースが変更された場合にのみ完全なコンテンツを返し、それ以外の場合はクライアントにキャッシュされたコンテンツを使用できます。詳細は Wikipedia を参照してください。
これは、すべてのクライアントがサーバーからそのようなETagヘッダーを取得できることを意味します。つまり、ヘッダーの値は秘密ではありません。したがって、あなたの質問に反して、そのようなヘッダー自体の漏洩は問題ではありません。
代わりに問題は、ヘッダーの値（つまり文字列）が、秘密にしておくべきサーバーに関する情報を提供する場合です。多くの場合、ヘッダーの値はリソースのコンテンツのハッシュにすぎず、まったく問題ありません。ただし、たとえば、Apache Webサーバーは、ETagをiノード番号、最終変更時刻、ファイルのサイズに基づいて作成できます。これらのメタ情報を使用すると、一意のETagを、コンテンツのハッシュを計算するよりもはるかに速く作成できます。ただし、少なくともiノード番号はサーバーの内部情報と見なされ、クライアントに公開しないでください。攻撃では直接使用できませんが、多くのiノード番号の知識を使用して、たとえば、サーバーに対するさらなる攻撃に役立つ可能性のある基礎となるファイルシステムに関する情報を取得できます。
つまり、inode番号は秘密にしておく必要があるため、ETagヘッダーから抽出できないようにする必要があります。これはApache 1.3.27（かなり前）で修正されました。つまり、ETagの計算にはiノード番号が引き続き使用されますが、ETagの値から抽出することはできません。
編集：たとえばRapid7は、重大度が4の場合のこれを参照してください。
CVSSスコアはいくつかの部分から計算されます。この特定の問題の詳細 ここで見ることができます しかし、基本的には、使用するのは簡単で、ネットワーク経由で実行でき、認証を必要とせず、サーバーに関する内部情報を提供します。