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
Interested to know this too.
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:
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.