Re: [jansson-users] JSON XSS attacks

[Karl Hiramoto]

Hi all, 

I'm wondering what everyone else is doing to prevent XSS  on web apps where the server is written in pure C?   I'm responding to a thread I dug up from over a year ago :-)

One possible suggestion is to create a function that may be useful to many people where there is:

json_t *json_string_html_escape(const char *value)

Where the returned JSON string is html escaped  to where it would be safe to display this value directly on the browser.   This type of function would probably be useful to may people and would save an extra step of having to escape it yourself before calling json_string()

Is anyone else doing all server side escaping, or relying on escaping in javascript on the client site?

References:

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

http://stackoverflow.com/questions/5696244/xss-is-escaping-and-sufficient

Thanks,

On Thu, Apr 11, 2013 at 2:00 AM, JKL <jkla...@gmail.com> wrote:

A while ago I submitted a patch to create a dump flag to cause HTML markup characters in strings to be escaped. That patch was rejected on the grounds that it was too specialized, and besides that the escaping could be performed after the strings are dumped. My original rationale had to do with JSON data inside HTML script blocks, and that technique is only useful in a limited number of circumstances.

Recently I have learned of information that makes the problem much more general. Specifically, if JSON data ever ends up getting sent to certain versions of Internet Explorer, and the JSON contains untrusted data, there could be a security vulnerability even if the data is delivered with the appropriate JSON content type.

http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html

This problem isn't just limited to JSON, as it has to do with IE content sniffing heuristics in general, and even things like images can be interpreted as executable Javascript in certain circumstances. Yes, it sounds utterly ridiculous, but application developers have no control over browser behavior. The only choice is to work around the problem.

In this case the only thing that can be done to completely solve the problem is ensure that markup characters in JSON strings are replaced with escaped versions, so that the content sniffing heuristic won't see any markup and the contents cannot be interpreted as code. In particular, all applications which send any JSON data to a browser must have the ability to properly escape markup inside JSON strings. This is true even if the data isn't embedded in HTML.

With this additional perspective, I suggest that a JSON library isn't really complete without the ability to produce browser-safe JSON. In fact, perhaps this escaping should be the default behavior, given the security implications. It doesn't make sense to make everyone handle this problem in their own code, if there is a straightforward way to do it right in the library and if the library is likely to be used on the Web. Some people might not even be aware of the potential security problems with JSON data, even though research into content sniffing exploits has been published as early as 2009.

Please reconsider this issue in light of this additional information. If you are convinced I will resubmit a patch, either to add a new dump flag to enable escaping of markup characters, or a new flag to disable escaping (with escaping being the default).

--
--