От клиента обнаружено потенциально опасное значение Request.Form

Я думаю, вы атакуете его с неправильной точки зрения, пытаясь закодировать все опубликованные данные.

Обратите внимание, что < также может поступать из других внешних источников, таких как поле базы данных, конфигурация, файл, канал и т. Д.

Кроме того, < по своей сути не опасен. Это опасно только в определенном контексте: при написании строк, которые не были закодированы для вывода HTML (из-за XSS).

В других контекстах опасны разные подстроки, например, если вы записываете предоставленный пользователем URL-адрес в ссылку, подстрока javascript: может быть опасной. С другой стороны, символ одинарной кавычки опасен при интерполяции строк в SQL-запросах, но совершенно безопасен, если он является частью имени, отправленного из формы или прочитанного из поля базы данных.

Суть в том, что вы не можете фильтровать случайный ввод для опасных символов, потому что любой символ может быть опасным при определенных обстоятельствах. Вы должны кодировать в точке, где некоторые конкретные символы могут стать опасными, потому что они переходят в другой подъязык, где имеют особое значение. Когда вы пишете строку в HTML, вы должны кодировать символы, которые имеют особое значение в HTML, используя Server.HtmlEncode. Если вы передаете строку в динамический оператор 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) вы можете добавить _ 1_ свойству в вашей модели.

Это позволяет запросу включать разметку 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 Beta вы можете сделать это:

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

Это по-прежнему проверяет все поля, кроме исключенного. Приятно то, что ваши атрибуты проверки по-прежнему проверяют поле, но вы просто не получаете исключения «Потенциально опасное значение Request.Form было обнаружено от клиента».

Я использовал это для проверки регулярного выражения. Я создал свой собственный атрибут ValidationAttribute, чтобы проверить, допустимо ли регулярное выражение. Поскольку регулярные выражения могут содержать что-то похожее на скрипт, я применил приведенный выше код - регулярное выражение все еще проверяется, действительно ли оно или нет, но не содержит ли оно скрипты или HTML.

В ASP.NET MVC вам необходимо установить requestValidationMode = "2.0" и validateRequest = "false" в web.config и применить атрибут ValidateInput к действию вашего контроллера:

<httpRuntime requestValidationMode="2.0"/>

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

а также

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

Вы можете HTML-кодировать содержимое текстового поля, но, к сожалению, это не остановит исключение. По моему опыту, нет никакого пути, и вам нужно отключить проверку страницы. Поступая так, вы говорите: «Я буду осторожен, обещаю».

Ответ на этот вопрос прост:

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

Это отключит проверку для конкретного запроса.

Вы можете поймать эту ошибку в 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

Для MVC игнорируйте проверку ввода, добавив

[ValidateInput (false)]

над каждым действием в контроллере.

Имейте в виду, что некоторые элементы управления .NET автоматически кодируют выходные данные в формате HTML. Например, установка свойства .Text в элементе управления TextBox автоматически закодирует его. В частности, это означает преобразование < в <, > в > и & в &. Так что будьте осторожны с этим ...

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

Однако свойство .Text для HyperLink, Literal и Label не будет кодировать HTML, поэтому обертывание Server.HtmlEncode (); вокруг чего-либо, установленного в этих свойствах, необходимо, если вы хотите предотвратить вывод <script> window.location = "http://www.google.com"; </script> на вашу страницу и его последующее выполнение.

Поэкспериментируйте, чтобы увидеть, что кодируется, а что нет.

В файле web.config внутри тегов вставьте элемент httpRuntime с атрибутом requestValidationMode = "2.0". Также добавьте атрибут 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;
    }
}

Если вы используете framework 4.0, тогда запись в web.config (‹pages validateRequest =" false "/>)

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

Если вы используете framework 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" %>

если у вас уже есть что-то вроде ‹% @ Page, просто добавьте остальное => 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 вам следует взглянуть на более новый, более полный Библиотека Anti-XSS от команды Microsoft ACE.

Я нашел решение, которое использует JavaScript для кодирования данных, которые декодируются в .NET (и не требуют jQuery).

• Сделайте текстовое поле элементом HTML (например, textarea) вместо элемента ASP.
• Добавьте скрытое поле.
• # P2 # function boo () {targetText = document.getElementById ("HiddenField1"); sourceText = document.getElementById ("ящик пользователя"); targetText.value = escape (sourceText.innerText); }

В текстовое поле включите onchange, который вызывает boo ():

<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, он просто увидит ошибку. Вы также можете сохранить все эти данные в кодировке в базе данных, затем отключить их (на стороне сервера) и проанализировать и проверить на наличие атак перед отображением в другом месте.

Причина

ASP.NET по умолчанию проверяет все элементы управления вводом на предмет потенциально небезопасного содержимого, которое может привести к межсайтовому скриптингу (XSS) и SQL-инъекции. Таким образом, он запрещает такой контент, вызывая указанное выше исключение. По умолчанию рекомендуется разрешить эту проверку при каждой обратной передаче.

Решение

Во многих случаях вам необходимо отправить HTML-контент на свою страницу через Rich TextBoxes или Rich Text Editors. В этом случае вы можете избежать этого исключения, установив для тега ValidateRequest в директиве @Page значение false.

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

Это отключит проверку запросов для страницы, для которой вы установили флаг ValidateRequest в значение false. Если вы хотите отключить это, проверьте все свое веб-приложение; вам нужно будет установить для него значение false в разделе web.config ‹system.web>

<pages validateRequest ="false" />

Для платформ .NET 4.0 или более поздних версий вам также потребуется добавить следующую строку в раздел ‹system.web>, чтобы все вышеперечисленное работало.

<httpRuntime requestValidationMode = "2.0" />

Вот и все. Надеюсь, это поможет вам избавиться от указанной выше проблемы.

Ссылка: Ошибка ASP.Net: от клиента обнаружено потенциально опасное значение Request.Form

Другие решения здесь хороши, однако это немного неудобно применять [AllowHtml] к каждому отдельному свойству Model, особенно если у вас более 100 моделей на сайте приличного размера.

Если, как и я, вы хотите отключить эту (ИМХО, довольно бессмысленную) функцию за пределами сайта, вы можете переопределить метод Execute () в своем базовом контроллере (если у вас еще нет базового контроллера, я предлагаю вам сделать его, они могут быть довольно полезно для применения общих функций).

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

Просто убедитесь, что вы кодируете HTML все, что перекачивается в представления, поступающие из пользовательского ввода (в любом случае это поведение по умолчанию в ASP.NET MVC 3 с Razor, поэтому, если по какой-то странной причине вы не используете 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.NET MVC больше не будет блокировать запрос.

Отключите проверку страницы, если вам действительно нужны специальные символы, такие как, >,, < и т. Д. Затем убедитесь, что при отображении пользовательского ввода данные закодированы в HTML.

В проверке страницы есть уязвимость безопасности, поэтому ее можно обойти. Также не следует полагаться исключительно на проверку страницы.

См .: http://web.archive.org/web/20080913071637/http://www.procheckup.com:80/PDFs/bypassing-dot-NET-ValidateRequest.pdf

Вы также можете использовать функцию JavaScript escape (string) для замены специальных символов. Затем на стороне сервера используйте Server. 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"] должно работать.

Для тех, кто не использует привязку модели, извлекает каждый параметр из Request.Form, кто уверен, что вводимый текст не причинит вреда, есть другой способ. Не лучшее решение, но оно сработает.

Со стороны клиента закодируйте его как uri, а затем отправьте.
например:

encodeURIComponent($("#MsgBody").val());  

Со стороны сервера примите его и расшифруйте как uri.
например:

string temp = !string.IsNullOrEmpty(HttpContext.Current.Request.Form["MsgBody"]) ?
System.Web.HttpUtility.UrlDecode(HttpContext.Current.Request.Form["MsgBody"]) : 
null;  

or

string temp = !string.IsNullOrEmpty(HttpContext.Current.Request.Form["MsgBody"]) ?
System.Uri.UnescapeDataString(HttpContext.Current.Request.Form["MsgBody"]) : 
null; 

пожалуйста, обратите внимание на различия между UrlDecode и UnescapeDataString

Если это только "‹ "и"> "(а не сама двойная кавычка) символы, и вы используете их в контексте, например‹ input value = "this "/›, Вы в безопасности (в то время как для ‹textarea› этого ‹/textarea› вы, конечно, будете уязвимы). Это может упростить вашу ситуацию, но для чего-нибудь используйте одно из других опубликованных решений.