Is there a proposed fix?

From what I've seen the input '["/"]' should become '["\\/"]'.

Currently investigating the issue, actually Python's json library behaves like cjson in that respect. I'm trying to clarify if this is actually a security issue at all. 

The second link you posted does not work for me currently (server does not answer) so I need some time for verification.

Some explanation from John Millikin (author of jsonlib) why this input needs to be escaped:
> If "/" is not escaped, then user-sourced fields are vulnerable to
> injection, because browser error-handling heuristics may parse the
> string "</script>" as markup:

>  loadUsers({"users": [{"name": "Joe Smith</script><script
>  type='text/javascript'>alert('injected!')</script><script
>  type='text/javascript'>", "age": 40}]})

Actually I found that also simplejson 2.1 is vulnerable (while 1.7 in EL4 is not) as well as Python 2.x and Python 3.x.

Security team: Can you please file issues for Python 2+3 (all supported Fedora versions + EL6) + python-simplejson (all Fedora, EL5, EL6).

Created attachment 434739 [details]
proposed fix

I created a small patch which I believe fixes the issue. Can someone review this?

Security Team: Can you please also file bugs for python-demjson (Fedora + EPEL, all versions)?

Created attachment 434814 [details]
revised version of fix

Actually the current url of the blog post referenced as [2] is http://notmysock.org/blog/insecurity/quotes-dont-help

With the help of John Millikin (author of jsonlib) I was able to produce a revised patch which fixes the issue.

There is some work left to be done which you might consider a bug but to me it was more important to fix the security bug than doing upstream's work:
The parser was not modified, which means that 
   cjson.decode(cjson.encode("/")) != "/"
The issue existed previously as
   cjson.decode(r"\/") != "/"
however now with correct escaping it is more likely that user's trigger the issue.

I looked into implementing a correct fix and it turned out that someone tried that before (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534709). However that patch was turned down because upstream (which was alive back then) said the "correct fix is to modify the parser to take into account the solidus, so that it can all be done in 1 stage with only 1 buffer."

As python-cjson uses Python's PyString_DecodeEscape function for its parser needs, this means one actually needs to write a new escape-aware parser from scratch.

Therefore I'm for leaving the parsing issue and just release a package with the correct escape fix.

Technically this is not a bug in cjson (or any other JSON package), but rather a potential bug in other applications which may incorrectly embed or parse embedded JSON.

That being said, if you are to make a downstream patch to make it "HTML-safe", it should probably escape all special HTML/XML characters or sequences that could otherwise result in improper parsing.  Also you need to do so according to the JSON (RFC 7159) grammar, which has a more restricted set of escape sequences than does JavaScript.

You should escape:

/ (U+002F)  =>  \/
< (U+003C)  =>  \u003c
> (U+003E)  =>  \u003e
& (U+0026)  =>  \u0026

Also note that escaping ">" is additionally useful to prevent accidental recognition of the XML CDATA delimiter "]]>".

(In reply to Felix Schwarz from comment #5)
> Security Team: Can you please also file bugs for python-demjson (Fedora +
> EPEL, all versions)?

python-demjson version 2.2.1 now supports an 'html_safe' option which will insure the generated JSON is safe to embed inside HTML.  The equivalent option for it's included 'jsonlint' command is --html-safe.

See Fedora update task, bug# 1100731
Upstream info: http://deron.meranda.us/python/demjson/

Deron, you're right - I came to the same conclusion some time ago. Also python-cjson is retired/orphaned for F20 / EPEL6 so I guess we can close this bug.