2011-12-02 13 views
5

he implementado un Request.QueryString["somestr"].ToString();Proteger mi ser de cross-site scripting

que suprimir este tipo de ataque haciendo HttpUtility.HtmlEncode(Request.QueryString["somestr"].ToString();

todavía tengo un problema por el que un usuario puede hacer:

myfriendlydomain.com /? somestr = '; alerta (WOO XSS SUCCEDED); test ='

¿Cómo puedo evitar que esto suceda?

conforme a lo solicitado:

//Code Behind 
if(request.querystring["somestr"] != null) 
{ 
    AffiliatesEmail = HttpUtility.HtmlEncode(Request.QueryString["somestr"].ToString();  
} 

//Front End 
<script type="text/javascript"> 
    //<![CDATA[ 
    /*** Do not change ***/ 
    var SomeVAR = {}; 
    SomeVAR.Tracking.Sale.orderRef = '<%= AffiliatesEmail %>'; 
    //]]> 
</script> 

<script src="https://www.somethirdparty.com/somejscript.js" type="text/javascript" defer="defer"> </script> 

Ésta es nuestra aplicación. Cualquier cosa posterior que no creo es relevante.

+0

La información pertinente aquí es _cómo_ la inyección aún puede tener éxito; debe escribirla en alguna parte de la página, porque simplemente agregarla a la cadena de consulta no es suficiente para que funcione. Háganos saber lo que hace con 'Request.QueryString [" somestr "]. ToString();' – Widor

+0

información adicional. – Anicho

+0

Pero todavía no podemos decir dónde termina esta cadena. ¿Qué es 'AffiliatesEmail'? ¿A dónde va su contenido para habilitar un ataque XSS? – Widor

Respuesta

2

Puede usar el JavaScriptStringEncode() Method para borrar la cadena y codificarla para evitar que esto suceda.

Otra forma es utilizar la biblioteca AntiXSS.

+0

JavaScriptStringEncode() El método es una función de .NET Framework .4.0 aún estamos en .NET Framework 3.5 hasta nuevo aviso. – Anicho

+1

AntiXSS también funciona para .NET 3.5 – Erlend

+0

Sí, es tu derecho, la otra solución es más rápida de implementar, estoy limitado por el tiempo, no debería decir que parezco un atajo. – Anicho

0

Necesita validar cada entrada de la cadena de consulta para asegurarse de tener datos válidos entrando. Tampoco escribiría el valor directamente en una página.

+0

Validar como bajo control no es algo que no debería ser. Entonces, si solo debería ser aaa, bbb, ccc, luego verifique si es así, entonces rechace. – Anicho

+0

Correcto - en este caso, probablemente vaya con una expresión regular para asegurarme de que recibas un correo electrónico. De lo contrario, rechaza los datos. – Tim

+0

Esto es realmente difícil de hacer bien. La entrada puede contener un ataque y aún así ser una dirección de correo electrónico válida. – Erlend

1

Al conocer el contexto en el que está utilizando la cadena AffiliatesEmail, es útil saber cuán exhaustivo debe ser para validar y desinfectar la cadena.

Digamos, por ejemplo, que sabemos que AffiliatesEmail solo era válido si era numérico. De esta forma, estarás protegido si rechazaste cualquier Request.QueryString["somestr"] que no valide como número.

Ahora, sospecho que AffiliatesEmail se supone que es una dirección de correo electrónico válida.

Usando este conocimiento, ahora podemos validarlo como una dirección de correo electrónico y rechazar todo lo demás:

using System.Net.Mail; 
try 
{  
    MailAddress ma = new MailAddress(AffiliatesEmail); 
} 
catch (FormatException fe) 
{ 
    //Email isn't valid, so don't output it to the client!!! 
} 

El código anterior simplemente valida si la cadena es una dirección de correo electrónico (según la definición de .NET) - si no lo es, entonces no tenemos que preocuparnos por lo que es, porque simplemente no confiamos en él.

Así que no se obsesione demasiado con la santificación de todo lo que se pone en la cadena de consulta, simplemente conociendo los límites de lo que es aceptable, puede evitar expresiones regulares complejas y rutinas de limpieza XSS.

+0

Gracias por simplificarlo y explicarlo así. – Anicho

+0

Las respuestas de Shark y Widor son relevantes. Usé este. – Anicho

+1

Wow. La validación de entrada NO es la solución correcta aquí. Consulte la lista de cartas válidas en las direcciones de correo electrónico aquí: http://en.wikipedia.org/wiki/Email_address ¿Qué sucede si el atacante ingresa la dirección de correo electrónico: joe '+ alert (xss) +' @ evil.com – Erlend