Sanitize HTML antes de almacenar en la base de datos o antes de la representación? (Biblioteca AntiXSS en ASP.NET)

Question

Tengo un editor que permite a los usuarios agregar HTML que se almacena en la base de datos y se representa en una página web. Como esta es una entrada que no es de confianza, planeo usar Microsoft.Security.Application.AntiXsSS.GetSafeHtmlFragment para desinfectar el HTML.

• ¿Debo santificarme antes de guardar en la base de datos o antes de presentar la entrada no confiable en la página web?
• ¿Existe una ventaja al incluir el código fuente AntiXSS en mi proyecto en lugar de solo la DLL? (Tal vez pueda personalizar la lista blanca?)
• ¿Qué archivo de clase debo buscar en para la implementación real de la GetSafeHtmlFragment

Answer 1

no estoy de acuerdo con la respuesta seleccionada por dos razones

1. Si almacenó los datos codificados, usted tiene que escoger un codificador antes de almacenar. ¿Qué sucede si ha almacenado algo como HTML pero también desea extraerlo en otro formato, por ejemplo, como respuesta JSON, o como parte de un documento XML? Ahora tiene un formato codificado en HTML que debe decodificar, luego codificar en el formato correcto.
2. ¿Qué sucede si descubrimos un error en los codificadores y sacamos una nueva versión? Ahora, como no está codificando en el punto de salida, todos sus datos anteriores pueden contener elementos que se han codificado incorrectamente. Puedes codificar de nuevo, pero luego tocas problemas de codificación doble que pueden ser dolorosos para filtrar correctamente.

Generalmente codifica en el punto de salida y trata los datos provenientes de un almacén de datos como no confiables por defecto, después de todo, ¿qué pasa si alguien logra editar su base de datos directamente o mediante inyección SQL?

Answer 2

• Tanto
• Sólo si piensa cambiar, lo que no lo haría hacer personalmente
• la clase AntiXSS (ya que es llamado como AntiXss.GetSafeHtmlFragment())

Answer 3

Usted puede usar la directiva de página en el parámetro ValidateRequest = "true". De esta forma, todos los datos de Solicitud se validan y, si hay un problema de validación, siempre se puede detectar el error. También evita los hilos de inyección sql y otros no solo XSS posibles.

con datos numéricos, puede validar desbordamiento de enteros o mal uso de tipos de datos con Int32.TryParse() o cualquier otro de la familia TryParse (Byte.TryParse Int16.TryParse ...)

No hay necesidad de usar cualquier otra clase o método adicional de desinfección.

Answer 4

Escuche el OWASP podcast 67 with Jeff Williams on XSS. Habla sobre no desinfectar o codificar antes del almacenamiento. La razón principal es que si las bibliotecas (cuando) evolucionan en respuesta a nuevas vulnerabilidades, sus datos van a quedar atrapados en la versión anterior. Por supuesto, esto no le impide ejecutar ninguna entrada en una lista blanca en el punto de entrada y rechazar cualquier cosa fuera del rango aceptable.