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

Question

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

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

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

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

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

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

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

Есть ли способ сделать это из обработчика?

Answer 1

Причина

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

<pages validateRequest ="false" />

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

<httpRuntime requestValidationMode = "2.0" />

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Вместо

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 больше не будет блокировать запрос.

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

var nvc = Request.Unvalidated().Form;

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

Answer 9

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

Answer 10

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