Si la Validación de solicitud de ASP.NET está habilitada para un sitio, ¿aún necesita la información de cadena HtmlEncode y HtmlDecode hacia y desde formularios simples (por ejemplo, cuadros de texto ASP)?¿Es necesario codificar en HtmlEncode los valores del cuadro de texto si está habilitada la validación de solicitudes ASP .Net?
Si ASP.NET solicitud de validación está habilitada para un sitio, ¿todavía necesita HtmlEncode
ASP.NET solicitud de validación es un truco para tratar de evitar los programas rotos estúpidos autores. No escriba programas rotos.
Cualquier cadena de texto que escriba en una página HTML debe estar codificada en HTML; esto es una cuestión de corrección, no solo de seguridad (que es un subconjunto de la corrección). Incluso si Request Validation pudiera eliminar mágicamente cualquier posible ataque XSS (y eso es así que no se parece en nada al caso), si falla la salida de texto HtmlEncode aún lo dejará abierto para producir resultados incorrectos, destruyendo sus datos.Digamos que yo estaba haciendo un post en el foro hablando de algunas variables a, y bc y quería decir:
a<b b>c b>a
Si que se hizo eco de la fuente HTML sin codificar, me gustaría obtener:
una cb> a
y tal vez el resto de la página sería demasiado audaz. ¡Ups!
La validación de solicitud es falsa y no se debe confiar en ella. Estar preconfigurado y "recomendado para todos los entornos de producción" es triste y me hace dudar seriamente de la sensatez del equipo de ASP.NET.
Si ha escrito su programa correctamente, no lo necesita y se interpondrá en su camino. (Por ejemplo, si SO lo usara, no podría hacer esta publicación que menciona la etiqueta <script>). Si no ha escrito su programa correctamente, Solicitar validación no solucionará sus agujeros de seguridad, es solo va a hacerlos un poco más oscuros.
y la cadena HtmlDecode información
por lo general no HtmlDecode cualquier cosa en una aplicación web. Usted codifica para enviar contenido a HTML, pero cuando el contenido vuelve desde un formulario enviado es como texto sin formato, no codificado en HTML.
ay desde formularios simples (por ejemplo, cuadros de texto ASP)?
Los cuadros de texto deberían estar bien; estableciendo su .Text hace cualquier codificación necesaria, haciendo que la cadena exacta haya aparecido en el cuadro de texto. Pero. Algunas cosas que parecen que deberían ser HTML-encoding en realidad no lo hacen. Por ejemplo:
myTextBox.Text= "a<b b>c"; // Fine!
myLabel.Text= "a<b b>c"; // Broken!
Oh querido. Text no siempre significa Texto. Sometimes, it actually means HTML. Gracias Microsoft, forma de enturbiar las aguas de un tema que muchas personas ya encuentran difícil de entender.
El texto de los cuadros de texto ASP.NET no presenta ningún peligro, ya sea que la Validación de solicitud esté activada o desactivada. El control de cuadro de texto codifica automáticamente los datos cuando se muestran en el cuadro de texto.
Al generar datos que se originaron del usuario en otros lugares, es importante que HTML (o JavaScript) codifique esos datos. La Validación de solicitudes de ASP.NET proporciona solo un nivel mínimo de protección. No es impenetrable, ni siquiera cerca de ella. Está diseñado solo para proteger contra los ataques más simples.
Todavía tiene que codificar cosas a medida que las saca en otras partes de su sitio.
Editar
Lo que quiero decir por otros lugares, es que si el usuario introduce los datos en un cuadro de texto, utilizando el control de cuadro de texto ASP.NET es seguro porque el control codifica automáticamente la salida por lo que hará que sin peligro.
Digamos, por ejemplo, que está trabajando con la página de información de usuario de StackOverflow. Cuando un usuario elige su nombre de usuario, puede optar por ingresar algo que puede ser malicioso cuando sale en otra parte de su sitio. Por ejemplo, mi nombre de inicio de sesión de StackOverflow se muestra en la parte superior de cada página para mí, y también aparece en la página "Usuarios".
En la página Usuarios, AJAX se utiliza para cargar usuarios. Cuando JavaScript evalúa el nombre de usuario, no está sujeto a las mismas reglas de codificación que las etiquetas HTML, por lo que podría escribir algo en el cuadro de texto del nombre de usuario que podría causar cierto comportamiento de interrupción cuando se muestre en la lista de usuarios.
StackOverflow obviamente codifica datos de usuario correctamente cuando se envían al cliente, por lo que son seguros. Antes de enviar mi nombre de usuario al cliente, (presumiblemente) tienen alguna rutina de codificación JavaScript que asegura que mi nombre de usuario no se vuelva malicioso cuando se ejecute en código JavaScript.
También podría tener problemas si lo usa en un control de entrada que no sea ASP.NET. Las etiquetas de entrada usan atributos para definir el contenido, por lo que puede ingresar fácilmente texto que supere la comprobación de validación de solicitud, pero podría permitir al usuario agregar un atributo malicioso de "mouseover".
¿Qué quieres decir con otros lugares? Botones, opciones, enlaces? – Steve