Se tutto il codice html in un sito è generato lato client (attributi, url, stili tutto sarà concatenato in javascript e impostato come innerHTML), sta facendo solo l'html di escape sufficiente per mitigare tutti gli attacchi xss menzionati qui? link
Se tutto il codice html in un sito è generato lato client (attributi, url, stili tutto sarà concatenato in javascript e impostato come innerHTML), sta facendo solo l'html di escape sufficiente per mitigare tutti gli attacchi xss menzionati qui? link
Non necessariamente, e non sarebbe raccomandato. Evidentemente è probabile che prevenga l'XSS basato su DOM nella maggior parte dei casi (comunque in un contesto di output HTML), ma non tutto come descritto in dettaglio su OWASP ...
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HTML encoding may not work to mitigate against XSS.
--- SNIP ---
If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element.
Questa pagina include anche esempi.
Inoltre, la codifica HTML si applica solo quando il contesto di output è HTML.
In generale, direi sempre che la migliore soluzione per convalidare e disinfettare tutti gli input controllabili dall'utente, caso per caso, è ancora la soluzione migliore. In generale, i dati dovrebbero essere entrambi codificati in JavaScript e HTML in questo caso. Vedi il consiglio sulla stessa pagina OWASP qui sopra.
Leggi altre domande sui tag html javascript xss