Un valore Request.Form potenzialmente pericoloso è stato rilevato dal client

Ogni volta che un utente pubblica qualcosa che contiene < o >in una pagina nella mia applicazione Web, viene generata questa eccezione.

Non voglio entrare nella discussione sull'intelligenza di lanciare un'eccezione o mandare in crash un'intera applicazione web perché qualcuno ha inserito un personaggio in una casella di testo, ma sto cercando un modo elegante per gestirlo.

Intrappolare l'eccezione e mostrare

Si è verificato un errore, torna indietro e digita nuovamente l'intero modulo, ma questa volta non utilizzare <

non mi sembra abbastanza professionale.

La disabilitazione della post validazione ( validateRequest="false") eviterà sicuramente questo errore, ma lascerà la pagina vulnerabile a numerosi attacchi.

Idealmente: quando si verifica un postback contenente caratteri con restrizioni HTML, quel valore pubblicato nella raccolta Form verrà automaticamente codificato in HTML. Quindi la .Textproprietà della mia casella di testo saràsomething & lt; html & gt;

C'è un modo in cui posso farlo da un gestore?

Penso che tu lo stia attaccando da un'angolazione sbagliata cercando di codificare tutti i dati pubblicati.

Si noti che un " <" potrebbe anche provenire da altre fonti esterne, come un campo di database, una configurazione, un file, un feed e così via.

Inoltre, " <" non è intrinsecamente pericoloso. È pericoloso solo in un contesto specifico: quando si scrivono stringhe che non sono state codificate nell'output HTML (a causa di XSS).

In altri contesti diverse sottostringhe sono pericolose, ad esempio se si scrive un URL fornito dall'utente in un collegamento, la sottostringa " javascript:" potrebbe essere pericolosa. Il carattere di virgoletta singola invece è pericoloso quando si interpolano stringhe nelle query SQL, ma è assolutamente sicuro se fa parte di un nome inviato da un modulo o letto da un campo del database.

La linea di fondo è: non è possibile filtrare input casuali per personaggi pericolosi, perché qualsiasi personaggio può essere pericoloso nelle giuste circostanze. Dovresti codificare nel punto in cui alcuni caratteri specifici possono diventare pericolosi perché si incrociano in una sub-lingua diversa in cui hanno un significato speciale. Quando scrivi una stringa in HTML, dovresti codificare caratteri che hanno un significato speciale in HTML, usando Server.HtmlEncode. Se si passa una stringa a un'istruzione SQL dinamica, è necessario codificare caratteri diversi (o meglio, lasciare che il framework lo faccia per sé utilizzando istruzioni preparate o simili).

Quando sei sicuro di codificare HTML ovunque passi stringhe in HTML, quindi imposta validateRequest="false"la <%@ Page ... %>direttiva nei tuoi .aspxfile.

In .NET 4 potresti dover fare un po 'di più. A volte è necessario aggiungere anche <httpRuntime requestValidationMode="2.0" />a web.config ( riferimento ).

Esiste una soluzione diversa a questo errore se si utilizza ASP.NET MVC:

• ASP.NET MVC - pagine validateRequest = false non funziona?
• Perché ValidateInput (False) non funziona?
• ASP.NET MVC RC1, VALIDATEINPUT, UNA POTENZIALE RICHIESTA PERICOLOSA E LA PITFALL

Esempio C #:

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

Esempio di Visual Basic:

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

In ASP.NET MVC (a partire dalla versione 3), è possibile aggiungere l' AllowHtmlattributo a una proprietà sul modello.

Consente a una richiesta di includere markup HTML durante l'associazione del modello saltando la convalida della richiesta per la proprietà.

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

Se sei su .NET 4.0 assicurati di aggiungerlo nel tuo file web.config all'interno dei <system.web>tag:

<httpRuntime requestValidationMode="2.0" />

In .NET 2.0, la convalida della richiesta si applicava solo alle aspxrichieste. In .NET 4.0 questo è stato espanso per includere tutte le richieste. È possibile ripristinare l' esecuzione della convalida XSS solo durante l'elaborazione .aspxspecificando:

requestValidationMode="2.0"

È possibile disabilitare la richiesta convalidare interamente specificando:

validateRequest="false"

Per ASP.NET 4.0, è possibile consentire il markup come input per pagine specifiche anziché per l'intero sito inserendo tutto in un <location>elemento. Questo assicurerà che tutte le altre pagine siano al sicuro. NON è necessario inserire ValidateRequest="false"la pagina aspx.

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

È più sicuro controllarlo all'interno del tuo web.config, perché puoi vedere a livello di sito quali pagine consentono il markup come input.

È ancora necessario convalidare a livello di codice l'input nelle pagine in cui la convalida della richiesta è disabilitata.

Le risposte precedenti sono ottime, ma nessuno ha detto come escludere un singolo campo dalla convalida per iniezioni HTML / JavaScript. Non conosco le versioni precedenti, ma in MVC3 Beta puoi farlo:

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

Ciò convalida ancora tutti i campi tranne quello escluso. La cosa bella di questo è che i tuoi attributi di validazione convalidano ancora il campo, ma non ottieni le eccezioni "Un valore Request.Form potenzialmente pericoloso rilevato dal client".

L'ho usato per convalidare un'espressione regolare. Ho creato il mio ValidationAttribute per vedere se l'espressione regolare è valida o meno. Poiché le espressioni regolari possono contenere qualcosa che assomiglia a uno script, ho applicato il codice sopra riportato: l'espressione regolare viene ancora verificata se è valida o meno, ma non se contiene script o HTML.

In ASP.NET MVC è necessario impostare requestValidationMode = "2.0" e validateRequest = "false" in web.config e applicare un attributo ValidateInput all'azione del controller:

<httpRuntime requestValidationMode="2.0"/>

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

e

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

È possibile codificare HTML il contenuto della casella di testo, ma sfortunatamente ciò non impedisce l'eccezione. Nella mia esperienza non c'è modo di aggirare e devi disabilitare la convalida della pagina. In questo modo stai dicendo: "Starò attento, lo prometto."

Per MVC, ignorare la convalida dell'input aggiungendo

[ValidateInput (false)]

sopra ogni azione nel controller.

È possibile rilevare tale errore in Global.asax. Voglio ancora convalidare, ma mostrare un messaggio appropriato. Sul blog elencato di seguito, era disponibile un esempio come questo.

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

Il reindirizzamento a un'altra pagina sembra anche una risposta ragionevole all'eccezione.

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

La risposta a questa domanda è semplice:

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

Ciò disabiliterebbe la convalida per la richiesta particolare.

Tieni presente che alcuni controlli .NET codificheranno automaticamente l'output in HTML. Ad esempio, l'impostazione della proprietà .Text su un controllo TextBox lo codificherà automaticamente. Ciò significa specificamente convertire <in <, >in >e &in &. Quindi diffidare di fare questo ...

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

Tuttavia, la proprietà .Text per HyperLink, Literal ed Label non codificherà HTML, quindi avvolgendo Server.HtmlEncode (); intorno a tutto ciò che viene impostato su queste proprietà è un must se si desidera impedire<script> window.location = "http://www.google.com"; </script> l'output nella pagina e la successiva esecuzione.

Fai un piccolo esperimento per vedere cosa viene codificato e cosa no.

Nel file web.config, all'interno dei tag, inserire l'elemento httpRuntime con l'attributo requestValidationMode = "2.0". Aggiungi anche l'attributo validateRequest = "false" nell'elemento pagine.

Esempio:

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

Se non si desidera disabilitare ValidateRequest, è necessario implementare una funzione JavaScript per evitare l'eccezione. Non è l'opzione migliore, ma funziona.

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

Quindi nel codice dietro, nell'evento PageLoad, aggiungi l'attributo al tuo controllo con il codice successivo:

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

Sembra che nessuno abbia ancora menzionato il seguito, ma risolve il problema per me. E prima che qualcuno dica di sì, è Visual Basic ... schifo.

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

Non so se ci siano degli aspetti negativi, ma per me ha funzionato alla grande.

Un'altra soluzione è:

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

Se si utilizza Framework 4.0, la voce in web.config (<pages validateRequest = "false" />)

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

Se si utilizza Framework 4.5, la voce in web.config (requestValidationMode = "2.0")

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

Se vuoi solo per una singola pagina, nel tuo file aspx dovresti mettere la prima riga come questa:

<%@ Page EnableEventValidation="false" %>

se hai già qualcosa come <% @ Page, aggiungi semplicemente il resto => EnableEventValidation="false" %>

Consiglio di non farlo.

In ASP.NET, puoi rilevare l'eccezione e fare qualcosa al riguardo, come la visualizzazione di un messaggio descrittivo o il reindirizzamento a un'altra pagina ... Esiste anche la possibilità che tu possa gestire la convalida da solo ...

Visualizza messaggio amichevole:

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

Immagino che potresti farlo in un modulo; ma ciò lascia aperte alcune domande; cosa succede se si desidera salvare l'input in un database? Improvvisamente perché stai salvando i dati codificati nel database finisci per fidarti dell'input che è probabilmente una cattiva idea. Idealmente, i dati grezzi non codificati vengono archiviati nel database e nella codifica ogni volta.

Disabilitare la protezione a livello di pagina e quindi codificare ogni volta è un'opzione migliore.

Invece di utilizzare Server.HtmlEncode dovresti guardare la libreria Anti-XSS più nuova e completa del team Microsoft ACE.

Causa

ASP.NET per impostazione predefinita convalida tutti i controlli di input per contenuti potenzialmente non sicuri che possono portare a iniezioni cross-site (XSS) e iniezioni SQL . Pertanto, non consente tale contenuto generando l'eccezione di cui sopra. Per impostazione predefinita, si consiglia di consentire questo controllo su ogni postback.

Soluzione

In molte occasioni è necessario inviare contenuto HTML alla tua pagina tramite Rich TextBox o Rich Text Editor. In tal caso, puoi evitare questa eccezione impostando il tag ValidateRequest in@Page direttiva su false.

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

Ciò disabiliterà la convalida delle richieste per la pagina che hai impostato il flag ValidateRequest su false. Se si desidera disabilitare questo, controllare in tutta l'applicazione Web; dovrai impostarlo su false nella sezione web.config <system.web>

<pages validateRequest ="false" />

Per i framework .NET 4.0 o versioni successive è necessario aggiungere anche la seguente riga nella sezione <system.web> per far funzionare quanto sopra.

<httpRuntime requestValidationMode = "2.0" />

Questo è tutto. Spero che questo ti aiuti a sbarazzarti del problema di cui sopra.

Riferimento da: ASP.Net Errore: un valore Request.Form potenzialmente pericoloso è stato rilevato dal client

Ho trovato una soluzione che utilizza JavaScript per codificare i dati, che è decodificato in .NET (e non richiede jQuery).

• Rendi la casella di testo un elemento HTML (come textarea) anziché ASP.
• Aggiungi un campo nascosto.

• Aggiungi la seguente funzione JavaScript alla tua intestazione.

  function boo () {targetText = document.getElementById ("HiddenField1"); sourceText = document.getElementById ("userbox"); targetText.value = escape (sourceText.innerText); }

Nella tua textarea, includi un onchange che chiama boo ():

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

Infine, in .NET, utilizzare

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

Sono consapevole che questo è unidirezionale - se hai bisogno di due modi devi essere creativo, ma questo fornisce una soluzione se non puoi modificare web.config

Ecco un esempio che I (MC9000) ha ideato e utilizzato tramite 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
    });


});

E il markup:

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

Funziona benissimo. Se un hacker prova a postare ignorando JavaScript, vedrà solo l'errore. È possibile salvare anche tutti questi dati codificati in un database, quindi eliminarli (sul lato server) e analizzare e verificare la presenza di attacchi prima di visualizzarli altrove.

Le altre soluzioni qui sono belle, tuttavia è un po 'un dolore reale nella parte posteriore dover applicare [AllowHtml] a ogni singola proprietà del Modello, specialmente se hai oltre 100 modelli su un sito di dimensioni decenti.

Se come me, vuoi disattivare questa funzionalità (IMHO piuttosto inutile) su tutto il sito, puoi ignorare il metodo Execute () nel tuo controller di base (se non hai già un controller di base ti suggerisco di crearne uno, possono essere piuttosto utile per l'applicazione di funzionalità comuni).

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

Assicurati solo di codificare HTML tutto ciò che viene pompato nelle viste provenienti dall'input dell'utente (è comunque il comportamento predefinito in ASP.NET MVC 3 con Razor, quindi a meno che per qualche bizzarro motivo tu stia usando Html.Raw () tu non dovrebbe richiedere questa funzione.

Stavo ricevendo anche questo errore.

Nel mio caso, un utente ha inserito un carattere accentato áin un Nome ruolo (relativo al provider di appartenenze ASP.NET).

Passo il nome del ruolo a un metodo per concedere agli utenti quel ruolo e la $.ajaxrichiesta di post falliva miseramente ...

Ho fatto questo per risolvere il problema:

Invece di

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

Fai questo

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

@Html.Raw ha fatto il trucco.

Stavo ottenendo il nome del ruolo come valore HTML roleName="Cadastro bás". Questo valore con entità HTML áè stato bloccato da ASP.NET MVC. Ora ottengo il roleNamevalore del parametro come dovrebbe essere: roleName="Cadastro Básico"e il motore ASPCNET MVC non bloccherà più la richiesta.

Disattivare la convalida pagina se si ha realmente bisogno i caratteri speciali come, >,, <, ecc Poi assicurarsi che quando viene visualizzato l'input dell'utente, i dati sono HTML-codificato.

Esiste una vulnerabilità di sicurezza con la convalida della pagina, quindi può essere aggirata. Inoltre, la convalida della pagina non deve essere affidata esclusivamente.

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

È inoltre possibile utilizzare la funzione di escape (stringa) di JavaScript per sostituire i caratteri speciali. Quindi lato server utilizzare Server. URLDecode (stringa) per tornare indietro.

In questo modo non è necessario disattivare la convalida dell'input e sarà più chiaro agli altri programmatori che la stringa potrebbe avere contenuto HTML.

Ho finito per usare JavaScript prima di ogni postback per verificare i caratteri che non volevi, come ad esempio:

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

Concesso la mia pagina è principalmente l'inserimento di dati, e ci sono pochissimi elementi che fanno postback, ma almeno i loro dati vengono conservati.

Puoi usare qualcosa come:

var nvc = Request.Unvalidated().Form;

Più tardi, nvc["yourKey"]dovrebbe funzionare.

Fintanto che questi sono solo caratteri "<" e ">" (e non la stessa virgoletta) e li stai usando in un contesto come <input value = " this " />, sei al sicuro (mentre per <textarea > questo </textarea> saresti vulnerabile ovviamente). Ciò potrebbe semplificare la tua situazione, ma per qualcosa di più utilizza una delle altre soluzioni pubblicate.

Se stai solo cercando di dire ai tuoi utenti che <e> non devono essere utilizzati MA, non vuoi che l'intero modulo venga elaborato / inviato indietro (e perdi tutti gli input) in anticipo non potresti semplicemente inserire un validatore in tutto il campo per cercare quei personaggi (e forse altri potenzialmente pericolosi)?

Nessuno dei suggerimenti ha funzionato per me. Non volevo disattivare questa funzione per l'intero sito Web perché il 99% delle volte non voglio che i miei utenti inseriscano HTML nei moduli Web. Ho appena creato il mio metodo di lavoro poiché sono l'unico a utilizzare questa particolare applicazione. Converto l'input in HTML nel codice dietro e lo inserisco nel mio database.