Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

If all html in a site is generated in client side (attributes, urls, styles everything will be concatenated in javascript and set as innerHTML), is it doing only html escape enough for mitigating all xss attacks mentioned here?https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

share|improve this question
    
You have to consider the context in which the data is inserted into. See the rules 3, 4, 5, and 7 where you’re not in the context of HTML any more but in a different context, in which other rules on special characters and sequences apply. Additionally, rule 7 is about DOM-bases XSS which can work solely without any code injection at all. –  Gumbo Mar 1 at 14:18

1 Answer 1

Not necessarily, and it wouldn't be recommended. Admittedly it is likely to prevent DOM-based XSS in the majority of cases (in an HTML output context anyway), but not all as detailed on 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.

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet#Encoding_Misconceptions

This page also includes examples.

Furthermore, HTML encoding only applies when the output context is HTML.

Generally, I would still say that the best practice of validating and sanitising all user controllable input on a case-by-case basis is still the best solution. Generally, data would need to be both JavaScript and HTML encoded in this case. See the recommendation on the same OWASP page above.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.