潜在的に危険なRequest.Form値がクライアントから検出されました

ユーザーがWebアプリケーションのページを含む、<または>ページに何かを投稿するたびに、この例外がスローされます。

誰かがテキストボックスに文字を入力したため、例外をスローしたり、Webアプリケーション全体をクラッシュしたりすることの賢さについては説明しませんが、これを処理するためのエレガントな方法を探しています。

例外をトラップして表示する

エラーが発生しました。戻ってフォーム全体をもう一度入力してください。ただし、今回は使用しないでください

私には専門家のようには思えません。

事後検証（validateRequest="false"）を無効にすると、このエラーは確実に回避されますが、ページは多くの攻撃に対して脆弱になります。

理想的には、HTML制限付き文字を含むポストバックが発生すると、Formコレクション内のそのポストされた値は自動的にHTMLエンコードされます。したがって、.Text私のテキストボックスのプロパティはsomething & lt; html & gt;

ハンドラーからこれを行う方法はありますか？

投稿されたすべてのデータをエンコードしようとして、間違った角度から攻撃していると思います。

「<」は、データベースフィールド、構成、ファイル、フィードなど、他の外部ソースからも来る可能性があることに注意してください。

さらに、「<」は本質的に危険ではありません。これは特定のコンテキストでのみ危険です。HTML出力にエンコードされていない文字列を書き込むとき（XSSのため）。

他のコンテキストでは、異なるサブストリングは危険です。たとえば、ユーザーが指定したURLをリンクに書き込むと、サブストリング "javascript: "が危険になる可能性があります。一方、単一引用符文字は、SQLクエリで文字列を補間する場合は危険ですが、フォームから送信された名前またはデータベースフィールドから読み取られた名前の一部である場合は完全に安全です。

肝心なのは、危険な文字のランダム入力をフィルタリングすることはできないということです。適切な状況下では、どの文字も危険な場合があるからです。特定の文字が特別な意味を持つ別のサブ言語に交差するために危険になる可能性があるポイントでエンコードする必要があります。文字列をHTMLに書き込むときは、Server.HtmlEncodeを使用して、HTMLで特別な意味を持つ文字をエンコードする必要があります。文字列を動的SQLステートメントに渡す場合は、さまざまな文字をエンコードする必要があります（または、準備されたステートメントなどを使用してフレームワークにエンコードさせることをお勧めします）。

ときあなたは必ずHTMLエンコードあなたがHTMLに文字列を渡している、どこでも、その後、セットvalidateRequest="false"で<%@ Page ... %>お使いに指示.aspxファイル（複数可）。

.NET 4では、もう少し行う必要がある場合があります。場合によっては<httpRuntime requestValidationMode="2.0" />、web.config にも追加する必要があります（参照）。

ASP.NET MVCを使用している場合、このエラーには別の解決策があります。

• ASP.NET MVC –ページvalidateRequest = falseが機能しませんか？
• ValidateInput（False）が機能しないのはなぜですか？
• ASP.NET MVC RC1、VALIDATEINPUT、潜在的な危険な要求およびピットフォール

C＃サンプル：

[HttpPost, ValidateInput(false)]
public ActionResult Edit(FormCollection collection)
{
    // ...
}

Visual Basicサンプル：

<AcceptVerbs(HttpVerbs.Post), ValidateInput(False)> _
Function Edit(ByVal collection As FormCollection) As ActionResult
    ...
End Function

ASP.NET MVC（バージョン3以降）では、 AllowHtml、モデルのプロパティに属性をます。

プロパティのリクエスト検証をスキップすることで、モデルバインディング中にリクエストにHTMLマークアップを含めることができます。

[AllowHtml]
public string Description { get; set; }

.NET 4.0を使用している場合は、これをタグ内のweb.configファイルに追加してください<system.web>。

<httpRuntime requestValidationMode="2.0" />

.NET 2.0では、リクエストの検証はリクエストにのみ適用されましたaspx。.NET 4.0では、これはすべてのリクエストを含むように拡張されました。以下を指定することにより、処理時にXSS検証のみを実行するように戻すことができます.aspx。

requestValidationMode="2.0"

以下を指定することで、リクエストの検証を完全に無効にすることができます。

validateRequest="false"

ASP.NET 4.0の場合、<location>要素全体にマークアップを配置することで、サイト全体ではなく特定のページの入力としてマークアップを許可できます。これにより、他のすべてのページが安全になります。ValidateRequest="false".aspxページに配置する必要はありません。

<configuration>
...
  <location path="MyFolder/.aspx">
    <system.web>
      <pages validateRequest="false" />
      <httpRuntime requestValidationMode="2.0" />
    </system.web>
  </location>
...
</configuration>

どのページがマークアップを入力として許可するかをサイトレベルで確認できるため、web.config内でこれを制御する方が安全です。

リクエストの検証が無効になっているページでは、プログラムで入力を検証する必要があります。

以前の答えは素晴らしいですが、HTML / JavaScriptインジェクションの検証から単一のフィールドを除外する方法については誰も述べていません。私は以前のバージョンについて知りませんが、MVC3ベータではこれを行うことができます：

[HttpPost, ValidateInput(true, Exclude = "YourFieldName")]
public virtual ActionResult Edit(int id, FormCollection collection)
{
    ...
}

これにより、除外されたフィールドを除くすべてのフィールドが検証されます。これの良い点は、検証属性がまだフィールドを検証しているにもかかわらず、「潜在的に危険なRequest.Form値がクライアントから検出された」という例外が発生しないことです。

私はこれを正規表現の検証に使用しました。正規表現が有効かどうかを確認するために、独自のValidationAttributeを作成しました。正規表現にはスクリプトのようなものが含まれる可能性があるため、上記のコードを適用しました。正規表現が有効かどうかはまだチェックされていますが、スクリプトやHTMLが含まれている場合はチェックされていません。

ASP.NET MVCでは、web.configでrequestValidationMode = "2.0"およびvalidateRequest = "false"を設定し、ValidateInput属性をコントローラーアクションに適用する必要があります。

<httpRuntime requestValidationMode="2.0"/>

<configuration>
    <system.web>
        <pages validateRequest="false" />
    </system.web>
</configuration>

そして

[Post, ValidateInput(false)]
public ActionResult Edit(string message) {
    ...
}

テキストボックスのコンテンツをHTMLエンコードできますが、残念ながら例外は発生しません。私の経験では回避策はなく、ページの検証を無効にする必要があります。そうすることによって、あなたは言っている：「私は注意します、私は約束します」。

MVCの場合、追加して入力検証を無視します

[ValidateInput（false）]

コントローラの各アクションの上。

Global.asaxでそのエラーをキャッチできます。検証したいのですが、適切なメッセージを表示します。下記のブログでは、このようなサンプルが公開されていました。

    void Application_Error(object sender, EventArgs e)
    {
        Exception ex = Server.GetLastError();

        if (ex is HttpRequestValidationException)
        {
            Response.Clear();
            Response.StatusCode = 200;
            Response.Write(@"[html]");
            Response.End();
        }
    }

別のページにリダイレクトすることも、例外に対する妥当な応答のようです。

http://www.romsteady.net/blog/2007/06/how-to-catch-httprequestvalidationexcep.html

この質問への答えは簡単です：

var varname = Request.Unvalidated["parameter_name"];

これにより、特定のリクエストの検証が無効になります。

一部の.NETコントロールは自動的に出力をHTMLエンコードすることに注意してください。たとえば、TextBoxコントロールで.Textプロパティを設定すると、自動的にエンコードされます。それは、具体的には変換手段<に<、>内>と&に&。これを行う場合は注意してください...

myTextBox.Text = Server.HtmlEncode(myStringFromDatabase); // Pseudo code

ただし、HyperLink、Literal、Labelの.TextプロパティはHTMLエンコードしないため、Server.HtmlEncode（）;をラップします。これらのプロパティに設定されているものは、<script> window.location = "http://www.google.com"; </script>ページに出力されてから実行されないようにする場合に必須です。

少し実験して、何がエンコードされ、何がエンコードされないかを確認します。

web.configファイルのタグ内に、requestValidationMode = "2.0"属性を持つhttpRuntime要素を挿入します。また、pages要素にvalidateRequest = "false"属性を追加します。

例：

<configuration>
  <system.web>
   <httpRuntime requestValidationMode="2.0" />
  </system.web>
  <pages validateRequest="false">
  </pages>
</configuration>

ValidateRequestを無効にしたくない場合は、例外を回避するためにJavaScript関数を実装する必要があります。これは最良のオプションではありませんが、機能します。

function AlphanumericValidation(evt)
{
    var charCode = (evt.charCode) ? evt.charCode : ((evt.keyCode) ? evt.keyCode :
        ((evt.which) ? evt.which : 0));

    // User type Enter key
    if (charCode == 13)
    {
        // Do something, set controls focus or do anything
        return false;
    }

    // User can not type non alphanumeric characters
    if ( (charCode <  48)                     ||
         (charCode > 122)                     ||
         ((charCode > 57) && (charCode < 65)) ||
         ((charCode > 90) && (charCode < 97))
       )
    {
        // Show a message or do something
        return false;
    }
}

次に、コードビハインドのPageLoadイベントで、次のコードを使用してコントロールに属性を追加します。

Me.TextBox1.Attributes.Add("OnKeyPress", "return AlphanumericValidation(event);")

まだ誰も以下に言及していないようですが、それで問題が解決しました。そして、誰もがそう言う前に、それはVisual Basicだ...残念。

<%@ Page Language="vb" AutoEventWireup="false" CodeBehind="Example.aspx.vb" Inherits="Example.Example" **ValidateRequest="false"** %>

何か欠点があるかどうかはわかりませんが、私にとってはこれはすばらしく機能しました。

別の解決策は：

protected void Application_Start()
{
    ...
    RequestValidator.Current = new MyRequestValidator();
}

public class MyRequestValidator: RequestValidator
{
    protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex)
    {
        bool result = base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);

        if (!result)
        {
            // Write your validation here
            if (requestValidationSource == RequestValidationSource.Form ||
                requestValidationSource == RequestValidationSource.QueryString)

                return true; // Suppress error message
        }
        return result;
    }
}

フレームワーク4.0を使用している場合は、web.configのエントリ（<pages validateRequest = "false" />）

<configuration>
    <system.web>
        <pages validateRequest="false" />
    </system.web>
</configuration>

フレームワーク4.5を使用している場合は、web.configのエントリ（requestValidationMode = "2.0"）

<system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="2.0"/>
</system.web>

単一のページだけが必要な場合は、aspxファイルで、最初の行を次のように配置する必要があります。

<%@ Page EnableEventValidation="false" %>

<％@ページのようなものがすでにある場合は、残りを追加してください=> EnableEventValidation="false"％>

しないことをお勧めします。

ASP.NETでは、例外をキャッチして、わかりやすいメッセージの表示や別のページへのリダイレクトなど、何かを行うことができます...また、検証を自分で処理できる可能性もあります...

フレンドリーなメッセージを表示：

protected override void OnError(EventArgs e)
{
    base.OnError(e);
    var ex = Server.GetLastError().GetBaseException();
    if (ex is System.Web.HttpRequestValidationException)
    {
        Response.Clear();
        Response.Write("Invalid characters."); //  Response.Write(HttpUtility.HtmlEncode(ex.Message));
        Response.StatusCode = 200;
        Response.End();
    }
}

モジュールでそれを行うことができると思います。しかし、それはいくつかの質問を開いたままにします。入力をデータベースに保存する場合はどうでしょうか？突然、エンコードされたデータをデータベースに保存するため、データベースからの入力を信頼することになりますが、これはおそらく悪い考えです。理想的には、未エンコードの生データをデータベースに保存し、毎回エンコードします。

ページレベルで保護を無効にしてから、毎回エンコードすることをお勧めします。

Server.HtmlEncodeを使用するのではなく、Microsoft ACEチームからのより新しく、より完全なAnti-XSSライブラリを確認する必要があります。

原因

ASP.NETはデフォルトで、クロスサイトスクリプティング（XSS）およびSQLインジェクションにつながる可能性のある安全でない可能性のあるコンテンツのすべての入力コントロールを検証します。したがって、上記の例外をスローすることにより、そのようなコンテンツを拒否します。デフォルトでは、このチェックを各ポストバックで実行できるようにすることをお勧めします。

解決

多くの場合、リッチテキストボックスまたはリッチテキストエディタを使用して、HTMLコンテンツをページに送信する必要があります。その場合、@PageディレクティブのValidateRequestタグをfalseに設定することで、この例外を回避できます。

<%@ Page Language="C#" AutoEventWireup="true" ValidateRequest = "false" %>

これにより、ValidateRequestフラグをfalseに設定したページのリクエストの検証が無効になります。これを無効にする場合は、Webアプリケーション全体を確認してください。web.config <system.web>セクションでfalseに設定する必要があります

<pages validateRequest ="false" />

.NET 4.0以降のフレームワークの場合、上記の作業を行うには、<system.web>セクションに次の行も追加する必要があります。

<httpRuntime requestValidationMode = "2.0" />

それでおしまい。これがあなたが上記の問題を取り除くのに役立つことを願っています。

参照：ASP.Netエラー：潜在的に危険なRequest.Form値がクライアントから検出されました

JavaScriptを使用してデータをエンコードするソリューションを見つけました。これは.NETでデコードされます（jQueryを必要としません）。

• テキストボックスをASP要素ではなくHTML要素（textareaなど）にします。
• 非表示フィールドを追加します。

• 次のJavaScript関数をヘッダーに追加します。

  function boo（）{ta​​rgetText = document.getElementById（ "HiddenField1"）; sourceText = document.getElementById（ "userbox"）; targetText.value = escape（sourceText.innerText）; }

テキストエリアに、boo（）を呼び出すonchangeを含めます。

<textarea id="userbox"  onchange="boo();"></textarea>

最後に、.NETでは、

string val = Server.UrlDecode(HiddenField1.Value);

私はこれが一方向であることを認識しています-双方向が必要な場合はクリエイティブになる必要がありますが、これはweb.configを編集できない場合の解決策を提供します

以下は、私（MC9000）が思いついてjQueryを介して使用する例です。

$(document).ready(function () {

    $("#txtHTML").change(function () {
        var currentText = $("#txtHTML").text();
        currentText = escape(currentText); // Escapes the HTML including quotations, etc
        $("#hidHTML").val(currentText); // Set the hidden field
    });

    // Intercept the postback
    $("#btnMyPostbackButton").click(function () {
        $("#txtHTML").val(""); // Clear the textarea before POSTing
                               // If you don't clear it, it will give you
                               // the error due to the HTML in the textarea.
        return true; // Post back
    });


});

そしてマークアップ：

<asp:HiddenField ID="hidHTML" runat="server" />
<textarea id="txtHTML"></textarea>
<asp:Button ID="btnMyPostbackButton" runat="server" Text="Post Form" />

これはうまくいきます。ハッカーがJavaScriptをバイパスして投稿しようとすると、エラーが表示されるだけです。エンコードされたこのすべてのデータをデータベースに保存し、それを（サーバー側で）エスケープ解除し、他の場所に表示する前に解析して攻撃をチェックすることができます。

ここでの他の解決策は素晴らしいですが、特に適切なサイズのサイトに100を超えるモデルがある場合は、[AllowHtml]をすべてのモデルプロパティに適用する必要があるので、後悔します。

私のように、この（IMHOはかなり無意味な）機能をサイト全体でオフにしたい場合は、ベースコントローラのExecute（）メソッドをオーバーライドできます（ベースコントローラがまだない場合は、ベースコントローラを作成することをお勧めします。共通の機能を適用するのに非常に便利です）。

    protected override void Execute(RequestContext requestContext)
    {
        // Disable requestion validation (security) across the whole site
        ValidateRequest = false;
        base.Execute(requestContext);
    }

ユーザー入力から得られたビューに送り出されるすべてをHTMLエンコードしていることを確認してください（とにかく、Razorを使用したASP.NET MVC 3のデフォルトの動作です。奇妙な理由がない限り、Html.Raw（）を使用します）この機能は必要ありません。

私もこのエラーを受け取りました。

私の場合、ユーザーはáロール名にアクセント付き文字を入力しました（ASP.NETメンバーシッププロバイダーに関して）。

ユーザーにそのロールを付与するメソッドにロール名を渡し、$.ajax投稿リクエストが無残に失敗しました...

私は問題を解決するためにこれをしました：

の代わりに

data: { roleName: '@Model.RoleName', users: users }

これを行う

data: { roleName: '@Html.Raw(@Model.RoleName)', users: users }

@Html.Raw トリックをしました。

ロール名をHTML値として取得していましたroleName="Cadastro bás"。このHTMLエンティティの値はá、ASP.NET MVCによってブロックされていました。これで、roleNameパラメーター値が適切な方法で取得されroleName="Cadastro Básico"ます。ASP.NETMVCエンジンが要求をブロックしなくなります。

あなたは本当に、などの特殊文字が必要な場合は、ページの検証を無効にする>、<などは、ユーザー入力が表示されたときに、データはHTMLエンコードであることを確認してください。

ページ検証にセキュリティ上の脆弱性があるため、バイパスされる可能性があります。また、ページの検証だけに依存するべきではありません。

参照：http : //web.archive.org/web/20080913071637/http : //www.procheckup.com : 80/PDFs/bypassing-dot-NET-ValidateRequest.pdf

JavaScriptのescape（string）関数を使用して、特殊文字を置き換えることもできます。次に、サーバー側でサーバーを使用します。URLDecode（string）に戻します。

これにより、入力検証をオフにする必要がなくなり、文字列にHTMLコンテンツが含まれる可能性があることが他のプログラマーに明らかになります。

各ポストバックの前にJavaScriptを使用して、次のような不要な文字をチェックしてしまいました。

<asp:Button runat="server" ID="saveButton" Text="Save" CssClass="saveButton" OnClientClick="return checkFields()" />

function checkFields() {
    var tbs = new Array();
    tbs = document.getElementsByTagName("input");
    var isValid = true;
    for (i=0; i<tbs.length; i++) {
        if (tbs(i).type == 'text') {
            if (tbs(i).value.indexOf('<') != -1 || tbs(i).value.indexOf('>') != -1) {
                alert('<> symbols not allowed.');
                isValid = false;
            }
        }
    }
    return isValid;
}

私のページはほとんどがデータ入力であり、ポストバックを行う要素はほとんどありませんが、少なくともそれらのデータは保持されます。

あなたは次のようなものを使うことができます：

var nvc = Request.Unvalidated().Form;

後で、nvc["yourKey"]うまくいくはずです。

この限りであるとしてのみ「<」と「>」（とない二重引用符自体が）文字とは、<入力値=「のような文脈でそれらを使用しているこの」/>、あなたしている安全な（しばらくの間、<TEXTAREA > この1つ </ textarea>もちろん脆弱です）。それはあなたの状況を単純化するかもしれませんが、もっと何かのために他の投稿された解決策の1つを使用してください。

<と>を使用しないことをユーザーに伝えるだけの場合は、フォーム全体を処理/ポストバックしたくない（そしてすべての入力を失う）必要はありません。それらの（そしておそらく他の潜在的に危険な）文字をスクリーニングするフィールドの周りのバリデーター？

どの提案も私にとってはうまくいきませんでした。ユーザーがWebフォームにHTMLを配置することを99％の時間で望まないため、どうしてもこの機能をWebサイト全体でオフにしたくありませんでした。このアプリケーションを使用しているのは私だけなので、自分でメソッドを作成しました。コードビハインドで入力をHTMLに変換し、データベースに挿入します。