html - 隠しフィールドの改ざんを検出する方法は?

Question

Web アプリのフォームに、セキュリティ上の理由から改ざんから保護する必要がある隠しフィールドがあります。非表示フィールドの値が変更されたかどうかを検出し、適切に対応できるソリューションを考え出そうとしています (つまり、一般的な「問題が発生しました。もう一度やり直してください」というエラー メッセージが表示されます)。ソリューションは、ブルート フォース攻撃が実行不可能なほど十分に安全でなければなりません。うまくいくと思う基本的な解決策がありますが、私はセキュリティの専門家ではないので、ここで何かが完全に欠けている可能性があります。

私のアイデアは、2 つの非表示の入力をレンダリングすることです。1 つは保護する必要がある値を含む「important_value」という名前の入力で、もう 1 つは一定の長いランダム文字列と連結された重要な値の SHA ハッシュを含む「important_value_hash」という名前の入力です (つまり、同じ文字列は毎回使用します）。フォームが送信されると、サーバーは SHA ハッシュを再計算し、送信された important_value_hash の値と比較します。それらが同じでない場合、重要な値が改ざんされています。

追加の値を SHA の入力文字列 (おそらくユーザーの IP アドレス?) と連結することもできますが、それで本当に何かが得られるかどうかはわかりません。

これは安全ですか？それがどのように壊れているのか、そしてそれを改善するために何ができる/すべきかについての洞察を持っている人はいますか?

ありがとう！

Answer 1

ハッシュをサーバー側に保存することをお勧めします。攻撃者が値を変更し、独自の SHA-1 ハッシュを生成し、ランダムな文字列を追加できると考えられます (ページに繰り返しアクセスすることで、攻撃者はこれを簡単に把握できます)。ハッシュがサーバー側 (おそらくある種のキャッシュ内) にある場合は、ハッシュを再計算してチェックし、値が改ざんされていないことを確認できます。

編集

ランダム文字列（定数ソルト）に関する質問を間違って読みました。しかし、私は元のポイントがまだ立っていると思います。攻撃者は、隠し値に対応するハッシュ値のリストを作成できます。

Answer 2

デジタル署名

おそらくやり過ぎですが、これは、送信メールにデジタル署名して、受信者がその発信元と内容が本物であることを確認できる場合と同じように聞こえます。改ざんの影響を受けやすいフィールドの署名は、秘密鍵を保護し、データと署名を公開鍵で検証する限り、改ざんの恐れがほとんどなく、改ざんの影響を受けやすいフィールドで公開できます。

このスキームには、秘密鍵にアクセスできる非常に保護されたサーバー/プロセスのセットに「署名」を制限できるという気の利いたプロパティもありますが、フォームの送信を処理するには、公開鍵とともに提供されるサーバー/プロセスのより大きなセットを使用します。

非常に機密性の高い「改ざん禁止」フィールドがあり、サーバー上でそのハッシュ署名を維持できない場合は、これが私が検討する方法です。

ほとんどの人がデジタル署名に精通していると思いますが、初心者向けのWikipediaを次に示します。

公開鍵暗号-セキュリティ

...公開鍵暗号の別のタイプのアプリケーションは、デジタル署名スキームのアプリケーションです。デジタル署名スキームは、送信者の認証と否認防止に使用できます。このようなスキームでは、メッセージを送信したいユーザーは、このメッセージのデジタル署名を計算してから、このデジタル署名をメッセージと一緒に目的の受信者に送信します。デジタル署名スキームには、秘密鍵の知識がある場合にのみ署名を計算できるという特性があります。メッセージがユーザーによって署名され、変更されていないことを確認するには、受信者は対応する公開鍵を知っているだけで済みます。場合によっては（RSAなど）、暗号化スキームと多くの類似点があるデジタル署名スキームが存在します。その他の場合（例 DSA）アルゴリズムは暗号化スキームに似ていません。..。

Answer 3

サーバーでセッションを処理できない場合は、秘密鍵を使用してデータを暗号化し、そのHMACを生成することを検討し、結果を非表示フィールドとして送信します。次に、返されるものが送信されたものと一致することを確認できます。これは、他の誰もあなたの秘密鍵を知らないため、他の誰も有効な情報を生成できないためです。ただし、サーバー側で「変更してはならない」データを処理する方がはるかに優れています。

あなたは、十分に決定された誰もがあなた（あなたのフォーム）に彼らが望む情報を含むHTTPリクエストを送ることができることを認識しなければなりません。

Answer 4

ハッシュサーバー側を保存できない/保存できない場合は、確認するためにサーバー側で再生成できる必要があります。

それが価値があるもののために、あなたはまたあなたのハッシュを塩漬けにするべきです。これはあなたが言ったときにあなたが意味したことかもしれません：

一定の長いランダムな文字列と連結されます（つまり、毎回同じ文字列が使用されます）

その値がユーザー/ログイン/セッションごとに異ならない場合、それは実際にはソルト値ではないことを知っておいてください。

Answer 5

あなたがあなたの人生で「一定の長いランダムな文字列」を守る限り、あなたの方法は比較的強力です。

さらに進んで、1回/一意の「一定の長いランダムな文字列」を生成できます。

Answer 6

あなたが説明していることは、カナリアと呼ばれるものに必要な実装の一部に似ており、クロス サイト リクエスト フォージェリ攻撃を軽減するために使用されます。

一般的に言えば、HTML フォーム内の非表示の入力には、HTTP リクエストで返される暗号化された値が含まれています。ブラウザーの Cookie またはセッションに保持されている文字列には同じ暗号化された値が含まれているため、非表示の入力値が復号化され、Cookie/セッション値が復号化されると、暗号化されていない値が互いに比較されます。それらが同一でない場合、HTTP 要求信頼できません。

暗号化された値は、プロパティを含むオブジェクトである可能性があります。たとえば、ASP.NET MVC では、カナリア実装は、認証されたユーザー名のプロパティ、クラスを使用して生成された暗号化された疑似ランダム値RNGCryptoServiceProvider、オブジェクトが作成された DateTime (UTC 形式)、およびオプションのソルト文字列を含むクラスを使用します。 . 次に、オブジェクトは 256 ビット キーを使用して AES 暗号化アルゴリズムを使用して暗号化され、要求が受信されると同じキーで復号化されます。