Estoy escribiendo un servicio que recibe datos FHIR y los almacena. FHIR es un formato estándar de información de atención médica HL7 que contiene HTML por definición, integrado en un JSON o XML, ( para garantizar la legibilidad humana del documento )
¿Cómo debo realizar la validación de entrada en este caso, para poder evitar XSS y otros ataques similares?
Por definición, el FHIR le solicita que preserve la vulnerabilidad XSS de los datos (almacenar como código, mostrar como código). XSS requiere que los datos se muestren de nuevo a los usuarios, lo que podría evitarse con la validación de salida. Acepte la entrada, almacénela como JSON, filtre cuando muestre los datos HTML como código HTML. Dependiendo de los sistemas de "salida", esto podría ser mucho más fácil (depende de la necesidad del sistema).
Filtrar código malicioso (javascript malicioso, enlaces, etc.) va a ser muy difícil. Hay muchas formas de ocultar el código incorrecto a través de la ofuscación.
Lo que podría hacer, según los detalles de la especificación FHIR, es agregar a la lista blanca el código bueno / aceptable. Si la especificación FHIR está bien definida, la inclusión en la lista blanca debería ser fácil de realizar. Si la especificación no está bien definida, podría ser imposible bloquear todos los intentos de XSS almacenados.
Soy de la opinión de que debería filtrar (bloquear) la entrada xss Y evitar la entrada proporcionada por el usuario en la salida. ¿Por qué? Debido a que las bases de datos son de larga duración y con frecuencia se comparten, no deben contener xss. Y las aplicaciones web a menudo utilizan más de una fuente de datos.
Si está utilizando Java, puede usar Hibernate Validator con JSoup para analizar y validar la entrada HTML.
Tiene un WhiteListType , lo que te permite seleccionar qué etiquetas permitir. WhiteListType.NONE no acepta etiquetas HTML, WhiteListType.SIMPLE_TEXT acepta b , em , i , strong , u .
Siempre puedes hacer tu propia lista blanca también.
Su mejor apuesta es probablemente no realizar la validación de entrada, pero realizar un saneamiento de salida.
Se puede utilizar un desinfectante como Google Caja para eliminar el script antes de enviarlo a la página HTML .
Como a menudo se encuentran errores en los desinfectantes, a menudo cuando hay una nueva adición o cambio a la especificación o implementación HTML en un navegador, se recomienda combinar esto con un desarrollador Política de seguridad del contenido . Esta es una característica de HTML5 y puede evitar los ataques XSS en los navegadores compatibles, ya que efectivamente puede incluir en la lista blanca los scripts que pueden ejecutarse. Cualquier inyección por parte de un usuario fallará con un error en la consola del navegador.
La razón por la que recomiendo desinfectar la salida en lugar de la entrada es porque si ya existió una entrada anterior en su base de datos que omite la versión del desinfectante que se usaba en ese momento, esto puede solucionarse fácilmente más adelante al actualizar el desinfectante usado para la última versión. Si desinfecta la entrada, esto lo hace más difícil, ya que tendrá que ejecutar todas las entradas existentes del usuario a través del desinfectante cada vez que lo actualice.
Lea otras preguntas en las etiquetas html xss data-validation