codificación HTML para proteger contra XSS

(Copiado de mi respuesta en StackOverflow )

No.
HtmlEncode simplemente NO cubre todos los ataques XSS.
La codificación es la solución correcta, pero no siempre la codificación HTML: necesita codificación sensible al contexto .

Por ejemplo, considere javascript del lado del cliente generado por el servidor: el servidor emite dinámicamente valores htmlencoded directamente en el javascript del lado del cliente, htmlencode no detendrá la ejecución del script inyectado.

A continuación, considere el siguiente pseudocódigo:

<input value=<%= HtmlEncode(somevar) %> id=textbox>

Ahora, en caso de que no sea inmediatamente obvio, si somevar (enviado por el usuario, por supuesto) se configura, por ejemplo, para

a onclick=alert(document.cookie)

la salida resultante es

<input value=a onclick=alert(document.cookie) id=textbox>

que claramente funcionaría. Obviamente, esto puede ser (casi) cualquier otra secuencia de comandos ... y HtmlEncode no ayudaría mucho.

Se deben considerar algunos vectores adicionales ... incluyendo el tercer sabor de XSS, llamado XSS basado en DOM (donde el script malicioso se genera dinámicamente en el cliente, por ejemplo, basado en # valores).

Tampoco te olvides de los ataques de tipo UTF-7, donde se ve el ataque

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

No hay mucho que codificar allí ...

La solución, por supuesto (además de la validación de entrada de la lista blanca adecuada y restrictiva), es realizar una codificación sensible al contexto : la codificación Html es excelente SI su contexto de salida es HTML, o tal vez necesita JavaScriptEncoding, o VBScriptEncoding, o AttributeValueEncoding, o ... etc.

Si está utilizando MS ASP.NET, puede usar su biblioteca Anti-XSS, que proporciona todos los métodos de codificación de contexto necesarios.

Tenga en cuenta que toda la codificación no debe limitarse a la entrada del usuario, sino también a los valores almacenados de la base de datos, archivos de texto, etc.

Ah, y no te olvides de establecer explícitamente el conjunto de caracteres, tanto en el encabezado HTTP Y la etiqueta META, de lo contrario, todavía tendrás vulnerabilidades de UTF-7 ...

Último punto, en relación con el XSS almacenado: dado que estaría haciendo la codificación durante la generación de la página, en la salida de datos de los datos, es indiferente en cuanto a la fuente de los datos, ya sea de la entrada del usuario ( Es decir, XSS reflejado) o Base de datos / archivos (es decir, XSS almacenado / persistente). (Así que básicamente sí).

Para obtener más información y una lista bastante definitiva (que ya no está actualizada), consulte la Hoja de referencia de RSnake: enlace

Básicamente, XSS ocurre cuando un atacante ejecuta con éxito algún tipo de script no autorizado en una página web que ve una posible víctima. Por lo tanto, si HtmlEncode los campos antes de imprimir en la página web, la página no interpretará los datos como un script. Interpretará los caracteres como contenido y el contenido se imprimirá en la página tal como está.

por ejemplo: digamos que tienes algo como

<form action="/printname" >
  <input type="textbox" name="name">
  <input type="submit">
</form>

y en el lado del servidor tienes algo como

k=request.GET['name']
return HttpResponse("hai" + k)

si el usuario ingresa el nombre como

<script>alert("hia")</script>

la página ejecutaría el script en lugar de imprimirlo. Sin embargo, si suponemos que la función HttpResponse HTML codifica la salida antes de enviarla al cliente, < se reemplazará por < y > se reemplazará por > y las comillas dobles se reemplazarán por " .

El resultado sería la página que interpreta la salida como contenido en lugar de un script.

Espero que mi respuesta sea clara. Y ayuda a prevenir XSS almacenados, porque el valor almacenado se codifica antes de imprimir.