web-dev-qa-db-ja.com

攻撃者を阻止するための動的なランダム化プロトコル

定期的に変更されるプロトコルを想像してみてください。
これらのフィールドの順序が大幅に変更された場合はどうなりますか？
プロトコルが

{ Payload, Checksum, Length, Flags, ID }

次の時点になる

{ Flags, Checksum, Payload, ID, Flags }

設定された期間の後、プロトコルは再び変更されます。

攻撃者としての目標は、標的を悪用したり、穴を見つけたりすることが標的について何であるかを知ることです。定期的に変更する場合、攻撃者が弱点を悪用する方法を知るのが難しくなる可能性があります。また、基礎となるコード、フィールド、フィールド長、エンコード/変調方式、およびその他のものを変更することができます。
もちろん、クライアント/サーバーはこれらの変更と同期している必要があります。これは隠すことによるセキュリティのように聞こえますが、攻撃者を遅らせる可能性があります。以前に行われたことがありますか？そうでない場合、それは役に立つと思われますか？

attacksprotocolsdefense
1
dopobop

定期的に変更する場合、攻撃者が弱点を悪用する方法を知るのが難しくなる可能性があります。 ...基になるコード...もちろん、クライアント/サーバーはこれらの変更と同期している必要があります。

ご存知のとおり、クライアントとサーバーは同期している必要があります。これは、両側で何らかの状態を保持する必要があるか、サーバーがクライアントメッセージから状態を抽出できる必要があるが、クライアントが独自の状態を発明できないようにする必要があることを意味します。これらの要件を詳しく見ると、対称暗号化（つまり、状態が暗号化キーに関連している）または認証（セッションCookieに似た状態）のいずれかの典型的な形式がすでにあります。どちらも確立された単純な手法であるため、より複雑で実際には優れた保護を提供しない新しい手法を発明するのはなぜですか。

  • 状態のようなセッションCookieを使用すると、残りのデータを解釈する前に、まずクライアントが認証されているかどうかを確認します。認証に失敗するととにかく無視されるので、残りのフォーマットを変更する必要はありません。
  • 暗号化を使用すると、最初にデータを復号化する必要があります。復号化が失敗した場合、ペイロードは無視されるため、形式を変更する必要はありません。

最後に、セキュリティは、攻撃者が共通の状態をどれだけ推測できるかにのみ依存します。この状態が暗号化キー、セッションCookie、または形式の変更を説明するアルゴリズムであるかどうかは関係ありません。後者は、他の2つのソリューションよりも実装が複雑です。

1
Steffen Ullrich

これは、TCP自体を見ているように見えますが、パーサーは、帯域外の状況で何らかの方法でレイアウトを決定する必要があります。通信スタックに組み込み、に基づいてローテーションすることができます。事前に共有された秘密ですが、最終的には発見されるでしょう。おそらく6か月の期間ですか？

また、データの規則性により、バイト境界がどこにあるかを把握し、スキームを把握することが容易になります。

0
Munchen