security - tipos - xss reflected

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

Apoyo el consejo de metavida de 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 utiliza para transformar metacaracteres puede ser vulnerable a los ataques de evasión; por ejemplo, si no maneja adecuadamente Unicode e internacionalización.

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

No me preocupan otros tipos de ataques. Solo quiero saber si HTML Encode puede prevenir todo tipo de ataques XSS.

¿Hay alguna forma de hacer un ataque XSS incluso si se usa HTML Encode?

Como lo mencionaron todos los demás, está seguro siempre que codifique toda la entrada del usuario antes de mostrarlo. Esto incluye todos los parámetros de solicitud y los datos recuperados de la base de datos que pueden ser modificados por la entrada del usuario.

Como menciona 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 vulnerables a XSS, solo tenga en cuenta.

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

Si decide dejar etiquetas "seguras", le recomendaría encontrar alguna biblioteca existente para analizar y desinfectar su código antes de la salida. Hay http://ha.ckers.org/xss.html por ahí que debería detectar antes de que su desinfectante sea bastante seguro.

Me gustaría sugerir HTML Purifier ( http://htmlpurifier.org/ ). No solo filtra el html, básicamente lo convierte en token y lo vuelve a compilar. Es verdaderamente de fuerza industrial.

Tiene el beneficio adicional de permitirle garantizar una salida html / xhtml válida.

También nada de textiles, es una gran herramienta y la utilizo todo el tiempo, pero también la utilicé como purificador de html.

No creo que hayas entendido lo que quise decir con los tokens. HTML Purifier no solo ''filtra'', realmente reconstruye el html. http://htmlpurifier.org/comparison.html

No, solo codificar tokens HTML comunes NO protege por completo su sitio de los ataques XSS. Consulte, por ejemplo, esta vulnerabilidad XSS que se encuentra en google.com:

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

Lo importante de este tipo de vulnerabilidad es que el atacante puede codificar su carga útil XSS utilizando 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 ejecutar el script de ataque

No.

Dejando de lado el tema de permitir algunas etiquetas (realmente no es el punto de la pregunta), HtmlEncode simplemente NO cubre todos los ataques XSS.

Por ejemplo, considere el JavaScript javascript generado por el servidor: el servidor genera 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 establece, por ejemplo, para

a onclick=alert(document.cookie)

el resultado resultante es

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

lo que claramente funcionaría. Obviamente, esto puede ser (casi) cualquier otro script ... y HtmlEncode no ayudaría mucho.

Hay algunos vectores adicionales a considerar ... incluido el tercer sabor de XSS, llamado XSS basado en DOM (en el que el script malicioso se genera dinámicamente en el cliente, por ejemplo, en base a # valores).

Además, no 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 adecuada y restrictiva de la lista blanca), es realizar codificación sensible al contexto : HtmlEncoding es excelente SI el contexto de salida es HTML, o tal vez necesitas 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 restringirse a la entrada del usuario, sino también a valores almacenados de la base de datos, archivos de texto, etc.

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

Algo más de información, y una lista bastante definitiva (constantemente actualizada), echa un vistazo a la Hoja de trucos de RSnake: http://ha.ckers.org/xss.html

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

Si codifica sistemáticamente todas las entradas del usuario antes de mostrarse, ~~entonces sí, está seguro de~~ que aún no está 100% seguro.
(Ver la publicación de @Avid para más detalles)

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

Tendrá que configurar un sistema de toma de decisiones para decidir qué etiquetas están permitidas y cuáles no, y siempre es posible que alguien encuentre la manera de dejar pasar una etiqueta no permitida.

Ayuda si sigue los consejos de Joel de hacer que el código incorrecto se vea mal o si su lenguaje lo ayuda al advertir / no compilar cuando está produciendo datos de usuario no procesados (tipado estático).

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 terceros no es seguro. O tal vez alguna ruta de código que crees que la codificación no lo hizo, así que lo olvidaste en otro lugar.

Por lo tanto, es posible que desee verificar las cosas desde el lado de la entrada también. Y es posible que desee comprobar cosas que lee de la base de datos.

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

<script/>

No hay forma de que el navegador ejecute lo anterior.

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