JSONObject incorrectly accepts json with octal values

[wightwulf1944]

given:

{
	"MobileNumber": 09171234567
}

usage:

String jsonString = "{\n    \"MobileNumber\": 09171234567\n}";
JSONObject jsonObject = new JSONObject(jsonString);

expected:
JSONObject() should throw a JSONException because the input json string does not conform to RFC 4627 section 2.4 "Numbers" where it states...

Octal and hex forms are not allowed. Leading zeros are not allowed.

actual:
the octal value is coerced into a String upon construction of JSONObject and calling jsonObject.get("MobileNumber") returns a String

[johnjaylward]

Please see the README. It has a full explanation of this behavior and why it's allowed.

…

On Mon, Mar 25, 2019, 00:10 wightwulf1944 ***@***.***> wrote: given: { "MobileNumber": 09171234567 } usage: String jsonString = "{\n \"MobileNumber\": 09171234567\n}";JSONObject jsonObject = new JSONObject(jsonString); expected: JSONObject() should throw a JSONException because the input json string does not conform to RFC 4627 section 2.4 "Numbers" where it states... Octal and hex forms are not allowed. Leading zeros are not allowed. actual: the octal value is coerced into a String upon construction of JSONObject and calling jsonObject.get("MobileNumber") returns a String — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#465>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXa17XlrXWiA8f0a8EOs7blPcnPJWhQks5vaEwdgaJpZM4cGCLt> .

[johnjaylward]

Specifically this part of the README

In compliance with RFC7159 page 10 section 9, the parser is more lax with what is valid JSON than the Generator. For Example, the tab character (U+0009) is allowed when reading JSON Text strings, but when output by the Generator, tab is properly converted to \t in the string. Other instances may occur where reading invalid JSON text does not cause an error to be generated. Malformed JSON Texts such as missing end " (quote) on strings or invalid number formats (1.2e6.3) will cause errors as such documents can not be read reliably.

The Octal parsing falls into this category.

…

On Mon, Mar 25, 2019, 00:20 John Aylward ***@***.***> wrote: Please see the README. It has a full explanation of this behavior and why it's allowed. On Mon, Mar 25, 2019, 00:10 wightwulf1944 ***@***.***> wrote: > given: > > { > "MobileNumber": 09171234567 > } > > usage: > > String jsonString = "{\n \"MobileNumber\": 09171234567\n}";JSONObject jsonObject = new JSONObject(jsonString); > > expected: > JSONObject() should throw a JSONException because the input json string > does not conform to RFC 4627 section 2.4 "Numbers" where it states... > > Octal and hex forms are not allowed. Leading zeros are not allowed. > > actual: > the octal value is coerced into a String upon construction of JSONObject > and calling jsonObject.get("MobileNumber") returns a String > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#465>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAXa17XlrXWiA8f0a8EOs7blPcnPJWhQks5vaEwdgaJpZM4cGCLt> > . >

[wightwulf1944]

Thank you for the prompt reply. I now understand that JSONObject is lenient as long as the malformed json can be intuitively and reasonably parsed.

In case others have found this curious case, quoted below is the referenced RFC7159 page 10 section 9 "Parsers"

A JSON parser transforms a JSON text into another representation. A
JSON parser MUST accept all texts that conform to the JSON grammar.
A JSON parser MAY accept non-JSON forms or extensions.

For reference, is there any document that lists cases where JSONObject reasonably accepts malformed json? Or is there any way for JSONObject to enforce strict json specifications? Our usecase for this is we're not really parsing and extracting specific fields and values but just trying to validate the given json string. Given a list of leniency cases, we can implement a solution that catches those cases.

[johnjaylward]

For reference, is there any document that lists cases where JSONObject reasonably accepts malformed json? Or is there any way for JSONObject to enforce strict json specifications? Our usecase for this is we're not really parsing and extracting specific fields and values but just trying to validate the given json string. Given a list of leniency cases, we can implement a solution that catches those cases.

At this time, I don't think we have a single document that lists all cases in an explicit list. If you enjoy reading test cases, you can find many of the exception cases in those. (link in the README)

As for strict parsing, at this time it's not available in this library. It's been brought up before as a possible implementation option, but so far no one has suggested a merge request (see #240, #269, #325).

[johnjaylward]

so far I found these exception, although there may be more:

• Unquoted keys { key: "value" }
• Unquoted values { "key": value }
• Unescaped literals like "tab" in string values { "key": "value with an unescaped tab" }
• Numbers out of range for Double or Integer are parsed strings

It doesn't look like the parser supports Octal at all. The case you found is simply that the JSON parser doesn't recognize it as a number because of the leading 0.

[wightwulf1944]

The case you found is simply that the JSON parser doesn't recognize it as a number because of the leading 0.

I see so it falls under Unquoted values.

This list will suffice. We will try to explore JSONTokener's implementation with this in mind and perhaps make a StrictJSONTokener or something similar. Thank you for the detailed response. Me and my colleagues appreciate it.