¿Qué es la mutación XSS (mXSS)?

mXSS es un nuevo tipo de ataque XSS de Mario Heiderich. De hecho, lo vi presentar esta misma charla en Syscan 2013 este año.

La vulnerabilidad en cuestión proviene de innerHTML que permite la manipulación directa de contenido HTML, sin pasar por el DOM . Un elemento innerHTML no es idempotente. El navegador manipula los contenidos para corregir y optimizar errores con el HTML. Esto es muy visible en el ejemplo que aparece en las diapositivas. El problema con esta manipulación es que a veces introduce fallas que no son evidentes a primera vista. Una buena example también se encuentra en las diapositivas.

Lo importante de este ataque es que evita (en el momento de la conversación, la situación puede ser mejor ahora) la mayoría de los filtros y desinfectantes XSS existentes.

Por lo que sé, no hay ninguna otra información disponible sobre esta clase de ataque XSS, además de la información presente en las diapositivas de presentación.

Este es un tipo de publicación antigua, pero algunos comentarios preguntaban si había alguna defensa.

Aquí hay un extracto de el documento :

  

En este punto, la cadena sigue siendo inofensiva y no se puede utilizar para   Ejecutar un ataque XSS. Sin embargo, tan pronto como se inserta esta cadena   en el DOM del navegador usando la propiedad innerHTML , el navegador    mutará la cadena. Esta mutación es altamente impredecible ya que   no es parte del manejo innerHTML especificado, pero es un   Optimización propietaria de código HTML implementado de manera diferente en cada uno.   de las principales familias de navegadores. La cadena mutada ahora contiene un válido   XSS vector, y el ataque se ejecutará al renderizar el nuevo DOM   elemento. Los filtros del servidor y del cliente no pudieron detectar esto   ataque porque la cadena escaneada en estos filtros no contenía ningún   código ejecutable.

Este exploit es en realidad un exploit BASADO EN NAVEGADOR. Y en el mundo de los marcos bastante dinámicos como angularjs y jquery, hay bastante innerHTML pasando bajo el capó, incluso en 2012-2013 cuando se describió por primera vez este ataque.

El autor continúa diciendo:

  

Si innerHTML solo se usa para insertar código de confianza de   La aplicación web en sí misma en el DOM, no es vulnerable.

Entonces la respuesta a "¿hay algo que podamos hacer?" es: No use innerHTML en combinación con la entrada del usuario.

Pero espera ... ¿qué pasa si mi aplicación tiene miles de llamadas a innerHTML o usamos jquery? El artículo analiza un script que ofrecieron llamado "TrueHTML". Cuando busqué un código de ejemplo, lo mejor que pude encontrar fue aquí , donde anule el uso del cliente de innerHTML , omitiendo las funciones descritas en el ataque original ... y sin tener que hacer más que agregar un solo archivo de script. El artículo también analiza un impacto de rendimiento mínimo.

(No estoy 100% seguro de que deba confiarse en la lista de códigos que utilicé, ¡no la escribí, copie la pasta bajo su propio riesgo! Dicho esto, parece que se utiliza la técnica descrita en el en papel.) No estoy seguro de si la comprobación "es explotable" devuelve un valor adecuado.

Aquí hay un extracto de la confirmación github proporcionada:

mitigateMXSS: function (element) {
 +      var that = this;
 +      if (typeof element.innerHTML === 'string') {
 +          Object.defineProperty(element, 'innerHTML', {
 +              get: function () { return that.changeInnerHtmlHandler(this, 'innerHTML') },
 +              set: function (html) {
 +                  while (this.firstChild) {
 +                      this.removeChild(this.lastChild);
 +                  }
 +                  this.insertAdjacentHTML('afterBegin', html);
 +              }
 +          });
 +      }
 +  },