views:

136

answers:

2

I'm using json to pass data between the browser and a java server.

I'm using Json-lib to convert between java objects and json.

I'd like to strip out susupicious looking stuff (i.e "doSomethingNasty().) from the user input while converting from json to java.

I can imagine several points at which I could do this:

  • I could examine the raw json string and strip out funny-looking stuff
  • I could look for a way to intercept every json value on its way into the java object, and look for funny stuff there.
  • I could traverse my new java objects immediately after reconstitution from json, look for any fields that are Strings, and stripp stuff out there.

What's the best approach? Are there any technologies built for this this task that I tack tack on to what I have already?

A: 

As I understand you need to validate the JSON data coming into your application. If you want to do white listing ("You know the data you expect and nothing else is valid"), then it makes sense to validate your java objects once they are created ("make sure not to send the java object to DB or back to UI in some way before validation is done). In case you want to black listing of characters (you know some of the threat characters which you want to avoid"), then you can directly look at the json string as this validation would not change much over a period of time and even if it does, you only need to enhance one common place. For while listing iot would depend on your business logic.

Fazal
+1  A: 

I suggest approach 3: traverse the reconstructed Java objects immediately upon arrival, and before any other logic can act on them. Build the most restrictive validation you can get away with (that is, do white-listing).

You can probably do this in a single depth-first traversal of the object hierarchy that you retrieve from Json-lib. In general, you will not want to accept any JSON functions in your objects, and you will want to make sure that all values (numbers, strings, depth of object tree, ...) are within expected ranges. Yes, it is a huge hassle to do this well, but believe me, the alternative to good user-input validation is much, much worse. It may be a good idea to add logging for whenever you chop things out, to diagnose any possible bugs in your validation code.

tucuxi