確かに、将来発見される可能性があり、ASP.netのデフォルトの要求検証セキュリティを損なう可能性のあるXSSの脆弱性が常に存在することは誰もが知っています。
ただし、デフォルトでは、validateRequestはtrueです。したがって、最初からhtml値の多くをASP.netテキストボックスやその他の入力に入力することはできません。
したがって、XSSに対する100％の確実なセキュリティではありませんが、間違いなくその大部分をカバーしていますか？
データベースからASP.nethtmlに（.Text = ...を介して）何かを吐き出すたびに、さらにHtmlEncodes（）またはカスタムplainText（）関数を実行する必要があるとは思いません。
データベースからASP.nethtmlに（.Text = ...を介して）何かを吐き出すたびに、さらにHtmlEncodes（）またはカスタムplainText（）関数を実行する必要があるとは思いません。
これには強くお勧めします。
まず、ASP.NET要求の検証は、JavaScriptまたはSQLインジェクションを妨げません。
次に、XSSの脆弱性は、コードのバグが原因で発生することを忘れないでください。たとえば、ユーザー入力を適切にHTMLエンコードまたはJavaScriptエンコードできないコードなどです。要求の検証を有効にし、ASP.NETが悪意のある入力の通過を防ぐという理由だけで、コードからバグを魔法のように削除することはありません。
要求の検証は、ミスをしたときにアプリケーションが悪用されるのを防ぐのに役立つ多層防御手段です。ユーザー入力を常に適切にエンコードするバグのないコードを記述してください。攻撃者がアプリケーションを危険にさらす前に、 2つのフープを飛び越えなければならないので安心できます。
入力フィルタリングは、出力エスケープの問題に対する答えではありません。カジュアルな攻撃者を追い払うことは、せいぜい部分的で信頼性の低い防御です。私の見解では、フレームワークプロバイダーがXSSの問題に対する強固な防御としてそれを提供することは誤った方向に進んでおり、無責任です。
ドロップしたテキストコンテンツをHTML文字列にHTMLエンコードする必要があります。同様に、JS文字列にドロップするテキストコンテンツをJavaScript-string-literal-encodeする必要があります。SQLクエリにドロップするテキストコンテンツはすべてSQLエスケープする必要があります。等々。
これは、作成する出力形式に応じて完全にコンテキストに依存します。出力ターゲット形式がわからない入力レイヤーでは処理できません。
HTTPパラメータ入力以外のソースからコンテンツを取得し、それを出力に含める場合、保護されません。逆に、HTTP入力を使用してHTML以外のものを作成している場合、コンテンツは不必要に破壊されます。さらに、もちろん、完全に有効な入力をブロックしています。SOがリクエスト検証を使用した場合、前述のときに中断されるため、この会話を行うことはできません<script>。
賢明なコーダーは、既存のライブラリ/フレームワークレイヤーを使用して、エスケープ関数を手動で呼び出す必要をなくします。これは、忘れがちなためです。したがって、文字列連結からSQLを作成する代わりに、パラメータ化されたクエリを使用することをお勧めします。HTMLの場合も同じです。適切に設計されたテンプレート言語またはWebコントロールセットを使用すると、HTMLエスケープがデフォルトで発生するため、何もする必要がなくなります。
ASP.NETとWebフォームは、この点で部分的に適切に設計されています。「はい」を設定TextBox.Text=...すると、必要に応じてコンテンツがエスケープされ、それ以上のことは何もできなくなります。一方、設定した場合Literal.Text=...、デフォルトではエンコードされません（これはLiteralModeプロパティで変更できます）。この不一致は非常に残念です。
ほとんどの場合、リクエストの検証を有効にしている場合は保護する必要があります。残念ながら、マークアップを保存する必要がある場合は、最初にマークアップを削除する必要があります。そうしないと、検証によって：がスローされますHttpRequestValidationException。
詳細については、ホワイトペーパーを参照してください。検証の要求-スクリプト攻撃の防止