同僚と議論していました。いくつかのセキュリティ標準を実装する必要があります。非表示フィールドに「機密情報、住所、生年月日」の情報を保存しないことは承知していますが、通常、アプリケーションで非表示フィールドを使用しても問題ありません。
例えば:
action=goback
クエリ文字列に追加するのではなく、そのような情報には隠しフィールドを使用する方が安全なようです。ハッカーがアプリケーションに対して使用できる情報が 1 つ少なくなります。
同僚と議論していました。いくつかのセキュリティ標準を実装する必要があります。非表示フィールドに「機密情報、住所、生年月日」の情報を保存しないことは承知していますが、通常、アプリケーションで非表示フィールドを使用しても問題ありません。
例えば:
action=goback
クエリ文字列に追加するのではなく、そのような情報には隠しフィールドを使用する方が安全なようです。ハッカーがアプリケーションに対して使用できる情報が 1 つ少なくなります。
ハッカーは、インターセプト プロキシ (または任意の数のツール) を使用して、クエリ文字列の値と同じくらい簡単に隠しフィールドにアクセスできます。
非表示フィールドが機密性の高いものに使用されず、クライアントからの他の値と同じように検証する限り、非表示フィールドを使用しても問題はないと思います。
フィールドを「非表示」にすることは、セキュリティとはほとんど関係がなく、UI の決定と見なす必要があります。とにかく、「ハッカー」は HTML ソースを読み取ります。
機密情報をまったく表示しないか、必要に応じて SSL (ネットワーク仲介者によるデータの傍受を防ぐため) を使用し、ログイン チャレンジをいくつか組み合わせて (不正アクセスを防ぐため) 使用することをお勧めします。
他の方法ではエンド ユーザーが利用できない情報を公開している場合、および/または返されたときにそれを検証していない場合は、セキュリティ ホールにすぎません。
代わりに、上記の情報をサーバー側のセッション変数に保存することを検討します...
非表示フィールドにデータを格納することは、セキュリティの観点から、クエリ文字列にデータを格納することとまったく同じです。実際、フォームで GET アクションを使用すると、いずれにせよクエリ文字列に変換されます。
非表示のフィールドは、セキュリティとはまったく関係ありません。それらは、ユーザーにデータを強制的に表示することなく、データをフォームに格納できる方法にすぎません。ユーザーがそれを見ないようにする方法は提供しません。
非表示のフィールドは常に問題になるわけではありませんが、次の 2 つの潜在的な問題があるため、常に警鐘を鳴らす必要があります。
1)データが機密性の高い場合、クライアントに公開します(たとえば、プロキシを使用するか、単にソースを表示します-これをプログラムで防止しようとするのは無意味です)
2) データがサーバーによって解釈される場合、知識のあるユーザーはデータを変更できます。ばかげた例を挙げると、隠しフィールドにユーザーの銀行残高が含まれている場合、プロキシまたは非標準のクライアントを使用して、サーバーに自分の銀行残高が選択したものであると認識させることができます。
2 つ目は、Web アプリケーションの脆弱性の大きな原因です。セッションに関連付けられたデータは、サーバー上で検証する手段がない限り (たとえば、フィールドがサーバーによって署名または暗号化されている場合)、サーバー側で保持する必要があります。
これらの罠のいずれにも陥っていないことが確実であれば、問題なく使用できます。経験則として、クエリ文字列で喜んで表示されるデータを除いて、または JavaScript が処理のためにそれらを必要とする場合を除いて、非表示フィールドは使用しません。後者の場合でも、サーバーが検証していることを確認する必要がありますが、クライアントが JavaScript を実行すると想定しないでください。
ハッカーは引き続き非表示フィールドを取得して、希望どおりに操作できるため、改ざんチェックの目的で非表示フィールドの名前と値を暗号化することを検討してください。
他の人が言及しているように、クエリ文字列と非表示フィールドの両方は本質的に公開データであり、ユーザーが表示できます。
クエリ文字列にデータを配置する場合に留意すべきことの 1 つは、人々が URL を渡すということです。このため、現在のユーザーに固有の情報を含めることはできません。
状態を直接入力できない場合は、URL に状態情報を含めないこともおそらく良い考えです。または、少なくともクエリ文字列で無効な状態情報を処理する必要があります。
他の投稿者によるその他すべての有用なアドバイスに加えて、隠しフィールドを使用しても、URL クエリ文字列の値と同様に、SQL インジェクション攻撃に対する脆弱性がアプリにあることを付け加えておきます。いつものように、入力をサニタイズします。
通常、機密データには非表示のフォーム フィールドを使用しないでください。「受け取ったとおりに」処理するのが安全ではないことがわかっている静的で機密性の低い POST データに対してのみ。私がそれらを使用するのは、POST の受信時にレンダリングおよびチェックされるセッション トークンを保存するときだけです。CSRF攻撃を防ぐか、少なくともそれらを非常に困難にします。
これは、アイテムをクエリ文字列に配置することよりも多かれ少なかれ安全だと言えます。結局のところ、いつでもサイトでソースを表示できます (いつでもプログラムでソースをダウンロードできるため、それを防ぐ方法はありません)。
ここでのより良い解決策は、フィールドの名前と値を、サーバー上で生成されたキー (サーバーのみ) で暗号化することです。サーバーがハッキングされていない限り、クライアントは値の名前やその値が何であるかを知ることはできません。
もちろん、これはクライアントからのものであるため、戻ってくるデータの有効性を確認する必要があります。自分が指示した以外の方法でデータが変更されていないことを当然と考えてはいけません。
そのためには、値が改ざんされていないことを確認するためにハッシュを使用する必要があります。