フォームの送信時に返されるキーと値を非表示にする方法はありますか? これらのキー値は、burp スイートなどのセキュリティ テスト ツールを使用してハッカーによって改ざんされる可能性があるためですか?
質問する
2731 次
4 に答える
2
HTTPS は転送中のデータを保護するために使用されますが、ユーザーがマシン上のデータを改ざんするのを防ぐ実用的な方法はありません。最近のほぼすべてのブラウザーには、ユーザーがスクリプトの実行を一時停止したり、クライアント スクリプト変数を変更したり、HTML を変更したりできる組み込みまたはアドオンの開発者ツールがあります。
クライアントからサーバーへの往復で変更されないデータ (UserID など) に使用できる方法の 1 つは、送信前にデータを暗号化し、サーバーに戻ったときに復号化することです。サーバー。別のメカニズムは、変更が予想されないすべてのラウンドトリップ値を取得し、ページの非表示フィールドに格納できるハッシュを計算することです。その後、戻ってきたら、ハッシュを再計算し、すべてが一致することを確認します。次に、"BobLimitedUser" は、ハッシュを壊さずに HTML を操作して、自分のユーザー名を "Administrator" に変更できませんでした。
とはいえ、基本的な事実は、自分の管理下にないシステムからのデータは信頼できないと考えるべきだということです。最終的な入力の検証は、常にサーバー側で実行する必要があります (実行されるクライアント側の検証に加えて)。この「二重検証」要件のため、複雑な検証ルーチンの場合、実際には Web サービス/AJAX 呼び出しを使用してクライアント側の検証を実行します。次に、クライアント スクリプトとサーバー コードは、送信中に 1 回、送信後に 1 回、同じルーチンを呼び出すだけです。
両端ですべての入力を検証するというアプローチを取る場合 (いわば)、改ざんは実際には問題になりません。BobLimitedUser が HTML を操作して、ドロップダウン値をある値からアクセスできる別の値に変更できるようにしたい場合、それは時間を無駄にすることになります。彼がデータの整合性やセキュリティの問題を引き起こす値に何かを変更した場合、それはサーバー側の検証によって保護されます。
要するに
- クライアント スクリプトによって生成されたものは決して信用しないでください。簡単に操作できます (または、古いスクリプトがブラウザにキャッシュされ、古くなり、何かが壊れてしまうことさえあります)。
- クライアント側の検証は、応答性と使いやすさのためのものです。サーバー側の検証は、データの整合性とセキュリティのためのものです
- 機密情報をクライアントに渡さず、元の状態で戻ってくると信頼してください。必要に応じて、暗号化を使用して保護するか、ハッシュを使用して検証します。
- クライアント側のものを暗号化/ハッシュしようとすることさえ気にしないでください
- 転送中にデータを保護するために HTTPS を使用する
- セキュリティ関連のエラーのロギング/アラートを実装します。そうすれば、BobLimitedUser がアプリを悪用しようとしているという警告を毎日受け取る場合、IT セキュリティ部門に連絡して、コンピューターからウイルスを削除するか、適切に対処することができます。
データ検証は議論の大きなトピックであり、OWASP リファレンス ガイドを確認することをお勧めします (ここで複製するには情報が多すぎます): https://www.owasp.org/index.php/Data_Validation
最後にもう 1 つ考えてみましょう... クライアント スクリプト アプリケーションを使用している場合は、AJAX と Web サービスを使用してデータを送信していると思います。作成するクライアント スクリプトに関係なく、悪意のあるユーザーが Fiddler などを単純に使用して、クライアント スクリプトだけでなくブラウザー自体もバイパスし、要求を Web サービスに直接送信するのを防ぐにはどうすればよいでしょうか? セキュリティを確保する唯一の方法は、サーバーですべてを検証することです。
于 2015-10-21T18:37:30.610 に答える
1
これは、悪意のあるユーザーが値を変更するのを防ごうとしていると想定しています。中間者攻撃を防ぎたいだけなら、Richard が提案するように HTTPS を使用してください。
ユーザーが値を投稿できるようにしたいと仮定すると、短い答えはノーです。
ユーザーがこれらの値を変更できないようにする場合は、それらをセッション状態に保存し、ユーザーに返さないでください (または、クライアントとサーバー）。
サーバー側で返されたデータを検証することもできます。つまり、タグを削除するなどです。
基本的に、クライアントが提供するデータは信頼できません。HTTPS は、悪意のあるユーザーがリクエストを傍受し、firstName を「alert(1)」に変更することを阻止しません (たとえば)。
ユーザーが値を指定する必要がある場合は、値が安全であり、サーバー側のコンテンツのルールに一致していることを確認してください。サーバー側で承認などを常に確認し、ユーザーが提供するデータを信頼しないでください。
サーバーに送信される前に悪意のあるユーザーがデータを変更するのを止めることはできませんが、サーバーがデータを使用する前にデータを検証することはできます。
于 2015-10-15T07:43:33.607 に答える
1
Burp Suite をプロキシ サーバーとして使用すると、ユーザーは、それを通過するトラフィック (つまり、Web ブラウザー、つまりクライアントと Web サーバーの間) を操作できます。これは通常、中間者 (MITM) タイプの攻撃アーキテクチャと呼ばれます。
私の提案は、クライアント側で改ざんされないようにしたいデータを暗号化し、サーバーに投稿する前に非表示のフォームフィールドに個別に保存し、サーバー側で復号化して値と比較することです(サーバーに投稿された中間者によって改ざんされた可能性のあるデータ)。
このようにして、安全に保ちたいデータに変更が加えられたかどうかを知ることができます。
PS:ここのほぼすべての回答で述べたように、そのような場合は HTTPS の使用を強くお勧めします。
于 2015-10-23T06:58:53.900 に答える