0

I'm trying to figure out how "safe" this C# server-side code is against a maliciously crafted "text" string:

using Newtonsoft.Json;
...
public class FooController {
    private class FooData { ... }
    ...
        var fooObject = (FooData)JsonConvert.Deserialize(text, typeof(FooData));
    ...
}

Looking at the documentation for Json.NET Schema, it looks like JSchemaGenerator can be used to generate a JSON schema for a given C# class, which may then be used by JSchemaValidatingReader to validate inbound text prior to using JsonSerlializer to deserialize it.

I would be reassured to know that these steps are all done automatically when invoking JsonConvert.Deserialize() with a type as in the above code snippet. But unfortunately, I don't see this documented explicitly on newtonsoft.com, and simply throwing a few invalid JSON examples at the Deserialize() method doesn't convince me that all the security angles are covered.

My nightmare scenario is using code like this (perhaps together with an upstream check on the length of the text input) in an API endpoint and being owned by an injection attack.

Liam
  • 27,717
  • 28
  • 128
  • 190
Peter
  • 2,526
  • 1
  • 23
  • 32
  • I'm not clear how validating against a schema makes your code any more secure. If the Json contains values not in FooData then they just get ignored. If they do contain things in your object then they get parsed, schema or no. Json isn't run, so I don't see an issue here. If your concerned about injection attacks then you need to sanitise your JSON before you use it directly in any HTML or SQL. Json.Net has very little role to play here. – Liam Sep 11 '17 at 15:33
  • What kind of injection attacks are you expecting/wish to secure against? – Liam Sep 11 '17 at 15:33
  • 1
    As another aside unless your using a very old version of Json.Net you should be using the `JsonConvert.Deserialize` method signature. – Liam Sep 11 '17 at 15:37
  • @Liam Thank you for reading my question. The injection attack I have in mind is theoretical, and would involve exploiting some as-yet-undiscovered bug in the JSON parsing engine. In my hypothetical scenario let's suppose that only a small subset of JSON is needed to serialize instances of FooData, which means that a JSON schema validation step "upstream" of the JSON parser + deserializer can reject/block lots of possible malicious inputs. This makes theoretical bugs in the parser more difficult for an attacker to exploit. – Peter Sep 11 '17 at 15:51
  • 1
    Practically speaking, the biggest security risk with Json.NET is using `TypeNameHandling` without writing a custom serialization binder that sanitizes the incoming types. See [TypeNameHandling caution in Newtonsoft Json](https://stackoverflow.com/q/39565954/3744182) and [How to configure Json.NET to create a vulnerable web API](https://www.alphabot.com/security/blog/2017/net/How-to-configure-Json.NET-to-create-a-vulnerable-web-API.html). But can a JSON Schema even catch an invalid `"$type"` parameter? – dbc Sep 11 '17 at 23:45
  • I mean if there's a bug in the JSON parsing engine, then why wouldn't that bug also exist in the Schema parsing engine? It's essentially the same thing – Liam Sep 12 '17 at 07:35
  • @Liam Although JSON schemas are written in JSON (with some special keywords) the corner cases which the JSON parser might run into while attempting to _deserialize_ maliciously crafted text could be significantly different from those encountered by the JSON validator while attempting to _validate_ this text against a simple JSON schema. For discussion of some important differences between JSON validation and JSON sanitization, I invite you to review comments on https://github.com/OWASP/json-sanitizer/issues/7 – Peter Sep 12 '17 at 12:51
  • @dbc Any JSON schema that I would write by hand or generate from a class definition would be built up from primitive JSON types. The task of mapping the data back to a class in the context of a C# program would be handled by the JSON deserializer. The JSON validator doesn't need to know anything about the program; It refers only to the JSON schema. I see that your remark about TypeNameHandling is in line with the Json.NET recommendations from Munoz's Blackhat paper: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf – Peter Sep 12 '17 at 13:14

0 Answers0