Permitiendo a los usuarios ingresar un subconjunto seguro de HTML

10

Recientemente publiqué esta pregunta en Revisión de código y se recomendó que les pregunte a ustedes sobre esto.

Básicamente, esto se usará para permitir que los usuarios generen contenido con formato. Se coloca dentro de las etiquetas HTML, por lo que no tengo que preocuparme por que un atacante rompa un atributo. Si eso no está claro, aquí hay un ejemplo:

<div>
Generated content
</div>

Editar: No estoy insertando el contenido en un atributo, por lo que no es una preocupación el hecho de que salgan las comillas. Sé que todavía tengo que buscar atributos erróneos dentro del contenido generado por el usuario, que es para lo que sirve una gran parte del script.

He establecido que soy vulnerable a que un atacante publique un enlace malicioso o publique una imagen de seguimiento, pero eso es algo que estoy dispuesto a aceptar. No creo que puedas evitar eso sin las URL de la lista blanca, lo que también reduciría drásticamente la libertad que tienen los usuarios. Si hay una forma viable de corregir esta vulnerabilidad, me encantaría conocerla.

He leído la hoja de trucos OWASP XSS , y creo que tengo todos esas bases cubiertas.

¿De qué tengo que preocuparme fuera de esa hoja de trucos? ¿Me perdí algo en él? ¿Es mi código a prueba de futuro? ¿Estoy en camino sobre mi cabeza? ¿Debo cambiar a BBCode o Markup?

Código actual

    
pregunta Meredith 16.06.2014 - 08:36
fuente

3 respuestas

13

Se encuentra en una ruta correcta a medida que avanza con la inclusión en la lista blanca, pero su implementación a prueba de balas es difícil.

I.e. sus enlaces pueden ser engañados para ejecutar JS simplemente escribiendo:

<a href="JAVASCRIPT:xxx">xss</a>

También, especialmente los navegadores más antiguos pueden ejecutar JS en img src, etc.

Le recomiendo que vaya con HTMLPurifier , que, además de XSS, también le ayuda a lidiar con el código HTML roto (anidamiento de etiquetas, etc. ).

    
respondido por el timoh 16.06.2014 - 10:51
fuente
10

Resumen: use un desinfectante de HTML, pero solo en combinación con una Política de seguridad de contenido, ya que siempre hay nuevas formas de omitir los filtros.

Después de su propio procesamiento para permitir que pase el subconjunto de etiquetas HTML incluidas en la lista blanca, debe pasar su contenido a través de un desinfectante HTML.

Además de utilizar algún tipo de desinfectante HTML, se recomienda implementar una Seguridad de contenido Política también en páginas con contenido HTML de usuario. Este es un mecanismo implementado por el navegador que detendrá la ejecución de JavaScript en línea si el usuario logra insertar un script malicioso. Puede configurar el CSP para permitir solo contenido externo .js (ya sea en su dominio o en otros que incluya en la lista blanca, por ejemplo, las bibliotecas alojadas de Google).

Estos pasos asegurarán que si un usuario ingresa javascript:alert('foo'); o lo que sea como enlace, no se ejecutará. Si está permitiendo las etiquetas img y las etiquetas a , estas podrían apuntar a cualquier dirección web. Pueden realizar un seguimiento, pero la información de la sesión no se podrá enviar con ellos (por ejemplo, document.cookie ) debido al CSP.

Siempre se encuentran agujeros en los desinfectantes HTML a medida que se desarrollan los navegadores y el lenguaje de la web, como este en versiones antiguas de HTML Purifier (< = v4.1.0). Por eso recomiendo ambos enfoques en combinación para asegurar que las brechas en un método no lo dejen vulnerable.

    
respondido por el SilverlightFox 16.06.2014 - 11:19
fuente
-1

No se recomienda que intentes implementar esto tú mismo. Si decide utilizar el HTML proporcionado por el usuario, debería echar un vistazo a OWASP ESAPI para php aquí .

    
respondido por el Tim Lamballais 16.06.2014 - 12:14
fuente

Lea otras preguntas en las etiquetas