ValidateRequest = “false” non funziona in Asp.Net 4

156

Ho un modulo in cui uso ckeditor. Questo modulo ha funzionato bene su Asp.Net 2.0 e 3.5 ma ora non funziona su Asp.Net 4+. Ho la direttiva ValidateRequest = "false". Eventuali suggerimenti?

asp.net asp.net-4.0 validate-request

— Hasang
fonte

C'è un breve articolo sul rendering corretto dei controlli di convalida se qualcuno se ne frega: Errore di convalida in .NET 4

— Ian

qualcuno può farmi sapere quali sono gli svantaggi dell'utilizzo di ValidationRequest = false?

— fc123,

194

Soluzione trovata nella pagina di errore. Ho solo bisogno di aggiungere requestValidationMode = "2.0"

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

Informazioni MSDN: proprietà HttpRuntimeSection.RequestValidationMode

— Hasang
fonte

1

è fantastico, ma qualcuno sa come impostare questo per pagina? Inoltre, come posso inserirlo in web.config in modo che funzioni ancora con .NET 2?

— MK.

1

@MK: Non penso che ci sia una direttiva di pagina per questa impostazione. Non puoi farlo funzionare su .net 2. Non penso che sarebbe necessario. Perché è possibile creare solo un'app Web destinata a una sola versione del framework. Copia questa riga in .net 4 web.config che ne ha bisogno ...

— HasanG,

2

Ma cosa è cambiato nella validazione per .net 4? C'è un modo per farlo senza cambiare la modalità di convalida?

— Sly

4

@Sly: puoi trovare la risposta qui: asp.net/learn/whitepapers/aspnet4/…

— HasanG il

qualcuno può farmi sapere perché nell'applicazione asp.net 4.0 utilizzando requestValidationMode = "2.0" è una buona idea?

— fc123,

102

C'è un modo per riportare la convalida su 2.0 per una pagina. Aggiungi il codice seguente al tuo web.config:

<configuration>
    <location path="XX/YY">
        <system.web>
            <httpRuntime requestValidationMode="2.0" />
        </system.web>
    </location>

    ...
    the rest of your configuration
    ...

</configuration>

— Ben Hoffman
fonte

La posizione è qualsiasi percorso e si basa su qualsiasi nodo sotto la cartella specificata nella struttura.

— DFTR

7

Questa è una soluzione migliore della risposta accettata perché non è ampia piuttosto che limitata all'ambito specifico definito nel percorso dell'ubicazione

— Charles Wesley,

5

La dichiarazione <location ..> sopra dovrebbe essere inserita nella dichiarazione <configuration> ma non più annidata.

— rbassett,

1

L'impostazione per pagina non sembra funzionare per progetti destinati a .NET 4.6.1.

— Dennis T - Ripristina Monica -

56

So che questa è una vecchia domanda, ma se si riscontra questo problema in MVC 3, è possibile decorare ActionMethodcon [ValidateInput(false)]e semplicemente disattivare la convalida della richiesta per un singolo ActionMethod, il che è utile. E non è necessario apportare modifiche al web.configfile, quindi è comunque possibile utilizzare la convalida della richiesta .NET 4 ovunque.

per esempio

[ValidateInput(false)]
public ActionMethod Edit(int id, string value)
{
    // Do your own checking of value since it could contain XSS stuff!
    return View();
}

— Tom Chantler
fonte

1

@RossCooper questo è solo per asp.net MVC

— mxmissile

28

Funziona senza cambiare la modalità di validazione.

Devi usare un System.Web.Helpers.Validation.Unvalidatedaiuto da System.Web.WebPages.dll. Restituirà un UnvalidatedRequestValuesoggetto che consente di accedere al modulo e a QueryString senza convalida.

Per esempio,

var queryValue = Server.UrlDecode(Request.Unvalidated("MyQueryKey"));

Funziona per me per MVC3 e .NET 4.

— Assassino
fonte

1

Potete per favore fornire un esempio di come recuperare una queryString con questo metodo? Continuo a ricevere "Non convalidato non è un membro di ..." a tutti gli oggetti a cui provo ad aggiungerlo. Penso che potrei mancare un include

— CodedMonkey

3

var queryValue = Server.UrlDecode (Request.Unvalidated ("MyQueryKey"));

— sfuqua,

1

Questa sicuramente dovrebbe essere la risposta accettata. Mantiene la sicurezza ed è estremamente flessibile poiché è possibile utilizzarlo su base selettiva.

— cmartin,

Per i moduli Web è necessario sostituire la voce nella raccolta QueryString per evitare errori di convalida; vedere Un valore Request.QueryString potenzialmente pericoloso è stato rilevato dal client durante l'invio del markup html dalla chiamata jquery alla pagina asp.net

— Michael Freidgeim

15

Si noti che un altro approccio è mantenere il comportamento di convalida 4.0, ma definire la propria classe che deriva RequestValidatore imposta:

<httpRuntime requestValidationType="YourNamespace.YourValidator" />

(dove YourNamespace.YourValidatorva bene, dovresti essere in grado di indovinare ...)

In questo modo si mantengono i vantaggi del comportamento 4.0s (in particolare, che la convalida avviene prima nell'elaborazione), consentendo anche le richieste che è necessario far passare, attraverso.

— Jon Hanna
fonte

7

Questo è buono a sapersi. Ma penso ancora che l'intera funzionalità di convalida della richiesta di ASP.Net sia errata. L'input stesso non è il problema, è quello che fai con esso. Può essere perfettamente valido accettare codice SQL, HTML o JavaScript come input per la tua app, a condizione che tu lo stia codificando / eseguendo l'escape correttamente prima di inviarlo o archiviarlo nel database.

— Jordan Rieger,

2

@JordanRieger Sono parzialmente d'accordo. OOTB, almeno ha il vantaggio di default per proteggere (non pensare alle cose e ottieni errori, piuttosto che 0wned), ma è un po 'fastidioso e il comportamento pre-4.0 è quasi tutto o niente. C'è qualcosa nella capacità di avere un livello di convalida che viene utilizzato prima di qualsiasi altra elaborazione, come con un requestValidationType personalizzato, ma molta convalida deve essere più legata ad altre elaborazioni. In tutto, penso che faccia di più per proteggere le persone con cattive abitudini da alcuni (ma non tutti) spl0its che per incoraggiare le buone abitudini.

— Jon Hanna,