No estoy seguro de si el filter_xss de Drupal es seguro. De acuerdo con el enlace que proporcionó, el filter_xss de Drupal se basa en la biblioteca kses para el filtrado de HTML. Para decirlo sin rodeos, no confío en los filtros derivados de kses o kses.

Si miras el código de kses, se basa en una expresión regular de monstruo. Esa es una arquitectura desagradable para un desinfectante HTML, y no confío en nada que esté construido de esa manera. Si tiene que filtrar HTML arbitrario, la forma correcta de hacerlo es analizar el HTML y luego operar en el árbol de análisis. (HTML Purifier funciona de esa manera, y en parte como resultado, confío en HTML Purifier mucho más.)

Históricamente, kses ha tenido algunos problemas de seguridad. Ver, por ejemplo, Vulnerabilidades en los filtros HTML basados en kses y HTML Sanitisation: The Devil's In The Details (y las vulnerabilidades) . No sé si esas vulnerabilidades afectan la versión de Drupal, pero no inspiran confianza. Por lo tanto, si necesitara el filtrado de HTML, y si eligiera por seguridad, creo que probablemente elegiría el Purificador de HTML en lugar de filter_xss .

También debería retroceder un poco. No dijiste mucho sobre la situación a la que te enfrentas. ¿Está seguro de que el filtrado de HTML es la herramienta adecuada para su trabajo? En mi experiencia, es mucho más común que necesite un escape de HTML (codificación de salida) en lugar del filtrado de HTML.

Si está incluyendo información no confiable en un documento HTML, debe decidir qué tipo de funcionalidad necesita:

• Escape de HTML, también conocido como codificación de salida. ¿La entrada proporcionada por el usuario es "solo texto sin formato", sin formato enriquecido? Si es así, use HTML escaping (también conocido como codificación de salida), no filter_xss . Al realizar el escape de HTML, desea utilizar el escape sensible al contexto, para escapar de los datos de manera adecuada para el contexto de análisis donde se insertarán los datos que no son de confianza. Para obtener más información, lea los siguientes recursos:

  • Los recursos de OWASP en XSS, incluidos la descripción general de OWASP XSS y < a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet"> la Hoja de referencia de prevención OWASP XSS . La biblioteca OWASP ESAPI tiene funciones de escape de salida para todos los contextos de análisis HTML con los que probablemente se encontrará.

  • ¿Filtra las entradas del usuario antes de la base de datos o en la pantalla?

  • Reduciendo el XSS mediante el escape automático basado en el contexto en los sistemas de plantillas

• Filtrado de HTML. ¿Desea permitir que la entrada proporcionada por el usuario contenga formato HTML enriquecido? ¿Desea permitir que el usuario ingrese en un HTML casi arbitrario, que desea incluir textualmente en el documento de salida? Si es así, necesita un filtro HTML. En esta situación, HTML Purifier es una excelente opción, y probablemente más segura que el filter_xss de Drupal. Esa es mi opinión personal.

Cuando inserto información proporcionada por el usuario en un documento HTML, mi experiencia es que probablemente el 95% de las veces desee que el HTML se escape, no el filtrado de HTML. El filtrado de HTML es la excepción. (¿Con qué frecuencia espera que los usuarios ingresen en el marcado HTML? Si está escribiendo una aplicación para la población general, la respuesta es: casi nunca). Entonces, ¿está seguro de que necesita un filtro HTML de todos modos?

D.W. tiene algunos puntos excelentes, pero me gustaría señalar algunas cosas:

  

Este código hace cuatro cosas:

     

1. Elimina caracteres y construcciones que pueden engañar a los navegadores.
  
2. Se asegura de que todas las entidades HTML estén bien formadas.
  
3. Se asegura de que todas las etiquetas y atributos HTML estén bien formados.
  
4. Se asegura de que ninguna etiqueta HTML contenga URL con un protocolo no permitido (por ejemplo, javascript: ).
  

Suponiendo que hace un excelente trabajo de todas las cosas en esta lista, hay algunas omisiones notables: equilibrio de etiquetas , ataques de nivel de codificación , enlace de spam .

Incluso si lo hace bien, HTMLPurify ha existido y ha sido atacado. Puedo pensar en al menos un académico de seguridad en mi cabeza, que se asegura de que HTMLPurify esté parcheado y estable antes de publicar nuevos ataques. Si Drupal no recibe un escrutinio similar, usaría el más endurecido.

Equilibrio de etiquetas

Si la seguridad de sus usuarios depende de que puedan distinguir el contenido que usted creó de los autores o de terceros, el equilibrio de etiquetas es importante.

Imagina que usaste <table> s para formatear. Las etiquetas no balanceadas pueden permitirles sacar contenido de la región que parece ser contenido de terceros en una región de la página que parece estar controlada por los propietarios del sitio. Por ejemplo, si su lista blanca incluye etiquetas de formato inocuas, como <table> , entonces

</table>
<center>If you have any questions,
<a href="[email protected]">contact us</a>
<br>Bogus copyright</center><br><br><br><br><sub><sub><sub><sub><sub>

podría permitir que el atacante falsifique un pie de página que contenga enlaces de phishing.

Un aparente e inocuo </ul> podría ayudar a un atacante a salir de una lista de comentarios de usuarios que se muestran usando <ul><li>...</ul> por HTML semántico.

Las listas blancas configurables por el usuario le dan mucho espacio para colgarse aquí, ya que los expertos en HTML suponen acertadamente que los elementos equilibrados como <table> y <ul> no hacen nada sensible a la seguridad (solo crean recuadros en torno al contenido fluido) , pero las etiquetas individuales son problemáticas.

Ataques de nivel de codificación

Si el atacante puede obtener contenido desinfectado en los primeros kB de una página HTML que no tenga un encabezado Content-type que especifique una codificación, entonces podría engañar a IE para que trate la página como UTF-7 , evitando todos los demás desinfectantes.

Esto puede caer en "construcciones que pueden engañar a los navegadores", pero el código fuente en esa página no indica que sí.

Enlace de spam

Si permites enlaces pero el desinfectante no agrega rel="nofollow" a los enlaces, tu reputación puede ser secuestrada.