Se detectó un valor Request.Form potencialmente peligroso del cliente

Cada vez que un usuario publica algo que contiene <o está >en una página de mi aplicación web, recibo esta excepción.

No quiero entrar en la discusión sobre la inteligencia de lanzar una excepción o bloquear una aplicación web completa porque alguien ingresó un carácter en un cuadro de texto, pero estoy buscando una forma elegante de manejar esto.

Atrapando la excepción y mostrando

Se ha producido un error, regrese y vuelva a escribir todo el formulario nuevamente, pero esta vez no use <

No me parece lo suficientemente profesional.

Deshabilitar la validación posterior ( validateRequest="false") definitivamente evitará este error, pero dejará la página vulnerable a una serie de ataques.

Idealmente: cuando se produce una devolución que contiene caracteres restringidos en HTML, ese valor publicado en la colección de formularios se codificará automáticamente en HTML. Entonces la .Textpropiedad de mi cuadro de texto serásomething & lt; html & gt;

¿Hay alguna manera de hacer esto desde un controlador?

Creo que lo estás atacando desde el ángulo equivocado al tratar de codificar todos los datos publicados.

Tenga en cuenta que un " <" también podría provenir de otras fuentes externas, como un campo de base de datos, una configuración, un archivo, un feed, etc.

Además, " <" no es inherentemente peligroso. Solo es peligroso en un contexto específico: al escribir cadenas que no se han codificado en la salida HTML (debido a XSS).

En otros contextos, las diferentes subcadenas son peligrosas, por ejemplo, si escribe una URL proporcionada por el usuario en un enlace, la subcadena " javascript:" puede ser peligrosa. El carácter de comillas simples, por otro lado, es peligroso al interpolar cadenas en consultas SQL, pero es perfectamente seguro si es parte de un nombre enviado desde un formulario o leído desde un campo de base de datos.

La conclusión es: no puede filtrar la entrada aleatoria de caracteres peligrosos, porque cualquier carácter puede ser peligroso en las circunstancias correctas. Debe codificar en el punto donde algunos caracteres específicos pueden volverse peligrosos porque se cruzan a un sub-idioma diferente donde tienen un significado especial. Cuando escribe una cadena en HTML, debe codificar caracteres que tengan un significado especial en HTML, utilizando Server.HtmlEncode. Si pasa una cadena a una declaración SQL dinámica, debe codificar diferentes caracteres (o mejor, deje que el marco lo haga por usted usando declaraciones preparadas o similares).

Cuando esté seguro de que codifica HTML en todas partes donde pasa cadenas a HTML, luego establezca validateRequest="false"la <%@ Page ... %>directiva en su .aspx(s) archivo (s).

En .NET 4 puede que tenga que hacer un poco más. A veces es necesario agregar también <httpRuntime requestValidationMode="2.0" />a web.config ( referencia ).

Hay una solución diferente a este error si está utilizando ASP.NET MVC:

• ASP.NET MVC - páginas validateRequest = false ¿no funciona?
• ¿Por qué ValidateInput (False) no funciona?
• ASP.NET MVC RC1, VALIDATEINPUT, UNA SOLICITUD PELIGROSA PELIGROSA Y EL PITFALL

Muestra de C #:

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

Muestra de Visual Basic:

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

En ASP.NET MVC (a partir de la versión 3), puede agregar el AllowHtmlatributo a una propiedad en su modelo.

Permite que una solicitud incluya un marcado HTML durante el enlace del modelo omitiendo la validación de solicitud para la propiedad.

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

Si está en .NET 4.0, asegúrese de agregar esto en su archivo web.config dentro de las <system.web>etiquetas:

<httpRuntime requestValidationMode="2.0" />

En .NET 2.0, la validación de solicitud solo se aplica a las aspxsolicitudes. En .NET 4.0 esto se expandió para incluir todas las solicitudes. Puede volver a realizar solo la validación XSS al procesar .aspxespecificando:

requestValidationMode="2.0"

Puede deshabilitar la validación completa de la solicitud especificando:

validateRequest="false"

Para ASP.NET 4.0, puede permitir el marcado como entrada para páginas específicas en lugar de todo el sitio al ponerlo todo en un <location>elemento. Esto asegurará que todas tus otras páginas estén seguras. NO necesita poner ValidateRequest="false"en su página .aspx.

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

Es más seguro controlar esto dentro de su web.config, porque puede ver a nivel de sitio qué páginas permiten el marcado como entrada.

Aún necesita validar mediante programación la entrada en páginas donde la validación de solicitud está deshabilitada.

Las respuestas anteriores son geniales, pero nadie dijo cómo excluir un solo campo de ser validado para inyecciones HTML / JavaScript. No sé sobre versiones anteriores, pero en MVC3 Beta puedes hacer esto:

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

Esto todavía valida todos los campos excepto el excluido. Lo bueno de esto es que sus atributos de validación aún validan el campo, pero simplemente no obtiene las excepciones "Se detectó un valor de Solicitud potencialmente peligroso.

Lo he usado para validar una expresión regular. He creado mi propio ValidationAttribute para ver si la expresión regular es válida o no. Como las expresiones regulares pueden contener algo que se parece a un script, apliqué el código anterior: la expresión regular todavía se está verificando si es válida o no, pero no si contiene scripts o HTML.

En ASP.NET MVC, debe establecer requestValidationMode = "2.0" y validateRequest = "false" en web.config, y aplicar un atributo ValidateInput a la acción de su controlador:

<httpRuntime requestValidationMode="2.0"/>

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

y

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

Puede codificar HTML en el contenido del cuadro de texto, pero desafortunadamente eso no detendrá la excepción. En mi experiencia, no hay forma de evitarlo, y debe deshabilitar la validación de la página. Al hacerlo, estás diciendo: "Tendré cuidado, lo prometo".

Para MVC, ignore la validación de entrada agregando

[ValidateInput (falso)]

sobre cada acción en el controlador.

Puede detectar ese error en Global.asax. Todavía quiero validar, pero mostrar un mensaje apropiado. En el blog que figura a continuación, una muestra como esta estaba disponible.

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

Redirigir a otra página también parece una respuesta razonable a la excepción.

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

La respuesta a esta pregunta es simple:

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

Esto deshabilitaría la validación para la solicitud particular.

Tenga en cuenta que algunos controles .NET codificarán automáticamente la salida HTML. Por ejemplo, establecer la propiedad .Text en un control TextBox la codificará automáticamente. Eso significa específicamente convertir <en <, >en >y &en &. Así que ten cuidado de hacer esto ...

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

Sin embargo, la propiedad .Text para HyperLink, Literal y Label no codificará HTML, por lo que envolverá Server.HtmlEncode (); todo lo que se establece en estas propiedades es imprescindible si desea evitar que <script> window.location = "http://www.google.com"; </script>se imprima en su página y se ejecute posteriormente.

Experimente un poco para ver qué se codifica y qué no.

En el archivo web.config, dentro de las etiquetas, inserte el elemento httpRuntime con el atributo requestValidationMode = "2.0". Agregue también el atributo validateRequest = "false" en el elemento de páginas.

Ejemplo:

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

Si no desea deshabilitar ValidateRequest, debe implementar una función de JavaScript para evitar la excepción. No es la mejor opción, pero funciona.

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

Luego, en el código detrás, en el evento PageLoad, agregue el atributo a su control con el siguiente código:

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

Parece que nadie ha mencionado lo siguiente todavía, pero me soluciona el problema. Y antes de que alguien diga que sí, es Visual Basic ... qué asco.

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

No sé si hay inconvenientes, pero para mí esto funcionó increíble.

Otra solución es:

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

Si está utilizando Framework 4.0, la entrada en web.config (<páginas validateRequest = "false" />)

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

Si está utilizando Framework 4.5, entonces la entrada en web.config (requestValidationMode = "2.0")

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

Si solo desea una sola página, en su archivo aspx debe poner la primera línea como esta:

<%@ Page EnableEventValidation="false" %>

si ya tiene algo como <% @ Page, simplemente agregue el resto => EnableEventValidation="false"%>

Recomiendo no hacerlo.

En ASP.NET, puede detectar la excepción y hacer algo al respecto, como mostrar un mensaje amigable o redirigir a otra página ... También existe la posibilidad de que pueda manejar la validación usted mismo ...

Mostrar mensaje amigable:

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

Supongo que podrías hacerlo en un módulo; pero eso deja abiertas algunas preguntas; ¿Qué pasa si desea guardar la entrada en una base de datos? De repente, debido a que está guardando datos codificados en la base de datos, termina confiando en la entrada, lo que probablemente sea una mala idea. Lo ideal es que almacene datos sin codificar sin procesar en la base de datos y la codificación cada vez.

Deshabilitar la protección en un nivel por página y luego codificar cada vez es una mejor opción.

En lugar de usar Server.HtmlEncode, debería mirar la biblioteca Anti-XSS más nueva y más completa del equipo de Microsoft ACE.

Porque

ASP.NET por defecto valida todos los controles de entrada para contenido potencialmente inseguro que puede conducir a secuencias de comandos entre sitios (XSS) e inyecciones SQL . Por lo tanto, no permite dicho contenido lanzando la excepción anterior. Por defecto, se recomienda permitir que esta verificación se realice en cada devolución de datos.

Solución

En muchas ocasiones, debe enviar contenido HTML a su página a través de Rich TextBoxes o Rich Text Editors. En ese caso, puede evitar esta excepción estableciendo la etiqueta ValidateRequest en la @Pagedirectiva en false.

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

Esto deshabilitará la validación de solicitudes para la página en la que ha establecido el indicador ValidateRequest en falso. Si desea desactivar esto, verifique en toda su aplicación web; deberá configurarlo como falso en su sección web.config <system.web>

<pages validateRequest ="false" />

Para marcos .NET 4.0 o superior, también deberá agregar la siguiente línea en la sección <system.web> para que funcione lo anterior.

<httpRuntime requestValidationMode = "2.0" />

Eso es. Espero que esto te ayude a deshacerte del problema anterior.

Referencia por: ASP.Net Error: Se detectó un valor de Request.Form potencialmente peligroso desde el cliente

Encontré una solución que usa JavaScript para codificar los datos, que se decodifica en .NET (y no requiere jQuery).

• Convierta el cuadro de texto en un elemento HTML (como textarea) en lugar de uno ASP.
• Agrega un campo oculto.

• Agregue la siguiente función de JavaScript a su encabezado.

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

En su área de texto, incluya un onchange que llame a boo ():

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

Finalmente, en .NET, use

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

Soy consciente de que esto es unidireccional: si necesita dos vías, tendrá que ser creativo, pero esto proporciona una solución si no puede editar la web.config

Aquí hay un ejemplo que se me ocurrió (MC9000) y uso a través de 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
    });


});

Y el marcado:

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

Esto funciona muy bien. Si un pirata informático intenta publicar sin saltarse JavaScript, solo verá el error. También puede guardar todos estos datos codificados en una base de datos, luego dejarlos de lado (en el lado del servidor) y analizar y verificar si hay ataques antes de mostrarlos en otro lugar.

Las otras soluciones aquí son buenas, sin embargo, es un poco difícil en la parte trasera tener que aplicar [AllowHtml] a cada propiedad de Modelo, especialmente si tiene más de 100 modelos en un sitio de tamaño decente.

Si, como yo, desea desactivar esta función (en mi humilde opinión, bastante inútil) en todo el sitio, puede anular el método Execute () en su controlador base (si aún no tiene un controlador base, le sugiero que cree uno, pueden ser bastante útil para aplicar funcionalidad común).

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

Solo asegúrese de que está codificando HTML todo lo que se bombea a las vistas que provienen de la entrada del usuario (de todos modos, es un comportamiento predeterminado en ASP.NET MVC 3 con Razor, por lo que a menos que por alguna extraña razón esté usando Html.Raw () usted No debería requerir esta función.

También recibí este error.

En mi caso, un usuario ingresó un carácter acentuado áen un Nombre de rol (con respecto al proveedor de membresía ASP.NET).

Paso el nombre del rol a un método para otorgar a los Usuarios a ese rol y la $.ajaxsolicitud de publicación fallaba miserablemente ...

Hice esto para resolver el problema:

En vez de

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

Hacer esto

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

@Html.Raw Hizo el truco.

Estaba obteniendo el nombre del rol como valor HTML roleName="Cadastro bás". áASP.NET MVC estaba bloqueando este valor con la entidad HTML . Ahora obtengo el roleNamevalor del parámetro como debería ser: roleName="Cadastro Básico"y el motor ASP.NET MVC ya no bloqueará la solicitud.

Desactivar la validación de la página si realmente necesita los caracteres especiales como, >,, <, etc A continuación, asegúrese de que cuando se muestra la entrada del usuario, los datos son codificados en HTML.

Existe una vulnerabilidad de seguridad con la validación de la página, por lo que se puede omitir. Además, no se debe confiar únicamente en la validación de la página.

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

También puede usar la función de escape (cadena) de JavaScript para reemplazar los caracteres especiales. Luego, del lado del servidor, use el servidor. URLDecode (cadena) para volver a cambiarlo.

De esta manera, no tiene que desactivar la validación de entrada y será más claro para otros programadores que la cadena puede tener contenido HTML.

Terminé usando JavaScript antes de cada devolución de datos para verificar los caracteres que no deseaba, como:

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

De acuerdo, mi página es principalmente entrada de datos, y hay muy pocos elementos que realicen devoluciones, pero al menos se conservan sus datos.

Puedes usar algo como:

var nvc = Request.Unvalidated().Form;

Más tarde, nvc["yourKey"]debería funcionar.

Siempre que estos sean solo caracteres "<" y ">" (y no la comilla doble) y los esté utilizando en contexto como <input value = " this " />, estará a salvo (mientras que para <textarea > este </textarea> sería vulnerable, por supuesto). Eso puede simplificar su situación, pero para cualquier otra cosa use una de las otras soluciones publicadas.

Si solo desea decirles a sus usuarios que <y> no se deben usar PERO, no desea que se procese / regrese todo el formulario (y pierda toda la información) de antemano, ¿no podría simplemente ingresar un validador alrededor del campo para detectar esos (y tal vez otros personajes potencialmente peligrosos)?

Ninguna de las sugerencias funcionó para mí. De todos modos, no quería desactivar esta función para todo el sitio web porque el 99% del tiempo no quiero que mis usuarios coloquen HTML en formularios web. Acabo de crear mi propio método de trabajo ya que soy el único que usa esta aplicación en particular. Convierto la entrada a HTML en el código detrás y la inserto en mi base de datos.