¿La prevención XSS almacenada debe ser del cliente o del servidor? [duplicar]

Normalmente para la prevención XSS usamos el carácter de escape html para validar el carácter o la entrada. De acuerdo con OWASP, aquí hay algunas de las cosas que debe seguir:

Para el lado del cliente y del servidor:

• Carácter de escape antes de procesar la entrada dada.
• Mejor uso de la biblioteca de codificación de seguridad.
• No ingrese datos que no sean de confianza, excepto en la ubicación permitida.
• Escape de HTML antes de insertar datos no confiables en el contenido del elemento HTML
• Escape de atributos antes de insertar datos no confiables en atributos comunes de HTML
• Escape de JavaScript antes de insertar datos no confiables en valores de datos de JavaScript
• Los valores JSON de escape HTML en un contexto HTML y leen los datos con JSON.parse
• Escape de CSS y valide estrictamente antes de insertar datos no confiables en valores de propiedad de estilo HTML
• Escape de URL antes de insertar datos no confiables en valores de parámetros de URL de HTML
• Sanitize HTML Markup con una biblioteca diseñada para el trabajo
• Evitar XSS basados en DOM

Para el lado del servidor:

• Usar el indicador de cookie HTTPOnly

• Implementar política de seguridad de contenido

• Implemente y configure WAF como la seguridad de Mod.

• Use el encabezado de respuesta de protección X-XSS

Hay otras medidas de prevención. Puede consultar este enlace para obtener información más detallada.

enlace

La solución más efectiva es probablemente una combinación de validación de entrada y codificación de salida.

No sé si puede depender del cliente para implementar mitigaciones XSS efectivas. Esperemos que lo hagan, pero no es algo en lo que puedas confiar.

La primera pregunta que desea hacer es qué hace con la entrada que falla la validación. ¿Elimina los caracteres incorrectos y deja que el resto de la entrada continúe? Eso hará que su aplicación sea impredecible para el usuario, lo que nunca parece una buena idea.

Otra cosa a tener en cuenta es que es posible que sus datos no siempre se muestren dentro de HTML. ¿Qué sucede si sus datos se incluyen en un documento PDF o se envían a una impresora? Esos sistemas tendrán sus propios formatos y la codificación HTML no tendrá sentido.

Este es el enfoque que recomendaría:

• Defina la entrada aceptable en términos de tamaño y conjunto de caracteres.
• Defina su comportamiento para una entrada no válida.
• Valide la entrada y rechace (recomendado) o restriegue
• Use métodos seguros para almacenar la entrada en su almacén de datos
• Al presentar los datos a los usuarios, codifíquelos correctamente para el formato (HTML, javascript, etc.)

Aquí existe el riesgo de que alguien de su equipo pueda hacer la suposición, ya que los datos están en un almacén de datos interno de que es seguro y comenzar a usar los datos sin realizar la codificación adecuada.

Idealmente; lado del servidor. Asegúrese de que su código no coloque entradas de usuarios sin autorización en la página. Pero no sería un desastre ejecutarlo del lado del cliente. Porque la víctima es el cliente donde se verifica. Esto abre la posibilidad de que el usuario eluda la medida de seguridad, pero si se hace bien, sería una gran molestia.

El cliente no debe ser responsable de prevenir cualquier tipo de XSS aparte del XSS basado en DOM, aunque los encabezados de seguridad pueden ayudarlo a no ejecutar nada a lo que no está destinado. La prevención de XSS sigue siendo responsabilidad del servidor, aparte de XSS basado en DOM.

El cliente del navegador también es inútil en la validación porque un atacante lo omitirá para lograr XSS.

He actualizado esta pregunta aquí para saber cómo prevenir todos los tipos de XSS. enlace (también más información sobre los encabezados de seguridad).