¿La codificación HTML evita los ataques de seguridad XSS?

Question

convirtiendo simplemente los siguientes ("The Big 5"): ataques

& -> & 
< -> &lt; 
> -> &gt; 
" -> &#034; 
' -> &#039; 

Va a evitar XSS?

Creo que también necesita una lista blanca a nivel de caracteres, para evitar certain attacks, pero el following answer indica que complica mucho las cosas.

EDITAR Este page detalles it does not prevent more elaborate injections, does not help with "out of range characters = question marks" when outputting Strings to Writers with single byte encodings, nor prevents character reinterpretation when user switches browser encoding over displayed page. En esencia acaba de escapar de estos personajes parece ser un enfoque bastante ingenua.

Answer 1

¿Va a prevenir los ataques XSS?

Si esta escapando en el momento adecuado (*) entonces sí, usted evitará que HTML-inyección. Esta es la forma más común de ataque XSS. No se trata solo de una cuestión de seguridad, debe hacer los escapes de todos modos para que las cadenas con esos caracteres se muestren correctamente de todos modos. El tema de la seguridad es un subconjunto del problema de la corrección.

Creo que se necesita a la lista blanca a un nivel de personaje también, para evitar ciertos ataques

Nº HTML-escape hará que cada uno de esos ataques como texto plano inactivo en la página, la cual es lo que quieres El rango de ataques en esa página está demostrando diferentes formas de hacer inyección de HTML, que puede evitar los "filtros XSS" más estúpidos que algunos servidores implementan para tratar de evitar los ataques comunes de inyección de HTML. Esto demuestra que los "filtros XSS" son inherentemente agujereados e ineficaces.

Existen otras formas de ataque XSS que podrían afectarlo o no, por ejemplo, esquemas incorrectos en URIs enviados por el usuario (javascript: y otros), inyección de código en datos repetidos en un bloque JavaScript (donde necesita JSON- estilo de escape) o en hojas de estilo o encabezados de respuesta HTTP (una vez más, siempre necesita la forma apropiada de codificación al colocar texto en otro contexto, siempre debe sospechar si ve algo con interpolación sin escapular como PHP "string $var string").

Luego está el manejo de carga de archivos, la política de origen de Flash, las secuencias UTF-8 demasiado largas en navegadores heredados y los problemas de generación de contenido a nivel de aplicación; todos estos pueden conducir potencialmente a scripts entre sitios. Pero la inyección de HTML es la principal que enfrentará cada aplicación web, y la mayoría de las aplicaciones PHP se equivocan hoy.

(*: que es cuando se inserta contenido de texto en HTML, y en ningún otro momento. No escanee HTML los datos de envío de formularios en $_POST/$_GET al inicio de la secuencia de comandos; este es un error común equivocado.)

Answer 2

Las medidas del contador dependen del contexto donde se insertan los datos. Si inserta los datos en HTML, reemplazar el meta carácter HTML con secuencias de escape (es decir, referencias de caracteres) impide insertar código HTML.

Pero si estás en otro contexto (por ejemplo, el valor del atributo HTML que se interpreta como URL) tienes metacaracteres adicionales con diferentes secuencias de escape con las que tienes que lidiar.

Answer 3

OWASP tiene una gran hoja de trucos.

1. Reglas de oro
2. Estrategias
3. Etc.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet