1

It's sometimes possible to use an alternate encoding to get around security checks (CAPEC-267). While the JSON spec may be strict on what is valid, popular parsers don't necessarily conform perfectly [1].

My question is thus: what alternate encodings are allowed by the standard, and what ones are allowed by popular parsers? Of the alternate encodings that exist, how confident can we be that they can't be used in an attack? The specific attack I'm concerned with is avoiding a white- or black-list checking the json key names in untrusted input, but I'd be interested in hearing of other attacks possible through alternate encoding of JSON keys - for my benefit and that of others.

[1] For example, the spec states that key names are case sensitive. Golang's encoding/json package prefers case-sensitive matches but will fall back to case-insensitive key matching - see (json.Unmarshal()).


(Edit) Use case: I'm involved in developing a network-attached appliance. Normally it is controlled by the cloud; however, if it gets misconfigured that isn't possible - or if the end user does not configure their network in a way we can understand. Uptime is highly important to the customers, so I'm working on a mechanism whereby a "rescue" file is written to usb key by the end user and then plugged into the appliance. Some tasks, such as restarting particular processes, are deemed safe and so a signature isn't necessary.

Since I can't imagine every possible issue, there's also a provision for a JSON key whose value is shell commands - obviously far more dangerous. I have a blacklist blocking dangerous command keys like this unless a signature is present and valid. Currently, I'm simply doing a case-insensitive text search for each "key_name" (including quotes, to reduce the chance of false positives), while the data is still encoded as json. As long as an attacker can't use something else in place of quotes or use some sort of encoding, I think my very simple blacklist will function well.


I originally planned to post to StackOverflow but decided this was a better fit. Apologies if that isn't so.

  • 1
    I've never seen such a flaw and I expect they are extremely rare. Encoding flaws often rely on a front security layer interpreting input differently to a back security layer, but JSON apps rarely do that. Also, JSON is almost always utf-8 throughout. However, mass assignment and deserialization flaws can happen – paj28 Oct 23 '17 at 19:14
  • JSON is always UTF, and there's only one way to escape text in JSON, unlike HTML, where there's probably at least 5 common ways of escaping. Even malformed content is only as good/bad as its runtime allows: if the badJSON doesn't lead to XSS or SQLI, what good is it? – dandavis Oct 23 '17 at 22:56
  • @dandavis "...if the badJSON doesn't lead to ..." -- I've updated the question with the use case. Short version: in this application, there could be dangerous things in the json that would be acted upon. – Mark Oct 24 '17 at 21:36
  • JSON is parsed, so if there were invalid parts of the key, the whole thing should error out. – dandavis Oct 25 '17 at 9:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.