私はASP.NETスクリプトエクスプロイトについて読んでいましたが、提案の1つは次のとおりです:(
強調は私のものです。提案は、Webページの「スクリプトエクスプロイトに対する保護」セクションの＃3です）
アプリケーションでHTML（たとえば、ユーザーからのフォーマット指示）を受け入れる場合は、サーバーに送信する前に、クライアントでHTMLをエンコードする必要があります。詳細については、「方法：文字列にHTMLエンコーディングを適用してWebアプリケーションのスクリプトエクスプロイトから保護する」を参照してください。
それは本当に悪いアドバイスではありませんか？つまり、悪用者がcurlなどを介してHTMLを送信すると、HTMLはエンコードされずにサーバーに送信されますが、これは適切ではありません（？）
私はここで何かを見逃しているのですか、それともステートメントを誤って解釈していますか？
マイクロソフトの発言は間違っていませんが、完全とはほど遠いものであり、彼らの発言は危険です。
デフォルトではvalidateRequest == trueであるため、クライアントで特別なHTML文字をエンコードして、最初にサーバーに侵入してvalidateRequestをバイパスできるようにする必要があります。
しかし、これは確かにサーバー側のフィルタリングと検証に代わるものではないことを強調する必要がありました。
具体的には、HTML を受け入れる必要がある場合は、ブラック フィルタリングの代わりにホワイト リストを使用することをお勧めします (つまり、特定の HTML タグを許可し、他のすべてを排除します)。強力なユーザー入力フィルタリングのために、 Microsoft AntiXSS ライブラリの使用を強くお勧めします。自分で「車輪を再発明する」よりもはるかに優れています。
そのアドバイスは良くないと思います...
私の経験から、私はあなたの考えに完全に同意し、そのアドバイスを次のように置き換えます。
クライアントが信頼できるデータを送信することを決して信頼しません。あなたが述べたように、データを送信する方法が多すぎます。JavaScript を無効にしている場合、悪意のないユーザーでもクライアントのシステムをバイパスできる可能性があります。
ただし、その項目からのリンクでは、ポイント 3 の意味が明確になります。
次の方法で、スクリプトの悪用から保護することができます。
フォーム変数、クエリ文字列変数、および Cookie 値に対してパラメーター検証を実行します。この検証には、2 種類の検証が含まれている必要があります。変数を予期される型に変換できることの検証 (たとえば、整数への変換、日時への変換など) と、予期される範囲またはフォーマットの検証です。たとえば、整数であることを意図したフォーム ポスト変数は、Int32.TryParse メソッドでチェックして、変数が実際に整数であることを確認する必要があります。さらに、結果の整数をチェックして、値が予想される値の範囲内にあることを確認する必要があります。
値を応答に書き戻すときに、HTML エンコーディングを文字列出力に適用します。これにより、ユーザーが指定した文字列入力が、実行可能なスクリプト コードや解釈された HTML 要素ではなく、ブラウザーで静的テキストとしてレンダリングされるようになります。
HTML エンコーディングは、HTML 予約文字を使用して HTML 要素を変換し、それらが実行されるのではなく表示されるようにします。
クライアントでこのレベルの検証を実行する方法はなく、リンクに含まれる例では、明らかにサーバー側のコードがクライアントに言及せずに提示されているため、これは単なる単語の誤配置だと思います。 編集： デフォルトでリクエストの検証も有効になっていますよね？したがって、Microsoft に関する限り、コンテンツ保護の焦点はサーバーにあることは明らかです。
記事の著者が言い間違えたと思います。リンク先の Web ページにアクセスすると、クライアントに送り返す前のデータのエンコードについて説明されています。その逆ではありません。これは作者による単なる編集ミスだと思います。彼は反対のことを言うつもりでした..クライアントに返される前にエンコードする.