У клієнта було виявлено потенційно небезпечне значення Request.Form

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

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

Захоплення винятку та показ

Виникла помилка, поверніться та повторно введіть всю свою форму, але цього разу не використовуйте <

не здається мені достатньо професійним.

Вимкнення перевірки публікації ( validateRequest="false"), безумовно, уникне цієї помилки, але це зробить сторінку вразливою для ряду атак.

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

Чи є спосіб це зробити з обробника?

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

Зауважте, що " <" також може надходити з інших зовнішніх джерел, таких як поле бази даних, конфігурація, файл, канал тощо.

Крім того, " <" не є по суті небезпечним. Це небезпечно лише в конкретному контексті: при написанні рядків, які не були закодовані до виводу 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:

<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 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 , але, на жаль, це не зупинить винятку. На мій досвід, обходу немає, і вам доведеться вимкнути перевірку сторінки. Роблячи це, ти кажеш: "Буду обережний, обіцяю".

Для 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. Наприклад, встановлення властивості .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 (<сторінки 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.

Причина

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 було виявлено у клієнта

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

• Зробіть текстовий текст HTML-елементом (наприклад textarea) замість ASP.
• Додайте приховане поле.

• Додайте до заголовка наступну функцію JavaScript.

  функція boo () {targetText = document.getElementById ("HiddenField1"); sourceText = document.getElementById ("скринька користувача"); targetText.value = втеча (sourceText.innerText); }

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

Інші рішення тут є приємними, однак, ззаду потрібно трохи по-королівськи застосувати [AllowHtml] до кожного властивості моделі, особливо якщо на сайті пристойного розміру є понад 100 моделей.

Якщо мені подобається, ви хочете вимкнути цю (IMHO досить безглузду) функцію із сайту, ви можете замінити метод 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 для заміни спеціальних символів. Потім сторона сервера використовує Сервер. URL-код (рядок), щоб повернути його назад.

Таким чином, вам не доведеться вимикати перевірку вводу, а іншим програмістам буде зрозуміліше, що рядок може мати вміст 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"]повинні працювати.

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

Якщо ви просто хочете сказати своїм користувачам, що <і> не використовуватимуться, АЛЕ, ви не хочете, щоб вся форма була оброблена / опублікована назад (і втратити всі дані) раніше, чи не могли б ви просто поставити валідатор навколо поля для екранізації цих (і, можливо, інших потенційно небезпечних) символів?

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