「潜在的に危険なRequest.Form値が検出されました...」というエラーでアプリケーションがクラッシュするのを防ぐため、ページ検証をオフにしました。私はこれを再訪し、正しく解決したい。テキスト入力の自動エンコードの戦略ですか？
これには良い戦略がありますか？人々が '<'と '>'を入力している場合は、データを保存する唯一の方法はJavacriptでエンコードすることだと思います。私はコードビハインドでそれをキャッチしようとしましたが、それは遅すぎます。私はテキストボックスを継承し、クライアントスクリプトで入力を自動エンコード/デコードすることを考えています。私はまた、私のデータベースに既に保存されているすべての山括弧について考える必要があります。
これに関するご提案またはご経験がありますか？
の重複こと。このように：
string = escape(string);
し、サーバー側：そのような
var stringVal = Server.UrlDecode(Request["string"]);
何か。
はJavaScriptを使用してクライアント側でそれを行うには、実際の必要はありません
Server.HtmlEncode(input)
、あなたが使用して検討しています。上記の手法を使用して、サーバー側で簡単に実行できます。
そして、おそらくあなたは、データを投稿する前に危険な文字をエスケープすることができthis質問 /BB
私はあなたのクライアントがあなたに「危険な」コンテンツを送信しないようにするため、ページ検証を有効にしておくことが望ましいですServer.HtmlEncodeを入力してください（1つが欠けている可能性があります）。
jQueryなどのライブラリを使用してフォームのサブミットイベントにフックし、入力する前に入力を整理するなど、javascriptソリューションを利用したいと思います。独自の派生テキストボックスを作成するよりもはるかにクリーンです。
JavaScriptを使用していないユーザー、または小さなスクリプトをハックしようとするユーザーのために、それらのユーザーは最終防衛線に到達し、エラーが発生します。
内蔵のページ検証は、すべての場合に適用可能ではない安全デバイスと考えるのが最善です。それがオンになって何かをすることが全く不可能な時は、何度もあります。このような場合、私たちはそれをオフにし、自分自身の検証に取り組んでいます。
もっとも明白なケースは、実際には、HTMLの大きな断片をサーバーに送信したい場合があることです。もちろん、これを行うにはまだセキュリティを確保する必要がありますが、「ああ、HTMLの大きな塊のように見えますが、セキュリティの例外を投げてください！明らかにそれを行う正しい方法ではありません。
したがって、これらの場合、ページ検証をオフにして、独自のサーバー側を追加することは完全に賢明です。この入力が以前よりも少し精査されて使用される方法について考える必要があることを意味します。 <のような文字が表示されることを期待する場所だけでなく、エスケープされていないクライアントに返信されないようにするか、安全性を保証するために完全に検査されていることを確認してください。
ライフサイクルのどの部分でこれを行うのですか？私がどこで試しても、私は "潜在的に危険なもの"を投げます。私はクライアントサイドがこれを処理する唯一の方法だと感じています（ – TruMan1
）これは、あなたのページ検証をオフにしたときにのみ行うことができます。 @ Bumble Beeは、実際にはオフにしておくことを提案し、Server.HtmlEncodeを使用してユーザーから取得した値をチェックします。 – Gidon
入力をエンコードすることは、私にとって悪いアーキテクチャのように見えます。出力をエンコードする必要があります。いくつかのビューエンジン（Razorのような）はこれを自動的に行います。 – CodesInChaos