Od klienta wykryto potencjalnie niebezpieczną wartość Request.Form

Za każdym razem, gdy użytkownik publikuje coś w mojej aplikacji internetowej <lub >na stronie, pojawia się ten wyjątek.

Nie chcę wchodzić w dyskusję na temat mądrości zgłaszania wyjątku lub zawieszania całej aplikacji internetowej, ponieważ ktoś wpisał znak w polu tekstowym, ale szukam eleganckiego sposobu, aby sobie z tym poradzić.

Przechwytywanie wyjątku i wyświetlanie

Wystąpił błąd, wróć i ponownie wpisz cały formularz, ale tym razem nie używaj <

nie wydaje mi się wystarczająco profesjonalny.

Wyłączenie post validation ( validateRequest="false") z pewnością pozwoli uniknąć tego błędu, ale pozostawi stronę podatną na wiele ataków.

Idealnie: gdy wystąpi zwrotny zwrot zawierający znaki HTML, ta zaksięgowana wartość w kolekcji Form zostanie automatycznie zakodowana w HTML. Tak więc .Textwłaściwość mojego pola tekstowego będziesomething & lt; html & gt;

Czy mogę to zrobić w programie obsługi?

Myślę, że atakujesz go pod niewłaściwym kątem, próbując zakodować wszystkie opublikowane dane.

Pamiętaj, że „ <” może również pochodzić z innych zewnętrznych źródeł, takich jak pole bazy danych, konfiguracja, plik, kanał i tak dalej.

Ponadto „ <” nie jest z natury niebezpieczne. Jest to niebezpieczne tylko w określonym kontekście: podczas pisania ciągów, które nie zostały zakodowane na wyjściu HTML (z powodu XSS).

W innych kontekstach różne podciągi są niebezpieczne, na przykład, jeśli wpiszesz podany przez użytkownika adres URL w podlinkowaniu, podciąg „ javascript:” może być niebezpieczny. Z drugiej strony pojedynczy znak cudzysłowu jest niebezpieczny podczas interpolacji ciągów w zapytaniach SQL, ale jest całkowicie bezpieczny, jeśli jest częścią nazwy przesłanej z formularza lub odczytanej z pola bazy danych.

Najważniejsze jest to: nie można filtrować losowych danych wejściowych pod kątem niebezpiecznych znaków, ponieważ każda postać może być niebezpieczna w odpowiednich okolicznościach. Powinieneś zakodować w miejscu, w którym niektóre określone znaki mogą stać się niebezpieczne, ponieważ przechodzą na inny podjęzyk, w którym mają specjalne znaczenie. Kiedy piszesz ciąg znaków do HTML, powinieneś zakodować znaki, które mają specjalne znaczenie w HTML, używając Server.HtmlEncode. Jeśli przekażesz ciąg do dynamicznej instrukcji SQL, powinieneś zakodować różne znaki (lub lepiej, pozwól, aby środowisko to zrobiło za Ciebie, używając przygotowanych instrukcji itp.).

Gdy masz pewność, że kodujesz HTML wszędzie, gdzie przekazujesz ciągi znaków do HTML, ustaw validateRequest="false"w <%@ Page ... %>dyrektywie .aspxplik (i).

W .NET 4 może być konieczne zrobienie czegoś więcej. Czasami konieczne jest również dodanie <httpRuntime requestValidationMode="2.0" />do pliku web.config ( odniesienie ).

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

• ASP.NET MVC - strony validateRequest = false nie działa?
• Dlaczego ValidateInput (False) nie działa?
• ASP.NET MVC RC1, WALIDACJA WEJŚCIA, POTENCJALNE NIEBEZPIECZNE ZAPYTANIE I PITFALL

Próbka C #:

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

Próbka Visual Basic:

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

W ASP.NET MVC (od wersji 3) możesz dodać AllowHtmlatrybut do właściwości w swoim modelu.

Pozwala żądaniu uwzględnić znaczniki HTML podczas wiązania modelu, pomijając sprawdzanie poprawności żądania dla właściwości.

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

Jeśli korzystasz z .NET 4.0, upewnij się, że dodajesz to do pliku web.config wewnątrz <system.web>tagów:

<httpRuntime requestValidationMode="2.0" />

W .NET 2.0 sprawdzanie poprawności aspxżądań dotyczyło tylko żądań. W .NET 4.0 został on rozszerzony o wszystkie żądania. Możesz przywrócić sprawdzanie poprawności XSS tylko podczas przetwarzania .aspx, określając:

requestValidationMode="2.0"

Możesz całkowicie wyłączyć sprawdzanie poprawności , określając:

validateRequest="false"

W przypadku ASP.NET 4.0 można zezwolić na znaczniki jako dane wejściowe dla konkretnych stron zamiast dla całej witryny, umieszczając je w jednym <location>elemencie. Dzięki temu wszystkie Twoje strony będą bezpieczne. NIE musisz umieszczać ValidateRequest="false"strony .aspx.

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

Bezpieczniej jest to kontrolować w pliku web.config, ponieważ na poziomie witryny można zobaczyć, które strony zezwalają na znaczniki jako dane wejściowe.

Nadal musisz programowo sprawdzić poprawność danych wejściowych na stronach, na których sprawdzanie poprawności żądania jest wyłączone.

Poprzednie odpowiedzi są świetne, ale nikt nie powiedział, jak wykluczyć jedno pole z weryfikacji pod kątem wstrzyknięć HTML / JavaScript. Nie wiem o poprzednich wersjach, ale w MVC3 Beta możesz to zrobić:

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

To nadal sprawdza poprawność wszystkich pól z wyjątkiem jednego wykluczonego. Zaletą tego jest to, że twoje atrybuty sprawdzania poprawności nadal sprawdzają poprawność pola, ale po prostu nie otrzymujesz wyjątków „Potencjalnie niebezpieczne żądanie. Wykryto formularz od klienta”.

Użyłem tego do sprawdzania poprawności wyrażenia regularnego. Zrobiłem własny atrybut ValidationAttribute, aby sprawdzić, czy wyrażenie regularne jest prawidłowe, 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, czy nie, ale nie, jeśli zawiera skrypty lub HTML.

W ASP.NET MVC należy ustawić requestValidationMode = "2.0" i validateRequest = "false" w pliku web.config i zastosować 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ć zawartość HTML w polu tekstowym, ale niestety nie powstrzyma to wyjątku. Z mojego doświadczenia wynika, że ​​nie ma takiej możliwości i musisz wyłączyć sprawdzanie poprawności strony. Robiąc to, mówisz: „Będę ostrożny, obiecuję”.

W przypadku MVC zignoruj ​​sprawdzanie poprawności danych wejściowych przez dodanie

[ValidateInput (false)]

powyżej każdej akcji w kontrolerze.

Możesz złapać ten błąd w Global.asax. Nadal chcę sprawdzić poprawność, ale pokażę odpowiedni komunikat. Na blogu wymienionym poniżej 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

Odpowiedź na to pytanie jest prosta:

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

Spowoduje to wyłączenie sprawdzania poprawności dla konkretnego żądania.

Należy pamiętać, że niektóre kontrolki .NET automatycznie kodują dane wyjściowe w formacie HTML. Na przykład ustawienie właściwości .Text w kontrolce TextBox spowoduje jej automatyczne zakodowanie. Oznacza to w szczególności konwersję <na <, >na >i &na &. Uważaj więc na to ...

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

Jednak właściwość .Text dla HyperLink, Literal i Label nie koduje HTML, więc otacza Server.HtmlEncode (); wszystko, co jest ustawione w tych właściwościach, jest koniecznością, jeśli chcesz zapobiec <script> window.location = "http://www.google.com"; </script>wyświetlaniu ich na stronie, a następnie wykonywaniu.

Wykonaj małe eksperymenty, aby zobaczyć, co zostanie zakodowane, a co nie.

W pliku web.config w tagach wstaw element httpRuntime z atrybutem requestValidationMode = „2.0”. Dodaj także 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łączać ValidateRequest, musisz zaimplementować funkcję JavaScript, aby uniknąć wyjątku. To nie jest 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 z tyłu, w zdarzeniu PageLoad, dodaj atrybut do kontrolki za pomocą następnego kodu:

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. I zanim ktokolwiek powie: tak, to Visual Basic ... fuj.

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

Nie wiem, czy są jakieś wady, ale dla mnie zadziałało to niesamowicie.

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

Jeśli używasz frameworka 4.0, to wpis w pliku web.config (<pages validateRequest = "false" />)

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

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

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

Jeśli chcesz tylko dla jednej strony, w pliku aspx powinieneś umieścić pierwszy wiersz w następujący sposób:

<%@ Page EnableEventValidation="false" %>

jeśli masz już coś w rodzaju <% @ Page, po prostu dodaj resztę => EnableEventValidation="false"%>

Polecam tego nie robić.

W ASP.NET możesz złapać wyjątek i coś z tym zrobić, na przykład wyświetlić przyjazną wiadomość lub przekierować na inną stronę ... Istnieje również możliwość samodzielnej obsługi sprawdzania poprawności ...

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żesz to zrobić w module; ale to pozostawia otwarte pytania; co jeśli chcesz zapisać dane wejściowe w bazie danych? Nagle, ponieważ zapisujesz zakodowane dane w bazie danych, w końcu ufasz wejściom, co jest prawdopodobnie złym pomysłem. Idealnie przechowujesz nieprzetworzone nieprzetworzone dane w bazie danych i kodowaniu za każdym razem.

Lepszym rozwiązaniem jest wyłączenie ochrony na poziomie strony, a następnie kodowanie za każdym razem.

Zamiast korzystać z Server.HtmlEncode powinieneś przyjrzeć się nowszej, bardziej kompletnej bibliotece Anti-XSS od zespołu Microsoft ACE.

Przyczyna

Program ASP.NET domyślnie sprawdza poprawność wszystkich formantów wejściowych pod kątem potencjalnie niebezpiecznych treści, które mogą prowadzić do skryptów krzyżowych (XSS) i wstrzyknięć SQL . W związku z tym nie zezwala na taką treść, zgłaszając powyższy wyjątek. Domyślnie zaleca się zezwalanie na to sprawdzanie przy każdym opóźnieniu zwrotnym.

Rozwiązanie

W wielu przypadkach musisz przesłać treść HTML na swoją stronę za pomocą Rich TextBoxes lub Rich Text Editor. W takim przypadku możesz uniknąć tego wyjątku, ustawiając tag ValidateRequest w @Pagedyrektywie na false.

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

Spowoduje to wyłączenie sprawdzania poprawności żądań dla strony, dla której ustawiono flagę ValidateRequest na false. Jeśli chcesz to wyłączyć, sprawdź w swojej aplikacji internetowej; musisz ustawić wartość false w swojej sekcji web.config <system.web>

<pages validateRequest ="false" />

W przypadku platform .NET 4.0 lub nowszych należy również dodać następujący wiersz w sekcji <system.web>, aby powyższe działało.

<httpRuntime requestValidationMode = "2.0" />

Otóż ​​to. Mam nadzieję, że pomoże to w pozbyciu się powyższego problemu.

Odniesienie do: Błąd ASP.Net: Wykryto potencjalnie niebezpieczną wartość Request.Form od klienta

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

• Ustaw pole tekstowe jako element 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 („skrzynka użytkownika”); targetText.value = escape (sourceText.innerText); }

W swoim obszarze tekstowym umieść onchange, który wywołuje boo ():

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

Wreszcie, w .NET, użyj

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

Wiem, że jest to jednokierunkowe - jeśli potrzebujesz dwukierunkowego, musisz wykazać się kreatywnością, ale zapewnia to rozwiązanie, jeśli nie możesz edytować pliku web.config

Oto przykład, który I (MC9000) wymyśliłem i używam 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 znaczniki:

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

To działa świetnie. Jeśli haker spróbuje opublikować, omijając JavaScript, zobaczy tylko błąd. Możesz również zapisać wszystkie dane zakodowane w bazie danych, a następnie usunąć z niego krajobraz (po stronie serwera) oraz przeanalizować i sprawdzić ataki przed wyświetleniem w innym miejscu.

Inne rozwiązania tutaj są fajne, jednak to trochę królewski ból z tyłu, gdy trzeba zastosować [AllowHtml] do każdej pojedynczej właściwości Modelu, szczególnie jeśli masz ponad 100 modeli na przyzwoitej stronie.

Jeśli tak jak ja, chcesz wyłączyć tę funkcję (całkiem bezcelową) z całej witryny, możesz zastąpić metodę Execute () w kontrolerze podstawowym (jeśli nie masz jeszcze kontrolera podstawowego, sugeruję, aby go utworzyć, mogą być całkiem przydatne do stosowania wspólnej funkcjonalności).

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

Tylko upewnij się, że kodujesz HTML wszystko, co jest wypompowywane do widoków pochodzących z danych wejściowych użytkownika (tak czy inaczej jest to domyślne zachowanie w ASP.NET MVC 3 z Razor, więc chyba że z jakiegoś dziwnego powodu używasz Html.Raw () nie powinien wymagać tej funkcji.

Wystąpił również ten błąd.

W moim przypadku użytkownik wprowadził znak akcentowany áw nazwie roli (w odniesieniu do dostawcy członkostwa ASP.NET).

Przekazuję nazwę roli do metody, aby przyznać użytkownikom tę rolę, a $.ajaxżądanie wysłania 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 wykonał lewę.

Otrzymałem nazwę roli jako wartość HTML roleName="Cadastro bás". Ta wartość z jednostką HTML ábyła blokowana przez ASP.NET MVC. Teraz otrzymuję roleNamewartość parametru taką, jaka powinna być: roleName="Cadastro Básico"a silnik ASP.NET MVC nie będzie już blokował żądania.

Wyłączyć sprawdzanie strony, jeśli naprawdę potrzebujesz znaków specjalnych, takich jak, >,, <, itd. Następnie upewnić się, że gdy wyświetlana jest wprowadzane przez użytkownika dane są kodowane w formacie HTML.

Podczas sprawdzania poprawności strony występuje luka w zabezpieczeniach, więc można ją obejść. Nie należy polegać wyłącznie na sprawdzaniu poprawności strony.

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

Możesz również użyć funkcji Escape (ciąg znaków) JavaScript, aby zastąpić znaki specjalne. Następnie po stronie serwera użyj serwera. URLDecode (ciąg), aby przełączyć z powrotem.

W ten sposób nie musisz wyłączać sprawdzania poprawności danych wejściowych, a dla innych programistów stanie się jasne, że ciąg może zawierać treść HTML.

Skończyłem używać JavaScript przed każdym zwrotnym zwrotnym sprawdzaniem znaków, których nie chciałeś, takich 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;
}

Przyznaję, że moja strona to głównie wprowadzanie danych i jest bardzo mało elementów, które wykonują zwroty, ale przynajmniej ich dane są zachowywane.

Możesz użyć czegoś takiego jak:

var nvc = Request.Unvalidated().Form;

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

Dopóki są to tylko znaki „<” i „>” (a nie sam znak podwójnego cudzysłowu) i używasz ich w kontekście takim jak <input value = " this " />, jesteś bezpieczny (podczas gdy dla <textarea > ten </textarea> oczywiście byłbyś narażony). Może to uprościć twoją sytuację, ale do wszystkiego innego użyj jednego z innych opublikowanych rozwiązań.

Jeśli chcesz tylko powiedzieć użytkownikom, że <i> nie będą używane, ALE, nie chcesz, aby cały formularz został ponownie przetworzony / wysłany z powrotem (i stracił wszystkie dane wejściowe), czy nie możesz po prostu umieścić walidator wokół pola, aby sprawdzić te (i może inne potencjalnie niebezpieczne) postacie?

Żadna z sugestii mi nie działała. I tak nie chciałem wyłączać tej funkcji dla całej witryny, ponieważ 99% czasu nie chcę, aby moi użytkownicy umieszczali HTML na formularzach internetowych. Właśnie stworzyłem własną metodę obejścia, ponieważ tylko ja używam tej konkretnej aplikacji. Przekształcam dane wejściowe na HTML w kodzie z tyłu i wstawiam do mojej bazy danych.