Poiché l'exploit non viene inviato al server (utilizzando #payload ), posso dire che un DOM XSS è una vulnerabilità nel browser piuttosto che nell'applicazione Web?
Poiché l'applicazione fornisce la logica che si traduce in un comportamento imprevisto, l'XSS basato su DOM è chiaramente un problema di applicazione.
Le protezioni XSS basate su DOM sono integrate in molti browser moderni, ma non devi fare affidamento su di esse poiché proteggono da un sottoinsieme più piccolo di attacchi.
Edited to clarify that one should not rely upon browser features for XSS protections.
Quindi qual è l'applicazione? Esistono framework come Backebone.js che implementano l'intero MVC dell'applicazione in JavaScript sul client. Il componente lato server di questo molto piccolo, e solo un livello di accesso ai dati.
Quindi, per rispondere alla tua domanda, l'XSS basato su DOM influisce sul componente lato client di un'applicazione web.
La vulnerabilità del modello a oggetti documento è un attacco XSS in cui il carico utile di attacco viene eseguito come risultato della modifica dell'ambiente DOM. Il codice javascript viene eseguito sul lato client, quindi posso dire che è vulnerabile a livello di applicazione.
Esempio di vulnerabilità basato su DOM - collegamento avviso (document.cookie)
Vedi OWASP per ulteriori informazioni sulle vulnerabilità basate su DOM XSS
È una vulnerabilità delle applicazioni. Alcuni browser vanno abbastanza lontano nel tentativo di impedirlo, ma il problema non è il browser, ma la parte client dell'applicazione.
La modifica del DOM da JavaScript è una tecnica comune e utile, anche (o soprattutto) che utilizza una struttura di documenti costruita dinamicamente. Per questo motivo, un browser che non conosce la logica dell'applicazione desiderata può solo bloccare gli attacchi più evidenti e, mentre è bello provare a farlo, la responsabilità principale è dell'applicazione, non del browser.
Leggi altre domande sui tag xss