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


1471

Каждый раз, когда пользователь публикует что-либо, содержащее <или >находящееся на странице в моем веб-приложении, я получаю это исключение.

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

Отслеживание исключения и отображение

Произошла ошибка. Вернитесь и введите заново всю форму, но на этот раз не используйте <

не кажется достаточно профессиональным для меня.

Отключение post validation ( validateRequest="false") определенно позволит избежать этой ошибки, но сделает страницу уязвимой для ряда атак.

В идеале: когда происходит обратная запись, содержащая ограниченные символы HTML, это опубликованное значение в коллекции Form будет автоматически кодироваться в формате HTML. Таким образом, .Textсвойство моего текстового поля будетsomething & lt; html & gt;

Есть ли способ, которым я могу сделать это из обработчика?


68
Обратите внимание, что вы можете получить эту ошибку, если у вас также есть имена сущностей HTML (& amp;) или номера сущностей (& # 39;).
Дрю Ноакс

18
Ну, так как это мой вопрос, я чувствую, что могу определить, в чем суть: срывать весь процесс приложения и возвращать общее сообщение об ошибке, потому что кто-то набрал '<', это излишне. Тем более, что вы знаете, что большинство людей просто «validateRequest = false», чтобы избавиться от него, тем самым вновь открывая уязвимость
Radu094

7
@DrewNoakes: имена объектов (& amp;), по-моему, не являются проблемой в соответствии с моими тестами (протестированными в .Net 4.0), хотя номера объектов (& # 39;) не проходят проверку (как вы сказали). Если вы разберете метод System.Web.CrossSiteScriptingValidation.IsDangerousString с помощью .Net Reflector, вы увидите, что код специально ищет html-теги (начиная с <) и номера сущностей (начиная с & #)
Gyum Fox

5
Создайте новый сайт в VS2014, используя проект MVC по умолчанию, и запустите его. Нажмите на ссылку регистрации, добавьте любое электронное письмо и используйте «<P455-0r [!» как пароль. Та же ошибка из коробки, не пытаясь сделать что-либо вредоносное, поле пароля не будет отображаться, поэтому это не будет атака XSS, но единственный способ исправить это - полностью удалить проверку с помощью ValidateInput (false) ? Предложение AllowHtml не работает в этой ситуации, но все равно взорвалось с той же ошибкой. От клиента было обнаружено потенциально опасное значение Request.Form (Пароль = "<P455-0r [!").
Стивенбайер

TL; DR положил <httpRuntime requestValidationMode="2.0" />в web.config

Ответы:


1081

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

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

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

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

Суть в том, что вы не можете отфильтровать случайный ввод для опасных символов, потому что любой символ может быть опасным при правильных обстоятельствах. Вы должны кодировать в точке, где некоторые конкретные символы могут стать опасными, потому что они переходят на другой язык, где они имеют особое значение. Когда вы пишете строку в HTML, вы должны кодировать символы, которые имеют особое значение в HTML, используя Server.HtmlEncode. Если вы передаете строку в динамический оператор SQL, вы должны кодировать разные символы (или, лучше, позвольте платформе сделать это за вас, используя подготовленные операторы или тому подобное) ..

Когда вы уверены, что HTML-кодирование везде, вы передаете строки в HTML, а затем установите validateRequest="false"в <%@ Page ... %>директиве в ваших .aspxфайлах.

В .NET 4 вам может потребоваться сделать немного больше. Иногда необходимо также добавить <httpRuntime requestValidationMode="2.0" />в web.config ( ссылка ).


74
Для тех, кто приходит поздно: validateRequest = "false" входит в директиву Page (первая строка вашего файла .aspx)
MGOwen

56
Совет: вставьте <httpRuntime requestValidationMode="2.0" />тег местоположения, чтобы избежать потери полезной защиты, обеспечиваемой проверкой с остальной части вашего сайта.
Брайан

299
В MVC3 это находится [AllowHtml]на свойстве модели.
Джереми Холовач

2
Для того, чтобы отключить его глобально для MVC 3 также необходимо GlobalFilters.Filters.Add(new ValidateInputAttribute(false));в Application_Start().
Алекс

15
@MGOwen вы также можете добавить директиву страницы в web.config через <pages validateRequest="false" />in <system.web />. При этом свойство будет применено ко всем страницам.
Оливер-Клэр

504

Существует другое решение этой ошибки, если вы используете ASP.NET MVC:

Образец 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

проблема может возникнуть, когда это необходимо на одной странице всего приложения

3
Вы также можете добавить атрибут [ValidateInput (false)] на уровне класса. Если вы добавите его в базовый класс контроллера, он будет применяться ко всем действиям метода контроллера.
Шан Плурд

@ Zack Спасибо за решение. С другой стороны, мне интересно, если [AllowHtml]это лучше, чем ValidateInput(false), потому что [AllowHtml]определяется сразу для свойства, то есть поля редактора, и всякий раз, когда оно используется, нет необходимости использовать его для нескольких действий. Что ты предлагаешь?
Джек,

@ Зак Петерсон Безопасно ли использовать? Нет проблем с безопасностью?
Шрей Пав

417

В ASP.NET MVC (начиная с версии 3) вы можете добавить AllowHtmlатрибут к свойству модели.

Это позволяет запросу включать разметку HTML во время привязки модели, пропуская проверку запроса для свойства.

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

12
Гораздо лучше сделать это декларативно, чем в контроллере!
Andiih

29
Единственно правильный ответ! Отключение проверки действия контроллера является хакерским. И для отключения проверки на уровне приложения, разработчики должны быть повешены!
trailmax

Это исчезло в MVC 4?
granadaCoder

1
В чем разница между ValidateInput(false)и AllowHtml? В чем преимущество одного над другим? Когда бы я хотел использовать AllowHtmlвместо ValidateInput(false)? Когда бы я хотел использовать ValidateInput(false)более AllowHtml? Когда бы я хотел использовать оба? Имеет ли смысл использовать оба?
Ян Бойд

3
ValidateInput используется для метода, AllowHtml - для свойства модели, поэтому вы разрешаете использовать только тот, который, как вы ожидаете, html - не все
Энтони Джонстон,

213

Если вы используете .NET 4.0, убедитесь, что вы добавили это в свой файл web.config внутри <system.web>тегов:

<httpRuntime requestValidationMode="2.0" />

В .NET 2.0 проверка aspxзапросов применяется только к запросам. В .NET 4.0 это было расширено, чтобы включить все запросы. Вы можете вернуться к выполнению только проверки XSS при обработке .aspx, указав:

requestValidationMode="2.0"

Вы можете отключить запрос Validate полностью , указав:

validateRequest="false"

30
Внутри <system.web>тегов.
Хосам Али

8
Я поместил это в файл web.config, но все еще с ошибкой «Потенциально опасное значение Request.Form»
Filip

20
Похоже, <httpRuntime requestValidationMode = "2.0" /> работает только тогда, когда на машине установлена ​​платформа 2.0. Что если 2.0 framework вообще не установлен, а установлен только 4.0?
Самуил

Это полностью сработало для меня. Ни один из шагов в других ответах не был необходим (включая validateRequest = "false")!
Том Редферн

112

В 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, потому что на уровне сайта вы можете видеть, какие страницы допускают разметку в качестве входных данных.

Вам все еще нужно программно проверять ввод на страницах, где проверка запроса отключена.


Более подробная информация о requestValidationMode = 2 | 4 здесь: msdn.microsoft.com/en-us/library/…
GlennG

К сожалению, это не будет работать с ASP.net 2.0 как есть. Удалите строку httpRuntime, и она будет работать.
Fandango68

Я добавил предупреждение, напоминающее людям о необходимости вручную проверять ввод, когда проверка отключена.
Картер Медлин

72

Предыдущие ответы были хорошими, но никто не сказал, как исключить проверку одного поля для инъекций HTML / JavaScript. Я не знаю о предыдущих версиях, но в MVC3 Beta вы можете сделать это:

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

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

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


10
К сожалению, похоже, что функция исключения была удалена из MVC 3 RTW :(
Мэтт Грир,

2
Также он не был включен в MVC 4
wilsjd

9
Используйте [AllowHtml]свойства модели вместо [ValidateInput]действия для достижения того же конечного результата.
Mrchief

2
@Christof Обратите внимание, что мой ответ 5 лет. Я давно не сталкивался с этой проблемой, так что, возможно, есть гораздо лучшие способы ее решения. Что касается этих двух вариантов, я думаю, что это зависит от вашей ситуации. Возможно, вы выставляете эту модель более чем одним действием, а в некоторых местах HTML разрешен или нет. В таком случае [AllowHtml]не вариант. Я рекомендую проверить эту статью: weblogs.asp.net/imranbaloch/… , но она тоже несколько устарела и может быть устаревшей.
глигоран

1
Есть еще способ исключить определенные параметры метода из проверки, посмотрите мой ответ здесь: stackoverflow.com/a/50796666/56621
Alex

51

В 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) {
    ...
}

2
Для меня validateRequest="false"не было необходимости, толькоrequestValidationMode="2.0"
Том Редферн

requestValidationMode = "2.0" по-прежнему генерирует ошибку с HTML-кодированными данными. Никакого решения, кроме как все кодировать в base64, а затем отправить его вместе.
MC9000

48

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


43

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

[ValidateInput (ложь)]

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


Похоже, это не работает в том случае, если он попадает в метод контроллера через настроенный маршрут.
PandaWood

На самом деле, техническое объяснение состоит в том, что это работает только тогда, когда оскорбительный символ находится в «строке запроса» ... если он находится в пути запроса, атрибут проверки не работает
PandaWood

42

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


40

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

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

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


1
Применимо только для ASP.NET 4.5 (и, по-видимому, что будет после него). Pre 4.5 не поддерживает это.
Беска

3
Я хотел бы столкнуться с этим. Я использую .NET 4.5, и это именно то, что мне нужно, так как я не использую MVC и не могу изменить web.config.
Крис Гиллум

1
Да, но что, если вы используете .Net 2? У некоторых из нас нет выбора
Fandango68

это получает параметры POST или GET?
max4ever

Вы говорите, что это предотвращает исключение, которое уже было выброшено? Или .net 4.5 задерживает исключение и проверку до тех пор, пока данные фактически не будут считаны из Request?
ebyrob

34

Помните, что некоторые элементы управления .NET будут автоматически кодировать HTML-код. Например, установка свойства .Text в элементе управления TextBox автоматически закодирует его. Это, в частности, означает превращение <в &lt;, >в &gt;и &в &amp;. Так что будьте осторожны с этим ...

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

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

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


29

В файле web.config в тегах вставьте элемент httpRuntime с атрибутом requestValidationMode = "2.0". Также добавьте атрибут validateRequest = "false" в элементе pages.

Пример:

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

1
Для меня validateRequest = "false" не было необходимости, только requestValidationMode = "2.0"
Tom Redfern

3
Раздел "pages" должен находиться в разделе "system.web".
Картер Медлин

Опасный ответ, еще раз.
MC9000

Мне нужны были оба. Спасибо
Джек,

23

Если вы не хотите отключать 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);")

4
Это по-прежнему оставляет приложение уязвимым от готовых запросов POST. У обычного пользователя будут проблемы с вводом символов, таких как, или: кавычки, но у обычного хакера не возникнет проблем с отправкой искаженных данных на сервер. Я бы заговорил об этом.
Radu094

13
@ Radu094: Это решение позволяет вам сохранить ValidateRequest = true, что означает, что хакеры по-прежнему будут поражать эту стену. Голосуйте ВВЕРХ, так как это делает вас менее уязвимым, чем отключение ValidateRequest.
jbehren

21

Кажется, никто еще не упомянул ниже, но это решает проблему для меня. И прежде чем кто-нибудь скажет: да, это Visual Basic ... хм.

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

Я не знаю, есть ли минусы, но для меня это сработало потрясающе.


Работает для веб-форм c # или VB
TheAlbear

19

Другое решение:

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;
    }
}

Ницца! Не был осведомлен о возможности заменить валидатор запросов. Вместо того чтобы просто сказать «хорошо», как вы, я расширил эту идею, чтобы не проверять поля, заканчивающиеся на «_NoValidation» в качестве их имени. Код ниже.
Уолден Леверих

Уолден Леверих, для этого смотрите атрибуцию [AllowHtml]
Sel

Сел, да в среде MVC, которая будет работать. Но в приложении webforms у меня нет модели, чтобы сделать это. :-)
Уолден Леверих

15

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

Я рекомендую не делать этого.


13

В 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();
    }
}

13

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

Отключение защиты на уровне страницы и последующее кодирование - лучший вариант.

Вместо использования Server.HtmlEncode вы должны взглянуть на более новую, более полную библиотеку Anti-XSS от команды Microsoft ACE.


12

причина

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 было обнаружено от клиента


10

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

  • Сделайте текстовое поле HTML-элементом (например, textarea) вместо ASP-элемента.
  • Добавьте скрытое поле.
  • Добавьте следующую функцию JavaScript в свой заголовок.

    function boo () {targetText = document.getElementById ("HiddenField1"); sourceText = document.getElementById ("userbox"); 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, он просто увидит ошибку. Вы также можете сохранить все эти данные, закодированные в базе данных, затем удалить их (на стороне сервера), проанализировать и проверить на наличие атак, прежде чем отображать их в другом месте.


Это хорошее решение. Это правильный ручной способ управлять им самостоятельно, а не аннулировать весь сайт или страницу
Fandango68

Убедитесь, что для текстовой области используется разметка HTML, а не элемент управления ASP.Net (т.е. нет runat = "server"), а затем используйте скрытый элемент управления ASP.Net для скрытого. Это лучшее решение, которое я видел без компромиссов. Естественно, вы хотите проанализировать свои данные для XSS, SQL-инъекций на стороне сервера, но, по крайней мере, вы можете опубликовать HTML
MC9000

escape(...)может занять много времени. В моем случае разметка представляла собой целый (2 МБ) XML-файл. Вы можете спросить: «Почему бы тебе просто не использовать <input type="file"...и ... я согласен с тобой :)
Красный горох

10

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


9

Я тоже получал эту ошибку.

В моем случае пользователь ввел акцентированный символ áв имени роли (в отношении поставщика членства ASP.NET).

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

Я сделал это, чтобы решить проблему:

Вместо

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

Сделай это

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

@Html.Raw сделал свое дело.

Я получал имя роли как значение HTML roleName="Cadastro b&#225;s". Это значение с сущностью HTML &#225;было заблокировано ASP.NET MVC. Теперь я получаю roleNameзначение параметра таким, каким оно должно быть: roleName="Cadastro Básico"и движок ASP.NET MVC больше не будет блокировать запрос.


9

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

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

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


Ссылка не работает.
Питер Мортенсен

7

Вы также можете использовать функцию escape (string) в JavaScript для замены специальных символов. Затем на стороне сервера использовать сервер. URLDecode (строка), чтобы переключить его обратно.

Таким образом, вам не нужно отключать проверку ввода, и другим программистам будет понятнее, что строка может иметь HTML-содержимое.


7

Я заканчивал тем, что использовал 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;
}

Конечно, моя страница - это, в основном, ввод данных, и очень мало элементов, которые выполняют обратную передачу, но, по крайней мере, их данные сохраняются.


Там должны быть большие скобки вместо маленьких скобок. Как `if (tbs [i] .type == 'text') {` вместо `if (tbs (i) .type == 'text') {`
Шилпа Сони

5

Вы можете использовать что-то вроде:

var nvc = Request.Unvalidated().Form;

Позже nvc["yourKey"]должен работать.


Спасибо, ваш ответ сэкономил мне много времени
хабиб

4

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


4

Если вы просто хотите сказать своим пользователям, что <и> не должны использоваться, НО, вы не хотите, чтобы вся форма была обработана / отправлена ​​обратно (и потеряна вся информация) до того, как вы могли бы просто не вставить валидатор вокруг поля для проверки этих (и, возможно, других потенциально опасных) символов?


пост сказал "валидатор" пожалуйста
mxmissile

4

Ни одно из предложений не сработало для меня. Я не хотел отключать эту функцию для всего сайта, так как в 99% случаев я не хочу, чтобы мои пользователи размещали HTML на веб-формах. Я просто создал свой метод обхода, так как я единственный, кто использует это конкретное приложение. Я преобразовываю ввод в HTML в коде и вставляю его в свою базу данных.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.