Is there a trivial solution that 100% prevents any further script execution?

No, non la penso così. Ogni tag script viene eseguito su se stesso, quindi lanciare un errore non fermerebbe il successivo script. alert e company e forse syncron AJAX vengono in mente per impedire l'esecuzione di ulteriori script, ma questo bloccherà l'intero browser.

If not, are there solutions that work in most contexts or for most browsers (and ways to bypass them for other contexts/browsers)?

Bene, puoi provare a cancellare tutte le variabili globali passando sopra le proprietà della finestra. Quindi in teoria gli script non avrebbero accesso al DOM per fare qualcosa. In practice , probabilmente non funzionerà bene in quanto non tutte queste proprietà sono scrivibili. Sono dubbioso che sarebbe possibile rimuovere tutto ciò che ti interessa.

Altri possibili hack potrebbero essere tentare di distruggere il documento prima che altri script possano essere eseguiti, magari usando document.write in qualche modo. Questo sarebbe nella terra del comportamento indefinito e dei draghi.

Esempio di codice:

Tutti amano un buon esempio di codice, quindi qui un payload di esempio immagino che sia difficile da battere.

<iframe name="iwin"></iframe>
<script>
(function() {
    // Due to the name attribute on the iframe, iwin is now
    // an implicit global for the iframe's contentWindow.
    // It should not have been there before the tag was parsed,
    // and the name could be randomized.

    // For legacy IE, to make globals accessible (0_o).
    iwin.execScript && iwin.execScript();

    // PWND, we have new globals.
    var XMLHttpRequest = iwin.XMLHttpRequest;
})();
</script>

The idea is to provide a fallback that prevents (inline) JavaScript for browsers that do not support CSP.

Ricorda che CSP non deve essere usato come prima linea di difesa. Dovresti codificare correttamente per contesto per impedire XSS nella tua applicazione. OWSAP ha buone informazioni su questo.

Detto questo, CSP può essere un buon ripiego per rendere l'XSS molto meno serio, nel caso in cui una vulnerabilità XSS (ovvero codifica errata o non codificata in qualche punto della pagina) venga trovata nell'applicazione e sfruttata.

I know that it is possible to overwrite existing functions, but it's not clear to me how exactly this would work.

È molto facile da fare. Ad esempio, XMLHttpRequest = myFunction o XMLHttpRequest = null impedirebbe agli script di utilizzare XMLHttpRequest direttamente.

Il problema è che se un attaccante non può usare quella particolare funzione e se l'attaccante sa che lo stai facendo, potrebbe facilmente usare un metodo alternativo. Mentre potrebbe essere possibile sovrascrivere le funzioni tutte , non è consigliabile come soluzione affidabile.

Is there a trivial solution that 100% prevents any further script execution?

Se hai un errore di sintassi nella tua <script> , allora non verrà eseguito nulla in quel <script>...</script> . Sfortunatamente, con XSS, l'autore dell'attacco potrebbe facilmente avviare un nuovo <script> che funzionerebbe perfettamente.

Ci sono molti modi per iniettare JavaScript oltre a <script> , ad esempio <img onload> o onerror .

Per quanto ne so, non puoi fermare in modo affidabile tutto il seguente codice HTML dal contenere l'esecuzione XSS.

If not, are there solutions that work in most contexts or for most browsers (and ways to bypass them for other contexts/browsers)?

Il supporto per browser versione 1 di CSP è che inizia ad essere buono , e dal momento che CSP è stato progettato come backup in ogni caso (non un primo linea di difesa) potresti riuscire a interrompere la tua ricerca sapendo che il supporto del browser costituirà un problema di riduzione.

Detto questo, penso che l'idea di sovrascrivere le funzioni potrebbe fare molto per raggiungere il successo. Sembra che possa funzionare in modo in teoria in modo affidabile. Anche se questo non è raccomandato, penso che sarebbe uno studio interessante. Mi chiedo quanto sarebbe complesso da implementare.

Ho scritto questo commento con jQuery in mente, dal momento che è davvero facile da rompere accidentalmente. Poiché il codice lato client più complicato (il tipo con i vettori) utilizza jQuery, l'ajax comune e i modelli che causano vulnerabilità semplicemente non funzioneranno senza di esso.

Il modello di sicurezza di JavaScript è basato sui riferimenti , il che significa che se non puoi raggiungere qualcosa, non lo fa Esistono al codice. Ci sono un paio di ref non previsti come constructor.constructor("alert(666)")() , ma sono gestibili perché JS semplicemente non ha molti built-in da offrire (rispetto alla lib di php o .net). Se riesci a nascondere o distruggere il riferimento, rimuovi la capacità. Doug Crockford parla molto di questo , e in modalità "use strict" , è ancora più applicabile a livello granulare.

• Sarebbe il reindirizzamento migliore a una pagina senza tag di script; una versione non js o "lofi", se disponibile.

• Puoi utilizzare un iframe di dimensioni pari al 100% con un attributo sandbox per ri-pubblicare la pagina senza script; Qualcosa che ho un bookmarklet da usare per il compat test (crea un nuovo iframe, lo dimensiona e imposta .src su location.href ). Non tutti i browser supportano sandbox , quindi potresti rubare peter per pagare paul se il tuo obiettivo è quello di ridurre l'XSS trascurato.

• window.stop() funziona in alcuni browser (sicuramente FF), ed è abbastanza semplice da usare per interrompere il caricamento della pagina sul posto.

• "masterizzali tutti"; clobber tutte le proprietà globali integrate, lasciando solo le pure capacità logiche del linguaggio. Lo svantaggio è che document non è modificabile, tutto ciò di cui ha davvero bisogno un avversario intelligente. Potrebbe esserci un modo semplice per rompere document , ma è un vettore enorme così com'è.