¿La codificación HTML evitará todo tipo de ataques XSS?

Si codifica sistemáticamente toda la entrada del usuario antes de mostrar entonces sí, está seguro todavía no está 100% seguro.
(Ver el post de @Avid para más detalles)

Además, surgen problemas cuando necesita dejar que algunas etiquetas no estén codificadas para permitir que los usuarios publiquen imágenes o texto en negrita o cualquier característica que requiera la entrada del usuario se procese como (o se convierta a) marcado no codificado.

Tendrá que configurar un sistema de toma de decisiones para decidir qué etiquetas son permitidos y que no lo son, y siempre es posible que alguien encuentre una manera de dejar pasar una etiqueta no permitida.

Ayuda si sigues el consejo de Joel de Hacer que el Código Incorrecto Parezca Incorrecto o si tu lenguaje te ayuda advirtiendo/no compilando cuando estás emitiendo datos de usuario no procesados (escritura estática).

Si codificas todo, lo hará. (dependiendo de su plataforma y la implementación de htmlencode) Pero cualquier aplicación web útil es tan compleja que es fácil olvidarse de revisar cada parte de ella. O tal vez un componente de tercera parte no es seguro. O tal vez alguna ruta de código que aunque hizo codificación no lo hizo por lo que se olvidó en otro lugar.

Así que es posible que desee comprobar las cosas en el lado de entrada también. Y es posible que desee comprobar las cosas que lee de la base de datos.

Como han mencionado todos los demás, estás a salvo siempre y cuando codifiques toda la entrada del usuario antes de mostrarla. Esto incluye todos los parámetros de solicitud y los datos recuperados de la base de datos que se pueden cambiar mediante la entrada del usuario.

Como mencionado por Pat a veces querrás mostrar algunas etiquetas, pero no todas. Una forma común de hacer esto es usar un lenguaje de marcado como Textile, Markdown , o BBCode. Sin embargo, incluso los lenguajes de marcado pueden ser vulnerable a XSS, solo ten cuidado.

# Markup example
[foo](javascript:alert\('bar'\);)

Si decide dejar pasar las etiquetas "seguras", le recomendaría encontrar alguna biblioteca existente para analizar y desinfectar su código antes de la salida. Hay muchos vectores XSS que tendría que detectar antes de que su desinfectante sea bastante seguro.

Secundo el consejo de metavida para encontrar una biblioteca de terceros para manejar el filtrado de salida. Neutralizar caracteres HTML es un buen enfoque para detener ataques XSS. Sin embargo, el código que usa para transformar metacaracteres puede ser vulnerable a ataques de evasión; por ejemplo, si no maneja adecuadamente Unicode e internacionalización.

Un error clásico simple que hacen los filtros de salida de homebrew es atrapar solo , pero perder cosas como", que puede romper la salida controlada por el usuario en el espacio de atributos de una etiqueta HTML, donde Javascript se puede adjuntar al DOM.

No, simplemente codificar tokens HTML comunes NO protege completamente su sitio de ataques XSS. Ver, por ejemplo, esta vulnerabilidad XSS se encuentra en google.com:

Http://www.securiteam.com/securitynews/6Z00L0AEUE.html

Lo importante de este tipo de vulnerabilidad es que el atacante es capaz de codificar su carga útil XSS usando UTF-7, y si no ha especificado una codificación de caracteres diferente en su página, el navegador de un usuario podría interpretar la carga útil UTF-7 y ejecuta el script de ataque.

Otra cosa que debe verificar es de dónde proviene su entrada. Puede utilizar la cadena de referencia (la mayoría de las veces) para comprobar que es de su propia página, pero poner un número aleatorio oculto o algo en su formulario y luego comprobarlo (con una variable de sesión establecida tal vez) también ayuda a saber que la entrada proviene de su propio sitio y no de algún sitio de phishing.

Me gustaría sugerir HTML Purifier (http://htmlpurifier.org/) no acaba de filtrar el html, que básicamente se acorta y re-compilación. Es verdaderamente industrial-fuerza.

Tiene la ventaja adicional de permitirle asegurar una salida html/xhtml válida.

También n'thing textile, es una gran herramienta y la uso todo el tiempo, pero también la ejecutaría a través de html purifier.

No creo que entendiste lo que quise decir re tokens. HTML Purifier no solo 'filtro', en realidad reconstruye el html. http://htmlpurifier.org/comparison.html

No lo creo. Html Encode convierte todos los caracteres funcionales (caracteres que podrían ser interpretados por el navegador como código) en referencias de entidades que no pueden ser analizadas por el navegador y, por lo tanto, no pueden ser ejecutadas.

<script/>

No hay forma de que el navegador pueda ejecutar lo anterior.

**A menos que sea un error en el navegador, por supuesto.*