Potencjalnie niebezpieczna Prośba.Wartość formularza została wykryta od klienta

Istnieje inne rozwiązanie tego błędu, jeśli używasz ASP.NET MVC:

• ASP.NET MVC-pages validateRequest=false nie działa?
• dlaczego ValidateInput (False) nie działa?
• ASP.NET MVC RC1, VALIDATEINPUT, POTENCJALNE NIEBEZPIECZNE ŻĄDANIE I PUŁAPKA

C# sample:

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

Visual Basic sample:

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

W ASP.NET MVC (począwszy od wersji 3), można dodać AllowHtml przypisanie właściwości w modelu.

Pozwala żądaniu dołączyć znaczniki HTML podczas wiązania modelu, pomijając walidację żądania dla właściwości.

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

Jeśli korzystasz z. NET 4.0 upewnij się, że dodałeś to w swojej sieci.config plik wewnątrz znaczników <system.web>:

<httpRuntime requestValidationMode="2.0" />

W.NET 2.0 Walidacja żądań ma zastosowanie tylko do żądań aspx. W.NET 4.0 zostało to rozszerzone o wszystkie żądania. Możesz powrócić do tylko wykonując walidację XSS podczas przetwarzania .aspx, podając:

requestValidationMode="2.0"

Możesz całkowicie wyłączyć walidację żądania , podając:

validateRequest="false"

Dla ASP.NET 4.0, możesz zezwolić znaczniki jako dane wejściowe dla określonych stron zamiast całej witryny, umieszczając je wszystkie w elemencie <location>. Dzięki temu wszystkie pozostałe Strony będą bezpieczne. Nie musisz wkładać ValidateRequest="false" do swojego .strona aspx.

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

Bezpieczniej jest kontrolować to wewnątrz sieci.config, ponieważ można zobaczyć na poziomie witryny, które strony zezwalają na znaczniki jako wejście.

Nadal musisz programowo walidować dane wejściowe na stronach, na których Walidacja żądania jest niepełnosprawni.

Poprzednie odpowiedzi są świetne, ale nikt nie powiedział, jak wykluczyć Pojedyncze pole z walidacji dla zastrzyków HTML / JavaScript. Nie wiem jak poprzednie wersje, ale w MVC3 Beta można to zrobić:

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

To nadal sprawdza wszystkie pola z wyjątkiem wykluczonego. Zaletą tego jest to, że atrybuty walidacji nadal sprawdzają poprawność pola, ale po prostu nie otrzymujesz " potencjalnie niebezpiecznego żądania.Wartość formularza została wykryta od klienta" wyjątki.

Użyłem tego do walidacji wyrażenia regularnego. Zrobiłem własne ValidationAttribute, aby sprawdzić, czy wyrażenie regularne jest poprawne, czy nie. Ponieważ wyrażenia regularne mogą zawierać coś, co wygląda jak skrypt, zastosowałem powyższy kod - Wyrażenie regularne jest nadal sprawdzane, czy jest poprawne, ale nie, jeśli zawiera skrypty lub HTML.

W ASP.NET MVC musisz ustawić requestValidationMode = " 2.0 "i validateRequest = "false" W web.config i zastosuj atrybut ValidateInput do akcji kontrolera:

<httpRuntime requestValidationMode="2.0"/>

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

I

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

Możesz kodować HTML zawartość pola tekstowego, ale niestety to nie powstrzyma wyjątku. Z mojego doświadczenia nie ma możliwości obejścia i musisz wyłączyć walidację strony. Robiąc to mówisz: "będę ostrożny, obiecuję."

Dla MVC, ignoruj walidację wejściową przez dodanie

[ValidateInput (false)]

Nad każdą akcją w kontrolerze.

Możesz wyłapać ten błąd w Global.asax. Nadal chcę potwierdzić, ale pokazać odpowiednią wiadomość. Na poniższym blogu dostępna była taka próbka.

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

Przekierowanie na inną stronę również wydaje się rozsądną odpowiedzią na wyjątek.

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

Należy pamiętać, że niektóre kontrolki. NET automatycznie kodują wyjście HTML. Na przykład, ustawienie .Właściwość Text na kontrolce TextBox automatycznie ją zakoduje. To konkretnie oznacza przekształcenie < w <, > na > i & na &. Więc uważaj na to...

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

Jednak .Text property for HyperLink, Literal i Label nie koduje HTML rzeczy, więc serwer zawijania.HtmlEncode (); wokół wszystkiego co jest ustawione na tych właściwościach jest musi, jeśli chcesz zapobiec wyświetleniu <script> window.location = "http://www.google.com"; </script> na stronie, a następnie wykonaniu.

Zrób małe eksperymenty, aby zobaczyć, co zostanie zakodowane, a co nie.

ODPOWIEDŹ na to pytanie jest prosta:

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

Spowoduje to wyłączenie walidacji dla danego żądania.

W sieci.plik konfiguracyjny, wewnątrz znaczników, Wstaw element httpRuntime z atrybutem requestValidationMode="2.0". Dodaj również atrybut validaterequest="false" w elemencie pages.

Przykład:

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

Jeśli nie chcesz wyłączyć ValidateRequest, musisz zaimplementować funkcję JavaScript, aby uniknąć wyjątku. Nie jest to najlepsza opcja, ale działa.

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

Następnie w kodzie za, NA zdarzeniu PageLoad, Dodaj atrybut do kontrolki z następnym kodem:

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

Wygląda na to, że nikt jeszcze nie wspomniał o tym poniżej, ale rozwiązuje to problem dla mnie. I zanim ktoś powie tak, to Visual Basic... Fuj.

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

Innym rozwiązaniem jest:

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

W ASP.NET, możesz złapać wyjątek i coś z tym zrobić, na przykład wyświetlając przyjazną wiadomość lub przekierowanie na inną stronę... Istnieje również możliwość, że możesz samodzielnie obsłużyć walidację...

Wyświetl przyjazną wiadomość:

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

Myślę, że można to zrobić w module; ale to pozostawia kilka pytań; co jeśli chcesz zapisać dane wejściowe do bazy danych? Nagle, ponieważ zapisujesz zakodowane dane do bazy danych, ufasz wejściom z niej, co prawdopodobnie jest złym pomysłem. Najlepiej przechowywać surowe niekodowane dane w bazie danych i za każdym razem kodować.

Wyłączenie ochrony na poziomie strony, a następnie kodowanie za każdym razem jest lepszą opcją.

Zamiast używać serwera.HtmlEncode powinieneś spójrz na nowszą, bardziej kompletną bibliotekę Anti-XSS {[6] } od Microsoft ACE team.

Jeśli używasz frameworka 4.0 to wpis w sieci.config ()

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

Jeśli używasz frameworka 4.5 to wpis w sieci.config (requestValidationMode="2.0")

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

Jeśli chcesz mieć tylko jedną stronę, to w pliku aspx powinieneś umieścić pierwszą linię w następujący sposób:

<%@ Page EnableEventValidation="false" %>

Jeśli masz już coś takiego jak EnableEventValidation="false" %>

Inne rozwiązania tutaj są ładne, jednak to trochę Królewski ból z tyłu, aby zastosować [AllowHtml] do każdej pojedynczej właściwości modelu, zwłaszcza jeśli masz ponad 100 modeli na przyzwoitej wielkości stronie.

Jeśli tak jak ja, chcesz wyłączyć tę (IMHO całkiem bezsensowną) funkcję off site wide możesz nadpisać metodę Execute() w kontrolerze bazowym (jeśli nie masz jeszcze kontrolera bazowego, sugeruję, abyś go zrobił, mogą być całkiem przydatne do stosowania zwykłych funkcjonalność).

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

Po prostu upewnij się, że kodujesz HTML wszystko, co jest pompowane do widoków, które pochodzą z wejścia użytkownika (jest to domyślne zachowanie w ASP.NET MVC 3 z Razorem i tak, więc chyba że z jakiegoś dziwacznego powodu używasz Html.Raw () nie powinieneś wymagać tej funkcji.

Też miałem ten błąd.

W moim przypadku użytkownik wpisał znak akcentowany á w nazwie roli (odnośnie ASP.NET dostawca członkostwa).

Przekazuję nazwę roli do metody przyznawania użytkownikom tej roli i $.ajax żądanie post nie powiodło się...

Zrobiłem to, aby rozwiązać problem:

Zamiast

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

Zrób to

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

@Html.Raw udało się.

Otrzymywałem nazwę roli jako wartość HTML roleName="Cadastro bás". Wartość ta z encją HTML á został zablokowany przez ASP.NET MVC. Teraz otrzymuję wartość parametru roleName tak jak powinna być: roleName="Cadastro Básico" i ASP.NET silnik MVC nie będzie już blokował żądania.

Cause

ASP.NET domyślnie sprawdza wszystkie kontrolki wprowadzania potencjalnie niebezpiecznych treści, które mogą prowadzić do cross-Site scripting (XSS) i SQL Injection . Tym samym uniemożliwia takie treści poprzez rzucenie powyższego wyjątku. Domyślnie zaleca się zezwalanie na to sprawdzanie na każdym postbacku.

Rozwiązanie

Przy wielu okazjach musisz przesłać zawartość HTML na swoją stronę za pomocą Rich TextBoxes lub Rich Text Editors. W tym przypadek można uniknąć tego wyjątku, ustawiając znacznik ValidateRequest w dyrektywie @Page Na false.

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

Spowoduje to wyłączenie walidacji żądań dla strony, którą ustawiłeś flagę ValidateRequest na false. Jeśli chcesz to wyłączyć, sprawdź w całej aplikacji internetowej; musisz ustawić ją na false w sieci.config Sekcja

<pages validateRequest ="false" />

W przypadku frameworków. NET 4.0 lub nowszych należy również dodać następującą linię w dział do zrobienia powyższa praca.

<httpRuntime requestValidationMode = "2.0" />

Reference by: ASP.Net błąd: potencjalnie niebezpieczne żądanie.Wartość formularza została wykryta od Klienta

Wyłącz walidację strony, jeśli naprawdę potrzebujesz znaków specjalnych, takich jak, >, , <, itd. Następnie upewnij się, że podczas wyświetlania danych wejściowych użytkownika dane są zakodowane w formacie HTML.

Istnieje luka w zabezpieczeniach z walidacją strony, więc można ją ominąć. Również Walidacja strony nie powinna polegać wyłącznie na.

Zobacz: http://www.procheckup.com/PDFs/bypassing-dot-NET-ValidateRequest.pdf

Znalazłem rozwiązanie, które używa JavaScript do kodowania danych, które jest dekodowane w. NET (i nie wymaga jQuery).

• niech textbox będzie elementem HTML (jak textarea) zamiast ASP.
• Dodaj ukryte pole.

• Dodaj następującą funkcję JavaScript do nagłówka.

  funkcja boo() { targetText = document.getElementById ("HiddenField1"); sourceText = document.getElementById ("userbox"); targetText.wartość = escape(sourceText.innerText); }

W polu textarea dodaj zmianę wywołującą Boo ():

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

Wreszcie, w. NET, użyj

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

Zdaję sobie sprawę, że to jest jednokierunkowe- jeśli potrzebujesz dwukierunkowej, musisz być kreatywny, ale to zapewnia rozwiązanie, jeśli nie możesz edytować sieci.config

Oto przykład, który wymyśliłem (MC9000) i użyłem przez 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
    });


});

I znacznik:

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

Możesz również użyć JavaScript escape(string) do zastąpienia znaków specjalnych. Następnie po stronie serwera Użyj serwera.URLDecode (string) to switch it back.

W ten sposób nie musisz wyłączać walidacji danych wejściowych i dla innych programistów będzie bardziej jasne, że łańcuch znaków może zawierać zawartość HTML.

Skończyło się na użyciu JavaScript przed każdym postback, aby sprawdzić, czy znaki nie chcesz, takie jak:

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

Przyznany moja strona jest głównie wprowadzanie danych, i istnieje bardzo niewiele elementów, które robią postbacks, ale przynajmniej ich dane są zachowane.

Tak długo, jak są to tylko "" (a nie sam podwójny cudzysłów) i używasz ich w kontekście takim jak , jesteś bezpieczny (podczas gdy dla <em>ten </em> będziesz oczywiście podatny). To może uprościć twoją sytuację, ale dla cokolwiek{[2] } Więcej użyj jednego z innych opublikowanych rozwiązań.

Jeśli chcesz tylko powiedzieć swoim użytkownikom, że nie mają być używane, ale nie chcesz, aby cały formularz został przetworzony/wysłany z powrotem (i stracił wszystkie dane wejściowe) przed ręką, czy nie mógłbyś po prostu umieścić walidatora wokół pola, aby wyświetlić te (i może inne potencjalnie niebezpieczne) znaki?

Żadna z sugestii mi nie pomogła. I tak nie chciałem wyłączać tej funkcji dla całej strony, ponieważ 99% czasu nie chcę, aby moi użytkownicy umieszczali HTML na formularzach internetowych. Właśnie stworzyłem własną metodę pracy, ponieważ jako jedyny korzystam z tej konkretnej aplikacji. Konwertuję dane wejściowe do HTML w kodzie z tyłu i wstawiam je do mojej bazy danych.

Możesz użyć czegoś w rodzaju:

var nvc = Request.Unvalidated().Form;

Później, nvc["yourKey"] powinno zadziałać.