Eliminación de cadenas de consulta maliciosas ASP.Net MVC5

Question

Eliminación de cadenas de consulta maliciosas ASP.Net MVC5

#1 de SilverlightFox (1 votos)
#2 de AminSaghi (0 votos)

0

Mi aplicación web está construida con ASP.Net MVC5. Uno de los métodos acepta los parámetros de cadena de consulta. Las pruebas de seguridad han informado que acepta cadenas de consulta maliciosas y se muestra en el cuerpo sin ninguna modificación.

el paginador de MVCContrib para la paginación agrega la url, incluidos los parámetros de consulta, a la salida html.

descripción detallada a continuación

El nombre de un parámetro de URL suministrado arbitrariamente se copia en el valor de un atributo de etiqueta HTML que está encapsulado entre comillas dobles. La carga útil 7dc29"style="behavior:url(#default#time2)"onbegin="alert(1)"2d524 se envió con el nombre de un parámetro de URL suministrado arbitrariamente. Esta entrada se hizo eco sin modificaciones en la respuesta de la aplicación. Este ataque de prueba de concepto demuestra que es posible inyectar JavaScript arbitrario en la respuesta de la aplicación. El ataque de prueba de concepto demostrado utiliza una expresión evaluada dinámicamente con un atributo de estilo para introducir JavaScript arbitrario en el documento. Tenga en cuenta que esta técnica es específica de Internet Explorer y puede que no funcione en otros navegadores.

Tengo un filtro QueryString para buscar entradas de lista negra @"</?\w+((\s+\w+(\s*=\s*(?:"".*?""|'.*?'|[^'"">\s]+))?)+\s*|\s*)/?>", "<img", "<iframe", "\";", "¼script¾", "embed src"

también desinfecto el parámetro usando Microsoft.Security.Application.Sanitizer.GetSafeHtmlFragment()

Mi pregunta: ¿Es suficiente para asegurar el ataque XSS? ¿O cómo puedo eliminar la cadena de consulta maliciosa?

xss asp.net-mvc

pregunta Saanch 13.03.2014 - 15:47

fuente

2 respuestas

Lea otras preguntas en las etiquetas xss asp.net-mvc

¿Correo electrónico y envío de la lista de agujeros negros? [duplicar] ¿Qué mecanismo usó Flame para evitar ser identificado?

score 1 · Answer 1

No debe eliminar la cadena de consulta maliciosa, pero debe codificarla correctamente cuando se imprima en la página. Las listas negras rara vez son el camino a seguir en seguridad, ya que las cosas siempre están cambiando y siempre habrá una nueva forma de descubrir la lista negra.

Por ejemplo, si la salida de un valor no confiable a HTML debe estar codificada en HTML ( " se convierte en " ) o si la salida a JavaScript debe ser una entidad hexadecimal codificada ( " se convierte en \x22 ). Al no confiar, lea el valor de cualquier en el que no pueda garantizar la fuente (esto significa cadenas de consulta, valores de formulario, encabezados o incluso datos de su base de datos que podría pensar que son "seguros", pero un valor es solo seguro cuando se ve en el contexto de su salida).

Revise la OWASP XSS Prevention Cheat Sheet para obtener más detalles sobre cómo codificar apropiadamente por salida contexto.

score 0 · Answer 2

No use ningún filtro autoimplantado, ¡la rueda ya está inventada ...!

Los filtros como lo que escribiste tienen varios problemas ocultos, como el caso de los personajes. Además, el enfoque de la Lista Blanca siempre es más preferido que el enfoque de la Lista Negra

Usa la biblioteca AntiXSS . Ahora está integrado en .NET 4.5, pero no confíe en eso. Actualice el paquete a través de nuget porque las versiones anteriores de AntiXSS se pueden omitir ...! Vea lo siguiente para saber cómo puede ser ...

enlace

Después de eso, todo lo que necesitas hacer es el siguiente comando:

Sanitizer.GetSafeHtmlFragment(suspiciousCode);

Y es suficiente para eliminar todas las etiquetas y obtener un texto limpio ...