Si todo el html en un sitio se genera en el lado del cliente (atributos, urls, estilos, todo se concatenará en javascript y se configurará como innerHTML), ¿está haciendo solo html para mitigar todos los ataques xss mencionados aquí? enlace
Si todo el html en un sitio se genera en el lado del cliente (atributos, urls, estilos, todo se concatenará en javascript y se configurará como innerHTML), ¿está haciendo solo html para mitigar todos los ataques xss mencionados aquí? enlace
No necesariamente, y no sería recomendable. Es cierto que es probable que evite XSS basado en DOM en la mayoría de los casos (en un contexto de salida HTML de todos modos), pero no todo como se detalla en OWASP ...
Muchos currículos y documentos de capacitación en seguridad abogan por el uso ciego de la codificación HTML para resolver XSS. Esto, lógicamente, parece ser un consejo prudente ya que el analizador de JavaScript no comprende la codificación HTML. Sin embargo, si las páginas devueltas desde su aplicación web utilizan un tipo de contenido de "text / xhtml" o la extensión de tipo de archivo de "* .xhtml", es posible que la codificación HTML no funcione para mitigar contra XSS.
--- SNIP ---
Si eso no es suficiente para tener en cuenta, debes recordar que las codificaciones se pierden cuando las recuperas utilizando el atributo de valor de un elemento DOM.
Esta página también incluye ejemplos.
Además, la codificación HTML solo se aplica cuando el contexto de salida es HTML.
En general, aún diría que la mejor práctica es validar y desinfectar todas las entradas controlables de los usuarios caso por caso. En general, los datos deberían estar codificados tanto en JavaScript como en HTML en este caso. Consulte la recomendación en la misma página de OWASP anterior.
Lea otras preguntas en las etiquetas html xss javascript