Is sanitizing JSON necessary?
Asked Answered
D

2

36

I think it's a well-known best practice on the web to mistrust any input. The sentence

"All input is evil."

is probably the most cited quote with respect to input validation. Now, for HTML you can use tools such as DOMPurify to sanitize it.

My question is if I have a Node.js server running Express and body-parser middleware to receive and parse JSON, do I need to run any sanitizing as well?

My (maybe naive?) thoughts on this are that JSON is only data, no code, and if somebody sends invalid JSON, body-parser (which uses JSON.parse() internally) will fail anyway, so I know that my app will receive a valid JavaScript object. As long as I don't run eval on that or call a function, I should be fine, shouldn't I?

Am I missing something?

Deodorize answered 22/9, 2014 at 21:5 Comment(1)
It sounds to me like body-parser is already sanitizing the input, so you shouldn't need to do so yourself. On the other hand, there's no harm in input being doubly sanitized unless it's a performance bottleneck.Slang
P
35

Since JSON.parse() does not run any code in the data to be parsed, it is not vulnerable the way eval() is, but there are still things you should do to protect the integrity of your server and application such as:

  1. Apply exception handlers in the appropriate place as JSON.parse() can throw an exception.
  2. Don't make assumptions about what data is there, you must explicitly test for data before using it.
  3. Only process properties you are specifically looking for (avoiding other things that might be in the JSON).
  4. Validate all incoming data as legitimate, acceptable values.
  5. Sanitize the length of data (to prevent DOS issues with overly large data).
  6. Don't put this incoming data into places where it could be further evaluated such as directly into the HTML of the page or injected directly into SQL statements without further sanitization to make sure it is safe for that environment.

So, to answer your question directly, "yes" there is more to do than just using body-parser though it is a perfectly fine front line for first processing the data. The next steps for what you do with the data once you get it from body-parser do matter in many cases and can require extra care.


As an example, here's a parsing function that expects an object with properties that applies some of these checks and gives you a filtered result that only contains the properties you were expecting:

// pass expected list of properties and optional maxLen
// returns obj or null
function safeJSONParse(str, propArray, maxLen) {
    var parsedObj, safeObj = {};
    try {
        if (maxLen && str.length > maxLen) {
            return null;
        } else {
            parsedObj = JSON.parse(str);
            if (typeof parsedObj !== "object" || Array.isArray(parsedObj)) {
                safeObj = parseObj;
            } else {
                // copy only expected properties to the safeObj
                propArray.forEach(function(prop) {
                    if (parsedObj.hasOwnProperty(prop)) {
                        safeObj[prop] = parseObj[prop];
                    }
                });
            }
            return safeObj;
        }
    } catch(e) {
        return null;
    }
}
Protohuman answered 22/9, 2014 at 21:34 Comment(2)
in terms of limiting the length of incoming JSON data (DoS), wouldn't you want to monitor that length in the request.on('data', chunk => { handler so you could request.destroy() it once it is over your allowed limit?Tissue
@RonnieRoyston - Most frameworks will have a limit capability built-in and you can configure that. For example, the Express middleware express.json() used for reading and parsing JSON bodies has a limit option where you set the max size you want to allow. This is a common enough feature, that most frameworks already support something for this.Protohuman
S
11

You should be fine. Early users of JSON would often call eval() on the received string, which is of course a huge security hole. But JSON.parse, as you state, handles the majority of these kinds of sanity checks.

As long as you make sure not to take something out of a received JSON object and pass it directly into a SQL query, for example, you should be fine.

Sprinkling answered 22/9, 2014 at 21:10 Comment(1)
The hint with not passing something out of a received JSON directly into a SQL query is especially valuable, thanks for that :-)!Deodorize

© 2022 - 2024 — McMap. All rights reserved.