Non sarebbe possibile utilizzare tale metodo per racchiudere le aree in cui è previsto l'input / output dell'utente (ad esempio i commenti box), così anche se uno script viene iniettato con successo attraverso l'evasione regex, lo script non verrà eseguito da rientra in un determinato wrapper HTML impostato per disabilitare tutti gli script al suo interno?
Problemi con il tuo approccio
No, non funzionerebbe. I problemi sono:
</disablescripts> per iniettare script e quindi ottenere XSS. You can use </disablescripts> to exit the new HTML6 feature. After that, anything in <script>alert(1)</script> will be executed . Questo commento non verrà visualizzato correttamente. E questo non sta nemmeno considerando la praticità di questo. Il problema con XSS è che gli sviluppatori spesso non sanno dove è previsto l'input dell'utente. Se lo sapessero, lo avrebbero già codificato in HTML. Ma per qualche ragione, hanno perso di vista cosa è l'input dell'utente e cosa no.
Lo stesso problema esiste con la tua idea proposta: come fa uno sviluppatore a sapere quali aree probabilmente contengono JavaScript? Anche se funzionasse, il tuo approccio sarebbe nel migliore dei casi una seconda linea di difesa, oltre alle soluzioni appropriate per XSS.
Migliori approcci per XSS
I migliori approcci sono:
script-src self https://cdn1.com . Solo i browser moderni lo seguiranno, ma non eseguiranno script inline iniettati e caricheranno solo script esterni dai siti consentiti. C'è un modo perfetto per fermare gli attacchi cross-site scripting. Evasione sensibile al contenuto; ad esempio, se il contenuto generato dall'utente viene inserito come contenuto in un documento HTML, HTML-escape &<>"'/ (potenzialmente consentire una piccola whitelist di tag consentiti come <b> o di escape di tutto e utilizzare un linguaggio sicuro simile al markdown per consentire un pochi tag), se il contenuto generato dall'utente viene inserito in javascript, quindi javascript lo sfugge, ecc. (Vedi OWASP per ulteriori dettagli .)
Questo attacco fallirebbe gravemente quando qualcuno tentasse di usarlo per prevenire attacchi su pagine web generate dinamicamente.
Immagina di avere una pagina web che legge il tuo commento da un database e inserisce quel commento in una pagina HTML che viene pubblicata per l'utente.
Scrivi la tua pagina HTML in questo modo:
<disablescripts>
{{ untrusted_user_content_read_from_db }}
</disablescripts>
Bene quando {{untrusted_user_content_read_from_db}} è impostato sul valore:
</disablescripts><script>alert("XSS -- gotcha!");</script><disablescripts>
quindi questo metodo di prevenzione fallisce quando il server web viene inviato sulla pagina Web html al browser come:
<disablescripts>
</disablescripts><script>alert("XSS -- gotcha!");</script><disablescripts>
</disablescripts>
Questo è praticamente ciò che fa una politica di sicurezza dei contenuti .
Tramite un'intestazione HTTP, l'autore del sito web può disabilitare gli script inline dall'esecuzione e "bloccare" i domini remoti che il tag script può caricare la loro origine da ( <script src="" ).
per es.
Content-Security-Policy: script-src 'self' https://apis.google.com
Il vantaggio di questo rispetto al metodo suggerito è che è impostato in un'intestazione HTTP in cui non può essere disinserito dal successivo contenuto della pagina. Nel tuo esempio un utente malintenzionato potrebbe semplicemente includere </disablescripts> all'inizio del suo payload per aggirare il problema.
Alcuni proprietari di siti Web hanno tentato di impedire XSS con il tag HTML <noscript> . Il problema è che se non si esegue correttamente la codifica dell'output, è possibile uscire dal tag <noscript> e ottenere comunque XSS. La cosa giusta da fare è a) convalidare l'input (ad es. Un numero è un numero) eb) codificare l'output.
Leggi altre domande sui tag html javascript web-browser xss