[ic] [interchange] Add better messages, support for application/json handling

Peter peter at pajamian.dhs.org
Wed Dec 31 22:57:21 UTC 2014

On 01/01/2015 05:16 AM, David Christensen wrote:
>> Also I would like to disable the entire code block by default as it
>> adds additional overhead to processing the page if someone has
>> already implemented their own code to handle json data, it may not
>> cause any apparent regressions, but there is some overhead in
>> parsing the JSON if it's not going to be used.
> Short of a custom core patch, how would this have been handled at
> this level in code?

It doesn't require a core patch, but it would require a bit of global
code.  Adding a usertag that is similar to the env tag but accesses
::http()->{entity} instead will fetch the json, then it's a simple
matter of parsing it, most likely with the JSON library.  On a catalog
level such a usertag can simply be called at the beginning of a page
that you know will be used to post JSON data to, it's not that far fetched.

> That kind of situation is always something we
> cannot anticipate or account for, and the impetus is on them to
> ensure custom patches still work with upgraded versions of the core.

As I just pointed out, doesn't require a custom patch, and it would
still work with future versions of the core.

> Considering this is only invoked if POSTed with application/json, I'm
> not seeing the argument for additional overhead.  Can you elaborate
> on the issues you see here?

The above scenario would likely be used to interface to a 3rd-party API
which does a post-back with a mime type of application/json.  This would
cause your code to fire off and create additional overhead of parsing
the JSON twice.  Since it is especially likely that the JSON library
would be present in this case you cannot rely on the lack of such a
library to deal with this code.

Another issue that just occurred to me is ... I'm not sure just how much
overhead parsing JSON incurs (maybe we need to benchmark), but assuming
it's more than just standard CGI parsing, what's to stop an attacker
from DDOSing with a bunch of json posts?  Your code would fire off and
parse them so long as there is a JSON library to do so with?  Worse yet,
what if a vulnerability is discovered in the JSON module?  We've just
made that very easy to exploit in Interchange.  Granted we cannot
anticipate every vulnerability that might or might not exist in every
library we use, but we can minimize exposure by not having code that
runs if the results are unneeded and unused.  This is why I am simply
asking that this code be opt-in so that it doesnt' affect every
Interchange catalog that has upgraded to it if some sort of
vulnerability or DDOS angle is discovered with it.


More information about the interchange-users mailing list