Después de ASP.NET 1.1, se introduce la capacidad de verificar automáticamente si hay XSS (ataque de secuencias de comandos entre sitios) para enviar formularios. Cuando el usuario intenta usar dicha entrada para afectar la página para devolver el resultado, el motor ASP.NET activará una HTTPRequestValidationException. Por defecto, se devolverá la página con el siguiente texto:
Esta es una función de seguridad muy importante proporcionada por ASP.NET. Debido a que muchos programadores no tienen idea de la seguridad, y ni siquiera conocen la existencia de ataques como XSS, incluso menos personas saben tomar la iniciativa para protegerlos. ASP.NET es seguro de forma predeterminada en este punto. Esto permite a los programadores que no saben mucho sobre la seguridad para que sigan escribiendo sitios web con ciertas capacidades de protección de seguridad.
Sin embargo, cuando busqué en Google la búsqueda de httprequestValidationException o una solicitud potencialmente peligrosa. El valor de forma se detectó del cliente, me sorprendió descubrir que la solución dada por la mayoría de las personas era deshabilitarlo estableciendo validateRequest = falso en la descripción de la página ASP.NET A esta característica no le importa si el sitio web del programador realmente no necesita esta característica. Estaba tan asustado por la vista. La conciencia de seguridad siempre debe estar en la mente de cada programador.
¿Por qué muchos programadores quieren prohibir ValidateRequest? No hay necesidad de decir esto. Otra parte no es realmente que el usuario permita la entrada de caracteres que causen fácilmente XSS, pero odia esta forma de informes de errores. no el usuario.
Para los programadores que desean manejar bien este mensaje de error sin usar el mensaje de error de excepción ASP.NET predeterminado, no deshabilite ValidateRequest = FALSE.
La forma correcta es agregar la función Page_error () a su página actual para atrapar todas las excepciones que ocurren durante el procesamiento de la página sin procesamiento. Luego dale al usuario un mensaje de error legal. Si la página actual no tiene Page_error (), esta excepción se enviará a la aplicación_error () de Global.asax para su procesamiento, y también puede escribir una función de manejo de errores de excepción general allí. Si no se escribe la función de manejo de excepciones en ambos lugares, se mostrará esta página de informe de error predeterminada.
Por ejemplo, solo se necesita un código muy corto para tratar esta excepción. Agregue este código a la página de código de código de la página:
| El siguiente es un fragmento citado: ProtectedVoidPage_Error (ObjectSender, EventArgse) { ExcepcionEx = server.getLasterRor (); if (exishttprequestValidationException) { Response.Write (Ingrese una cadena legal); Server.ClearError (); // Si ClearError () no es ClearError (), esta excepción continuará pasando a Application_Error (). } } |
De esta manera, este programa puede interceptar la excepción httprequestValidationException y puede devolver un mensaje de error razonable de acuerdo con los deseos del programador.
Este código es muy simple, por lo que espero que a todos los amigos que no sean realmente permitidos ingresar a personajes como los usuarios no prohíben esta función de seguridad a voluntad. . Poder.
Para los programadores que prohíben explícitamente esta característica, deben comprender lo que están haciendo y deben verificar manualmente las cadenas que deben filtrarse; de lo contrario, su sitio activará fácilmente los ataques de secuencia de comandos de sitios cruzados.
¿Cómo se deben manejar las páginas con el editor de texto rico?
Si la página tiene controles con editores de texto enriquecidos, inevitablemente conducirá a la presentación de etiquetas HTML de clase. En este caso, tenemos que validateRequest = false. Entonces, ¿cómo lidiar con la seguridad?
Según el consejo de Microsoft, debemos adoptar una política llamada política basada en seguridad y explícitamente permitida .
Primero, codificamos la cadena de entrada con httputility.htmlencode () y prohibimos completamente las etiquetas HTML en ella.
Luego, reemplazamos las etiquetas de seguridad en las que nos interesan y se reemplazan por reemplazo (). Por ejemplo, si queremos tener una etiqueta, la reemplazaremos explícitamente.
El código de muestra es el siguiente:
| El siguiente es un fragmento citado: VoidSubmitBtn_Click (ObjectSender, EventArgse) ... { // codificando la cadena de entrada, de modo que todas las etiquetas HTML no sean no válidas. StringBuildersB = NewstringBuilder ( Httputility.htmlencode (htmlinputtxt.text)); // Luego permitimos selectivamente <b> y <i> sb.replace (& lt; b & gt ;, <b>); sb.replace (& lt;/b & gt;,); sb.replace (& lt; i & gt;, <i>); sb.replace (& lt;/i & gt;,); Respuesta.write (sb.ToString ()); } |
De esta manera, permitimos algunas etiquetas HTML y prohibimos etiquetas peligrosas.
Según el consejo proporcionado por Microsoft, debemos permitir cuidadosamente las siguientes etiquetas HTML, porque estas etiquetas HTML pueden conducir a ataques de secuencias de comandos de sitios cruzados.
El siguiente es un fragmento citado:
|
Quizás lo más incomprensible aquí es <img>. Sin embargo, después de leer el siguiente código, debe comprender su peligro.
| El siguiente es un fragmento citado: <imgsrc = javaScript: alert ('hola');> <imgsrc = java 
 script: alert ('hello');> <imgsrc = java 
 script: alert ('hola');> |
Es posible causar la ejecución de JavaScript a través de la etiqueta <MG> para que el atacante pueda hacer lo que quiera disfrazar.
Lo mismo ocurre con <Syle>:
| El siguiente es un fragmento citado: <styletype = text/javascript> ... alerta ('hola'); </style> |
| El siguiente es un fragmento citado: Error del servidor en la aplicación '/YourApplicationPath' Una solicitud potencialmente peligrosa. Se detectó valor de forma del cliente (txtname = <b>). Descripción: La validación de la solicitud ha detectado un valor de entrada del cliente potencialmente peligroso, y el procesamiento de la solicitud ha sido abortado. Sin embargo, al establecer ValidateRequest = FALSO en la Directiva de página o en la Sección de Configuración. Detalles de la excepción: System.web.httprequestValidationException: se detectó una solicitud potencialmente peligrosa. Se detectó valor de forma del cliente (txtname = <b>). .... |