Cos'è la mutazione XSS (mXSS)?

mXSS è un nuovo tipo di attacco XSS di Mario Heiderich. L'ho visto presentare questo stesso discorso al Syscan 2013 quest'anno.

La vulnerabilità in questione proviene da innerHTML che consente la manipolazione diretta del contenuto HTML, ignorando il DOM . Un elemento innerHTML non è idempotente. Il browser manipola i contenuti per correggere e ottimizzare gli errori con l'HTML. Questo è molto visibile nell'esempio fornito nelle diapositive. Il problema con questa manipolazione è che a volte introduce difetti che non sono evidenti a prima vista. Un buon esempio è anche nelle diapositive.

Il grosso problema di questo attacco è che ignora (al momento del discorso, la situazione potrebbe essere migliore ora) la maggior parte dei filtri e disinfettanti XSS esistenti.

Per quanto ne so, non ci sono altre informazioni disponibili su questa classe di attacco XSS oltre a qualsiasi informazione presente nelle diapositive della presentazione.

Questa è una specie di post antico, ma alcuni commenti chiedevano se esistesse una qualsiasi difesa.

Ecco un estratto da il documento :

At this point the string is still harmless and cannoot be used to execute an XSS attack. However, as soon as this string is inserted into the browser's DOM by using the innerHTML property, the browser will mutate the string. This mutation is highly unpredictable since it is not part of the specified innerHTML handling, but is a proprietary optimization of HTML code implemented differently in each of the main browser families. The mutated string now contains a valid XSS vector, and the attack will be executed on rendering the new DOM element. Both Server and client filters were unable to detect this attack because the string scanned in these filters did not contain any executable code.

Questo exploit è in realtà un exploit basato su BROWSER. E nel mondo di framework piuttosto dinamici come angularjs e jquery, c'è un po 'di innerHTML in corso di sviluppo, anche nel 2012-2013, quando questo attacco è stato descritto per la prima volta.

L'autore continua a dire:

If innerHTML is only used to insert trusted code from the webapplication itself into the DOM, it is not vulnerable.

Quindi la risposta a "c'è qualcosa che possiamo fare?" è: non utilizzare innerHTML in combinazione con l'input dell'utente.

Ma aspetta ... e se la mia applicazione ha migliaia di chiamate a innerHTML o usiamo jquery? Il documento discute uno script che hanno offerto chiamato "TrueHTML". Quando cercavo codice di esempio, il meglio che ero in grado di trovare era qui , dove sostituisci l'uso del client di innerHTML , ignorando le funzioni discusse nell'attacco originale ... e senza dover fare altro che aggiungere un singolo file di script. Il documento discute anche di un impatto minimo sulle prestazioni.

(Non sono sicuro al 100% se la lista di codici che ho usato debba essere attendibile - non l'ho scritta, copy-pasta a tuo rischio! Detto questo, sembra che usi la tecnica descritta nel carta.) Non sono sicuro che il controllo "isExploitable" restituisca un valore corretto.

Ecco un estratto dal commit github fornito:

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);
 +              }
 +          });
 +      }
 +  },