web-dev-qa-db-ja.com

サーバー時間を公開することはセキュリティリスクですか?

サーバー時間を公に返す(認証の必要がない)サーブレットを作成すると、これはセキュリティ上の問題になりますか?私はこれについて何の問題も考えることができませんでしたが、どういうわけか私が間違っている可能性があることを私に知らせます。

さらに説明すると、このエンドポイントは、モバイルアプリでセキュリティを強化するために使用されます(デバイスの日付を調整して不正を回避するため)。

59
Manny

サーバー時間が正確である限り、通常、サーバーの時間は攻撃者にとってほとんど役に立ちません。実際、明らかにされているのは、現在の時間(結局のところ、相対論的物理学を除いて、時間はどこでも一貫しています)ではなく、時間のずれです。時間を明示的に明示していなくても、ローカルサーバーの時間を取得する方法は数多くあることに注意してください。たとえば、バージョン1.2までのTLS 現在の時刻を埋め込む ハンドシェイクで、Webページに動的ページの 最終変更日 が表示され、HTTP応答自体が 現在の日時を含める 応答ヘッダーなど.

サーバーの正確なクロックスキューを知ることは、非常に特定の脅威モデルでのみ問題になります。

  • クロックスキューは、攻撃でTorの隠しサービスを匿名化するために使用できます。

  • 不十分に作成されたアプリケーションは、サーバー時間を使用して秘密の値を生成する場合があります。

  • RTCの環境条件は 不自然な状況 で明らかになる場合があります。

85
forest

「サーブレット」は、すでに複雑なサーバーを実行しているようです。

プロトコルがサーバー時間をリークする方法はたくさんあります。たとえば、HTTPには作成/変更時間の一般的なヘッダーフィールドがあり、動的に生成されたデータは、適切に使用された場合、常に現在のシステム時間になります。

TLS認証の理由から、期限切れのクライアント証明書を使用して、バイナリ検索でエンドポイントの日付と時刻を見つけることもできます。

これは必要な悪です– TLSを実行している場合、サーバーは有効なキー/証明書が何で何がそうでないかを知るための時間の概念を持っている必要があります。その場合は、NTPで調整された時刻である可能性が非常に高くなります。そのため、攻撃者が知らないサーバーについては何も言うことはできません。「正しい」時刻は1つだけです。

TLSを実行していない場合:システム時間のリークは、おそらく修正する必要がある最初のことではありません。

セキュリティに関して:デバイスが世界の時間を把握するためだけに、別のサーブレットを公開する必要があるかどうかはわかりません。

さらに説明すると、このエンドポイントは、モバイルアプリでセキュリティを強化するために使用されます(デバイスの日付を調整して不正を回避するため)。

赤い旗。セキュリティに関しては、クライアントの無修正性に依存しています。絶対にしないでください。ユーザーのデバイスで発生していることは何も信用できません。これらはあなたのデバイスではありません。電話のOSで保持されているか、アプリケーションで保持されているかに関係なく、デバッガーを接続して、プロセスのメモリ内の時間の概念を変更するだけです。

11
Marcus Müller

サーバー時間はsecretではありません。逆に、時間を外部の客観的なタイムソース(タイムサーバーを通じて公開される原子時計など)に同期することを強くお勧めします。

秘密でないことには2つの影響があります。

  1. 保護したり隠したりする必要はありません。攻撃者が現在の時刻を把握できると安全に想定できます。
  2. 保護したり隠したりする機能はありません。たとえば、そのときから鍵や秘密を導き出すべきではありません。使用しているランダム関数には、現在の時刻(多くの場合、まだデフォルトでは遅延)をシードするのではなく、より適切なシードソースをシードする必要があります。
2
Tom

実際にセキュリティリスクを露呈する可能性があるのは、高精度のタイマーとパフォーマンスカウンターだけです。これらは、暗号化プロセスがサーバーでかかる時間を正確に計測し、そこから秘密データを推測するために使用できます。

データをミリ秒または通常の「ティック」レートにタイミング設定すると、これが公開される可能性はほとんどありません。

2
pjc50

私が考えることができる唯一のことは、サーバーの「稼働時間」時間を公開したかどうかです-これは、最後にインストールされたパッチの指標を与える可能性があります。しかし、これは通常は公開されていないと思いますが、チェックしていないため、興味がある場合は確認する価値があります。

1
user195233

サーバーの時刻を知ることは、攻撃者にとってほとんど役に立ちません。だからここであなたは可能な副作用について見つけるべきです。

  • そのサーブレットの保護は他のサーブレットの保護よりも(何らかの方法で)弱いですか? DOS/DDOS攻撃に関して認証の必要なしの考えられる影響は何ですか?認証がより安全な他のサーバーで処理された場合、問題になる可能性があります。リバースプロキシに違いはありますか?
  • そのサーブレットのセキュリティ欠陥のリスクは何ですか?他のサーブレットと同じ品質の保険管理に従っていますか?そのメンテナンスサイクルはどうですか?
  • そのサーブレットコンテナはどうですか?
1
Serge Ballesta

サーバー時間を公開することは実際にはリスクであるという仮定から何が起こるかを指摘することで、それに答えたいと思います。正しいまたはほぼ正しいサーバー時刻は推測しやすいため、正しい時刻に設定されたサーバーは脆弱であるため、システム管理者はシステムにランダムな時刻を設定する必要があることを意味します。また、誤った設定を正しい時間に変換して、時間に関連するすべてのアプリケーションで使用できるようにするという、極端な開発努力も意味します。システム上のすべてのファイルに誤ったタイムスタンプが付けられます。

私の経験では、間違ったサーバー時間を設定すると、正しい設定で予想できるよりもはるかに多くの問題を招きます。一部の例は他の回答で言及されていますが、通常は正しい時刻設定が不可欠である分散アプリケーションまたはクラスターも考慮する必要があります。基本的に、保存する時間関連情報には欠陥があります。

したがって、システム時間を公開することが最大のリスクとなる場合は、運が良かったです。しかし、おそらく十分な注意を払っていない他の多くの懸念があります。セキュリティ関連の問題とベストプラクティスについては、 https://www.owasp.org/index.php/Main_Page を参照してください。

1
Javatasse