DOMXSS - Il contenuto del campo di input è un vettore di attacco?

0

Un tipico esempio di DOMXSS è che il codice vulnerabile processa incautamente la parte dopo il segno di hash come in https://www.example.org/path/param1=val1&...#PAYLOAD_HERE senza convalida. Ad esempio, la stringa potrebbe essere assegnata tramite innerHTML a qualche elemento DOM. (O uno dei tanti metodi jQuery come html() , before() , prepend() e molti altri.)

Ora, confrontando con XSS riflessa, dove i parametri URL, i parametri del modulo o altri parametri (ad esempio come parte di un corpo in formato JSON) possono contenere il carico utile, spesso si tratta di input che possono essere inseriti nei campi modulo. Ad esempio, l'URL https://www.example.org/?search=query è praticamente sempre il risultato dell'utente che inserisce query in un campo di ricerca. (Almeno, questo è il caso d'uso previsto). Ora, è possibile ignorare il processo di inserimento della stringa di query nel campo modulo inviando direttamente l'URL della query. Simile per POST, anche se questo è un po 'più complesso (che non è il punto qui, per il gusto della discussione do per scontato che sia possibile).

Pertanto, se l'applicazione è vulnerabile a Reflected XSS attraverso un campo di input, virtualmente è sempre possibile creare un URL dannoso che, quando viene cliccato, sfrutta la vulnerabilità.

Tuttavia, mi sembra che questo non valga per DOMXSS. Se un'applicazione ha un campo di input che usa distrattamente il suo contenuto per aggiornare alcuni elementi DOM senza alcuna convalida, allora è chiaro che uno potrebbe inserire script arbitrari nel DOM. Si consideri ad esempio un'ipotetica app che ha un campo di input con id input_field e un elemento target come p , div , span o qualsiasi cosa con id target , e codice JavaScript con una riga come questa :

document.getElementById("target").innerHTML =
    document.getElementById("input_field").value;

Qui il contenuto del campo di input non viene inviato avanti e indietro come sarebbe per Reflected XSS.

La domanda per me è: Potrebbe essere sfruttato da un utente malintenzionato (senza sfruttare un precedente attacco XSS)?

    
posta countermode 28.09.2018 - 09:50
fonte

1 risposta

1

Sarebbe difficile sfruttarlo senza combinarlo con un'altra vulnerabilità. Come dovrebbe entrare il codice exploit nell'input? Suppongo che combinarlo con la correzione dell'interfaccia utente o qualcosa del genere avrebbe potuto funzionare, ma non vedo alcun modo chiaro di sfruttarlo. Potrebbe essere visto come un auto-XSS.

    
risposta data 29.09.2018 - 08:25
fonte

Leggi altre domande sui tag