Invio una richiesta AJAX e quando l'HTML carica nuovamente, recupero i valori di alcuni elementi dell'interfaccia utente sul lato client e li presenta all'utente, in questo modo:
var displ="<h1>"+$( "#myslider" ).slider( "values", 0)+</h1>
$("mydiv").append(displ);
Il valore di #myslider o qualsiasi altro elemento come una casella di selezione può essere modificato in un valore come <script>...</script> e creare un'iniezione XSS?
Risposta breve: Sì .
Risposta più lunga: Sì, se il <select> contiene già <option> con un payload XSS in (in qualche modo - vedi sotto), e dipende anche dal tipo di dispositivo di scorrimento () la funzione fa. Se si prende l'altro esempio (un input di selezione), quindi utilizzando val () senza disinfettare il contenuto, si verificherà questo problema. A meno che lo slider () non disinfetti il contenuto HTML in qualche modo, potrebbe fare lo stesso.
Questa è una forma di scripting cross-site basato su DOM.
Esempio di lavoro (con <select> ): link
Testato in Chrome per Mac OS X.
addString();
$("select").change(addString);
function addString() {
var displ=$("select").val()+"<br/>";
$("div").append(displ);
}
Dove c'è un <select> e un <div> sulla pagina.
Sfruttamento pratico
L'altra domanda è quando questo può essere praticamente sfruttato da un aggressore? Per rendere questo pratico per un utente malintenzionato, il valore di una selezione <option> deve provenire da una fonte non attendibile, direttamente da un parametro di richiesta controllabile dall'utente (inclusi intestazioni HTTP, cookie, ecc.) Per XSS riflesso o dove il carico utile è caricato dalla memoria (database, ecc.) per XSS memorizzato.
L'esempio sopra ha già il payload XSS nella pagina, quindi è fondamentalmente presupponendo che l'input non attendibile si sia già verificato.
Esempio # 1
Ecco un esempio interamente basato su DOM. JavaScript imposta il valore di un'opzione all'hash della posizione dell'URL. Quindi, se la vittima viene attirata su una pagina con un carico utile XSS dopo un # nell'URL, l'XSS può essere attivato.
Esempio # 2
Uso una tecnologia lato server (PHP in questo caso) per creare una pagina con un elemento <option> generato dinamicamente da un parametro URL controllabile dall'utente. Poiché sono uno sviluppatore super intelligente, so che se le doppie virgolette possono essere sfuggite, la pagina sarà vulnerabile all'XSS riflesso sull'elemento <option> stesso, quindi mi assicuro di rimuovere le doppie virgolette dalla stringa , pensando che sarò al sicuro.
// User controlled parameter
$value = $_GET("value");
// "Sanitise" the value by removing double-quotes
$sanitised = str_replace('"', '', $value);
// Output to the page
echo "<option value=\"" . $sanitised . "\">Choose Me!</option>";
Poiché lo sviluppatore ha disinfettato le virgolette, questo problema non può essere direttamente sfruttato. Cioè l'attaccante può inserire tutti i tipi di caratteri all'interno del valore dell'opzione, ma non può iniettare cose come "> per terminare l'elemento opzione e avviarne uno nuovo.
Tuttavia, a causa dell'XSS basato su DOM, Javascript continuerà a prendere questa stringa, potenzialmente contenente elementi HTML, e a stamparla direttamente sulla pagina. Certo, lo sviluppatore dovrebbe avere:
I riferimenti sono i cheat OWASP.