Of course json_encode is meant to create code for JS, it does not escape for HTML, so you’re right — document.write attack will work. I meant only to use json_encode instead of threating everything like strings and putting it inside “”.

And to prevent this attack additional HTML escaping is needed there, or XML->JSON->again-XML escaping if document is XML, or XML->JSON->CDATA escaping if script is enclosed into CDATA section. Holy God… But again, document.write does not work in XHTML (but one day one browser might support it out of the blue). And all this is the reason why I prefer to use javascript_tag method which automatically decides what escaping should be done for js code for current document type.

As for eval, since it’s embedding JS code inside JS string, I’d use double json_encode and concat two JS strings, NOT embed one into another:

eval(“u=” + );

Attack should not work then. If you add + “; alert(u)” at the end you will notice that whole “0,x setter=alert,x=2″ has been assigned to variable u.

The truth is that programmer should be aware of what language in what another language is he embedding.

Regards.

Json_encode uses unicode escapes which is bypassable inside document.write and eval, just like hex escapes for encodeForJavaScript.
e.x. if i use json_encode($str,JSON_HEX_TAG|JSON_HEX_APOS|JSON_HEX_QUOT|JSON_HEX_AMP) inside document.write where malicious $str=”“,
Then i get this – document.write(“\u003Cimg src=x:x onerror=alert(1)\u003E”) on my client and XSS still executes.

Thanks for your feedback. I can understand your confusion. What i meant to convey was esapi protection function encodeForJavaScript does not protect against all cases of javascript injection. The title essentially says that you can bypass the xss protection if you use this function for scrubbing. But, this is not a vulnerability of this function and no code fix can prevent this. It is required that people either use the correct function or don’t put insecure code there at all. If you need more clarity, lets discuss this over email.

For the low-paid programmer, i don’t think he or she will even know what xss is, no point in talking about security anyways there. My main concern was for people who know XSS and have sometime seen and used the xss prevention cheat sheet. Once Jeff fixes the defense recommendation on that page, those people will have a better idea of use the esapi correctly and securely.

i corrected your original comments, since some of it inside < and > was getting stripped. i will see what i can do to fix my commenting engine.

var a = <%= user_data.to_json %>; // Note absence of quotes

Also you don’t have to deal with data types, because json encoder checks for user_data type and yields string, integers, floats, etc. accordingly. Do you see any flaws in this approach?

BTW it is worth mentioning that those who use mixed HTML/XHTML and famous //<![CDATA[ //]]> snippets should
also ‘escape-for-cdata’, that is replace "]]>" with "]]>]]&gt;<![CDATA[" to prevent ]]> injection. Of course only when document is served as XHTML, not HTML. I use some guerilla patching of "javascript_tag" method in my Rails applications to make it automatic.

Besides that, good post. Example #2 shows HTML-within-JS-within-HTML; can anyone explain to me how a low-paid programmer (probably outsourced?) is ever going to care enough about his job to do this right?