3 Replies Latest reply on Mar 18, 2014 7:54 PM by mark.weitzel

    What is the purpose of the JSON Security String?


      I'm trying to understand the purpose of the JSON Security String in the ReST API GET response.  Since the request is authenticated, it's not protecting against unauthorized access, and since the JSON comes after it, it's not protecting against huge response entity size (like paging does).  It's a bit of an annoyance in my situation where I'm using jackson ObjecMapper to deserialize the stream.  I can probably work around it by buffering the response and doing the regex (but then the response goes into memory), or piping it through a stream filter, but what I'd really like to do is just turn it off (it's an on-prem instance). Is there a system property that controls this?


      I can't imagine this being added without a good reason so I must be missing the bigger picture.  Can anyone enlighten me?



        • Re: What is the purpose of the JSON Security String?

          Craig McClanahan Gaston Dombiak - Do either of you have some thoughts you can share about the security header in the REST API JSON responses?  I've only run into issues with it using jQuery ajax, but haven't noticed anything signifiant using Jackson, specifically in the Jive SDK Java Jersey Edition - jivesoftware/jive-sdk-java-jersey · GitHub

          • Re: What is the purpose of the JSON Security String?

            This came up recently and we had a lengthy discussion internally. Shame on us (er... me) for not moving it into the docs (cc: Yuval Z).

            Here ya go:

            Great question!  The particular type of XSS attack that the "throw" line prevents is one where a malicious third-party site includes a <script/> tag that loads the JSON response from one of our API endpoints.  If a user who is logged in to Jive visited such a site, their browser would automatically send the Jive session cookie when fetching that JSON data, so the malicious site could pull in private data as a script.  Because JSON is a strict subset of JavaScript, the browser will execute it.


            That by itself wouldn't be a problem - the browser would evaluate the data structure but would not assign in to any variable so the attacker would not actually be able to read it.  The problem is that, at least in some browsers, it is possible to override the Object and Array constructors to capture data from object and array literals as they are evaluated.  The JSON in the above post represents a JavaScript object; so when it is evaluated the Object constructor is automatically invoked.  Using that method an attacker could collect data that it should not have access to.  There is more information on this type of attack here: http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html and here:http://blog.archive.jpsykes.com/47/practical-csrf-and-json-security/


            By inserting the "throw" line at the beginning of JSON responses we prevent the response from being executable as a script.  The browser will throw an error on that first line and then stop.  There are a number of ways to prevent a browser from executing JSON; we chose this particular option because it is what DWR does.  Within the Jive application we use XHR to fetch JSON responses which allows our code to remove the "throw" line before attempting to parse JSON data.  Thanks to the browser same-origin policy, a malicious web page operating on another domain cannot make an XHR request to the Jive server.  The only way that such an attacker can get at one of those JSON endpoints is to use a <script/> tag - so there is no way for such an attacker to remove the "throw" line before executing the response.


            Our Core API is set up so that it can be accessed from third-party applications that are not running in a browser.  In the case of non-browser applications there is no same-origin restriction, so third-party apps can easily remove the "throw" line.  A malicious non-browser application is not restricted by the same-origin policy either - but a malicious application is not likely to have access to a user's Jive session cookie or to a valid OAuth token.  In that case the Jive server will refuse to authorize requests to REST services.


            We starting using the "throw" JSON obfuscation in SBS 4.5, at the same time that we started required an X-J-Token HTTP header in requests to REST services that have side effects.  The purpose of the X-J-Token header is to replace the form token that was used in POST requests to struts actions - both are designed to prevent CSRF attacks.


            jQuery has some nice features that allow us to set up hooks that filter inbound and outbound ajax responses and requests.  We have to hooks configured in json-security.js.  One automatically removes the "throw" line from any responses with an application/json mime type.  The other hook uses the value of a global variable to add X-J-Token headers to all outbound requests.