jettison-json / jettison Goto Github PK

Description:

Initializing JSONObject with a string consisting of any of opening brackets ('{', '[') and ending with a slash '/' will result in stack overflow.

Minimal reproducible example:

import org.codehaus.jettison.mapped.*;
import org.codehaus.jettison.json.JSONObject;

public class Test {
    public static void main(String[] args) throws Exception 
        JSONObject obj = new JSONObject("{/");
    }
}

Log:

Exception in thread "main" java.lang.StackOverflowError
at java.base/java.lang.String.charAt(String.java:693)
at org.codehaus.jettison.json.JSONTokener.next(JSONTokener.java:124)
at org.codehaus.jettison.json.JSONTokener.nextClean(JSONTokener.java:177)
at org.codehaus.jettison.json.JSONTokener.nextValue(JSONTokener.java:326)
at org.codehaus.jettison.json.JSONObject.(JSONObject.java:218)
at org.codehaus.jettison.json.JSONTokener.newJSONObject(JSONTokener.java:424)
at org.codehaus.jettison.json.JSONTokener.nextValue(JSONTokener.java:335)
at org.codehaus.jettison.json.JSONObject.(JSONObject.java:218)
at org.codehaus.jettison.json.JSONTokener.newJSONObject(JSONTokener.java:424)
at org.codehaus.jettison.json.JSONTokener.nextValue(JSONTokener.java:335)
at org.codehaus.jettison.json.JSONObject.(JSONObject.java:218)
at org.codehaus.jettison.json.JSONTokener.newJSONObject(JSONTokener.java:424)
at org.codehaus.jettison.json.JSONTokener.nextValue(JSONTokener.java:335)
at org.codehaus.jettison.json.JSONObject.(JSONObject.java:218)
at org.codehaus.jettison.json.JSONTokener.newJSONObject(JSONTokener.java:424)
at org.codehaus.jettison.json.JSONTokener.nextValue(JSONTokener.java:335)
at org.codehaus.jettison.json.JSONObject.(JSONObject.java:218)

In the JSON to XML case, the MappedNamespaceConvention maps the namespace defined in the key of the JSON object to the parent node. This is not correct it must be mapped to the node.

For example, if you have the JSON docment

{"p1.A":{"p2.B":"value"}}

with the xml2JsonNs map:

Map<String, String> xml2JsonNs = new TreeMap<String, String>();
xml2JsonNs.put("http://namespaceOfElementA", "p1");
xml2JsonNs.put("http://namespaceOfElementB", "p2");

then you get currently the result

However correct would be

I attached the patch.

Meanwhile I detected further problems concerning the namespace handling.

if you have the JSON document
{"simple.root":{"WithoutNs":"value"}}
then you currently get as XML
value
But correct is:
value
because the element "WithoutNS" does not have a namespace.

Secondly the attribute NS are not treated correctly:
If you have
{"simple.root":{"WithoutNs":
{"@ns.attrNs":"ans_v","$":"value"}

}}
then you get
value
But correct is :
value

So I updated the patch to correct these errors also.

Meanwhile my impression is that it would be better to use also for the elements prefixes in the XML because you need the prefixes anyway for the attributes with namespaces.

Regards Franz Forsthofer

Here are my comments to the patch: very good idea to abstract the details of how the sequence is read but unfortunately the way it is implemented it is too intrusive for the existing consumers of JsonObject/JsonArray.

Let me suggest a minor improvement to your patch, the idea stays the same but we will keep the existing code intact.

You've introduced JsonTokenerAbstract as the base 'interface'. Instead we should have an actual interface introduced, say 'JsonTokenerProvider'. Next you have your JsonTokenerAbstract implementing JsonTokenerProvider, where JsonTokenerProvider has the methods which are currently marked as abstract in JsonTokenerAbstract.
Introduce two JsonTokenerProvider interface implementations, both indeed extending JsonTokenerAbstract: one would use the existing String based JsonTokener, the other one would be a Reader based.
Add new constructors to JsonObject/etc accepting JsonTokenerProvider interface and Reader.
update existing constructors accepting JsonTokener by wrapping it into one of JsonTokenerProvider implementations and delegating to the constructor accepting JsonTokenerProvider. Similarly for new constructors accepting Reader.

Hello. We've encountered a problem with escaping after upgrading from 1.5.1 to 1.5.2. The case "\\" is converted into \"\\\\" which is not a valid JSON. As far as I can see the issue comes from the new logic added at JSONObject.quote(String string, boolean escapeForwardSlashAlways), lines 1044-1049.

For text only elements, it is possible to read the content in START_ELEMENT event using getElementText(). The getElementText() should read the characters, and set the current event to END_ELEMENT. See here: http://java.sun.com/webservices/docs/1.5/api/javax/xml/stream/XMLStreamReader.html#getElementText()
But now, the current event after getElementText() is CHARACTERS, which is causing problems. It should be END_ELEMENT.

We use the cxf which use the jettison as the default json provider. The single element array cannot be serialized correctly. Is it fixed in the latest two version?

Hi Team,

I upgraded my application from Jettision 1.2 to 1.5.3 and now strangely i am seeing the error
"NoClassDefFoundError org/codehaus/jettison/json/JSONException"

i am importing org.codehaus.jettison.json.JSONException;

however instead of JSONException if i use generic exception my application is working fine
but if i use JSONException then i am facing NoClassDefFoundError

Issue seen after upgrading to 1.5.3

It is not possible to turn off the escaping of forward slashes in JSON Arrays.

please debug below code, it will burn one CPU, and stuck on JSONTokener L179 ~ 188 -> next() -> back() -> next()

public static void main(String[] args) {
		String str = "[*/*A25] **";
		try {
			System.out.println("start");
			System.out.println(new JSONArray(str));
			System.out.println("end");
		} catch (JSONException e) {
			e.printStackTrace();
		}
	}

public Response list(){
JSONObject json = new JSONObject(infoService.listEnvironment());
return Response.status(HttpStatus.SC_OK).entity(json.toString()).build();
}

Calling .toString(int indentFactor) results in undesired output. Interestly enough, the indent factor does apply to adjacent array elements, but does not apply to objects.

Code:

String json = "{ \"policies\": { \"Certificates\": { \"ImportEnterpriseRoots\": true } } }";
System.out.println(new JSONObject(json).toString(2));
                                             //  ^-- indentFactor

Expected results:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Actual results:

{"policies": {"Certificates": {"ImportEnterpriseRoots": true}}}

Hello fellow programmers,

I'm using the jettison library in a project and I stumbled upon a strange case when using the ignored elements in a Mapped convention.
When I try to ignore an element which is somewhere in the middle of an xml, the result JSON contains two commas in a row (",,"), which results in an invalid JSON structure.
I've debugged the library and it appears that in method JSONObject.write() the flag "b" is never reset to "false" inside the while loop.

current snippet of code:

 while (keys.hasNext()) {
                if (b) {
                    writer.write(',');
                }

Suggested change:

 while (keys.hasNext()) {
                if (b) {
                    writer.write(',');
                    b = false;
                }

Would you please fix it and provide a new release?

PoC when initializing a JSONArray:

public class POC {
    public static void main(String[] args) throws JSONException {
        ArrayList<Object> list = new ArrayList<>();
        list.add(list);
        JSONArray jsonArray=new JSONArray(list);
    }
}

The result:

PoC when adding the list to an existing JSONArray:

public class POC {
    public static void main(String[] args) throws JSONException {
        ArrayList<Object> list = new ArrayList<>();
        list.add(list);
        JSONArray jsonArray=new JSONArray().put(list);
    }
}

The result:

If the issue is indeed exploitable, we can create a CVE entry after the fixed version is released since we are a CNA.

19ae19f introduced a recursion check in JSONTokener, which however seems to be computing recursion depth incorrectly - it increments the counter on every new object or array, but never decrements it, essentially counting number of created non-primitive objects instead of recursion depth. This leads to an JSONException being thrown whenever total object count exceeds the limit (500 by default), regardless of recursion level.

new JSONObject().setRecursionDepthLimit(10);
JSONArray json = new JSONArray("[{}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {a:10}]");

produces

Exception in thread "main" org.codehaus.jettison.json.JSONException: JSONTokener has reached recursion depth limit of 10
	at org.codehaus.jettison.json.JSONTokener.checkRecursionDepth(JSONTokener.java:440)
	at org.codehaus.jettison.json.JSONTokener.newJSONObject(JSONTokener.java:428)
	at org.codehaus.jettison.json.JSONTokener.nextValue(JSONTokener.java:339)
	at org.codehaus.jettison.json.JSONArray.<init>(JSONArray.java:145)
	at org.codehaus.jettison.json.JSONArray.<init>(JSONArray.java:175)

On a side note, the decision to make the setter for static JSONObject.RECURSION_DEPTH_LIMIT non-static seems rather unfortunate to me - see the code snippet for how awkward the use seems to be.

As Jettison itself requires Java 1.6, can the dependency on StAX be removed, as it is included in the JDK from version 1.6? Not a huge deal, but should be a quick win for some dependency housekeeping :)

We exclude stax-api when depending on Jettison, and everything works.

Make jettison JDK 10+ compliant as there is some fine tuning of the xml api in JDK.

For example https://docs.oracle.com/javase/9/docs/api/javax/xml/namespace/NamespaceContext.html#getPrefixes-java.lang.String- says Iterator getPrefixes​(String namespaceURI)

Java 10 and 11 code says now: Iterator<String> getPrefixes(String namespaceURI);

https://github.com/jettison-json/jettison/blob/master/src/main/java/org/codehaus/jettison/mapped/MappedNamespaceConvention.java#L194 has method public Iterator<Object> getPrefixes( String arg0 ) {

As the change is in generics, it's "just" compile time issue, runtime should be fine.

I noticed this when compiling RESTEasy with JDK11 where I received return type java.util.Iterator<java.lang.Object> is not compatible with java.util.Iterator<java.lang.String>:

[ERROR] /Users/rsvoboda/git/Resteasy/providers/jettison/src/main/java/org/jboss/resteasy/plugins/providers/jaxb/json/MappedConvention.java:[13,8] getPrefixes(java.lang.String) in org.codehaus.jettison.mapped.MappedNamespaceConvention cannot implement getPrefixes(java.lang.String) in javax.xml.namespace.NamespaceContext
[ERROR]   return type java.util.Iterator<java.lang.Object> is not compatible with java.util.Iterator<java.lang.String>

Jettison fails to serialize a list of beans when bean's name matches one of its attributes' with the first letter capitalized, e.g. bean class TestItem with a field testItem.

Apparently, it fails serializing nested elements with the same name. The following structure:

produces:

javax.xml.stream.XMLStreamException: Too many closing tags.
at org.codehaus.jettison.mapped.MappedXMLStreamWriter.writeEndElement(MappedXMLStreamWriter.java:246)
at org.apache.cxf.staxutils.DelegatingXMLStreamWriter.writeEndElement(DelegatingXMLStreamWriter.java:123)
at org.apache.cxf.jaxrs.provider.json.utils.JSONUtils$IgnoreContentJettisonWriter.writeEndElement(JSONUtils.java:255)

However, a single item:

is transformed into

{"testItem":{"testItem":"item"}}

normally.

When using JettisonMappedXmlDriver driver for serializing with jettsion 1.5.4 version, it serialize array object as json object when array object contains only one element in it, if it contains more than 1 element it is serialized as array object

For example: here donneesFlexibles is a list and when it contains only one element it is serialized in response as object(like json object) instead of array object

'donneesFlexibles' contains single element and it is serialized as like json object by wrapping it with { } around single element (note: when it has more than 1 element, it is serialized as array)

"donneesFlexibles": {
                            "@class": "linked-list",
                            "com.test.DonneeFlexible": {
                                "cle": "numeroInternational",
                                "valeur": "non"
                            }
                        }

When the same object serialized by JsonHierarchicalStreamDriver: -- here it has [ ] around single element which represent donneesFlexibles as array even if it contains only one element

"donneesFlexibles": [
                        {
                            "cle": "numeroInternational",
                            "valeur": "non"
                        }
                    ]

While parsing this type of response, consumer may get typeError when expecting array but got object
May we know is there any reason for designing jettsion serialization this way ? It would be more meaningful if we represent the object structure as its data type irrespective of the number of elements in it.

Technically it is correct because '16x16' is not a valid XML name. However it might make sense to configure Jettison to not report such elements or replace illegal characters somehow, etc...

See https://issues.sonatype.org/browse/OSSRH-23669

Hi maintainers! I raised a few PRs a couple of weeks ago (#41, #42, #43) that represent fixes and features that we use in an internal fork of Jettison and that we think would be useful to the community - not to mention, making it easier for us to consume internally.

There's not been any conversation on them in a couple of weeks, and I can't help noticing that the last activity on master was @dkulp moving to the next development version and that was a couple of years ago now.

So this is really a zero-pressure question: is there likely to be activity on Jettison in the near future, merging PRs or creating releases? If so, then great; if not, then at least we know to continue our own forked activity.

Hi,

I am using CXF with jettison and it looks like jettison as json parser didn't handle unicode character escape.

e.g. google response from OIDC userinfo API:

{
  "sub": "00000000000000000",
  "name": "Michal Hlaváč",
  "given_name": "Michal",
  "family_name": "Hlaváč",
  "profile": "https://plus.google.com/00000000000000000",
  "picture": "https://lh3.googleusercontent.com/a-/AOh14GgPG0866eC-84EjXGai_LFUaqDnmWORLGe3jPvN1A\u003ds96-c",
  "email": "[email protected]",
  "email_verified": true,
  "gender": "male",
  "locale": "en"
}

If you parse this with javascript or jackson, unicode characater \u003d from picture key is correctly decoded as =, but jettison returns string with \u003d.

JSONObject do support octal and hexadecimal numbers (0777, 0xABCD), but JSON.org states that JSON does not support them, and ES5 goes as far as forbidding them http://es5.github.com/#B.1
Since extra leading zeros might creep in the input, I think it's better to ignore them than return a completely different number from the one intended (how often does one use octal nowadays? except in chmod parameters, maybe...)

An extended constructor need to be used to turn off forward slash escaping. This is not so convenient. It would be great to have a setter to change this setting on an already created object.

With the latest version it is no longer possible to enfore array handling for an element. Actually the serializeAsArray flag triggers non-symmetric behavior of Jettison between its reader and writer. See following unit tests, that represent XStream's internal call sequence and which succeed with Jettison 1.2.

{code:java}
public void testJettisonArraysAreBroken() throws XMLStreamException {
final MappedXMLOutputFactory mof;
final MappedXMLInputFactory mif;
final Configuration config = new Configuration();
mof = new MappedXMLOutputFactory(config);
mif = new MappedXMLInputFactory(config);
ByteArrayOutputStream out = new ByteArrayOutputStream();
XMLStreamWriter writer = mof.createXMLStreamWriter(out);
((AbstractXMLStreamWriter)writer).serializeAsArray("list");
writer.writeStartDocument();
writer.writeStartElement("list");
writer.writeStartElement("string");
writer.writeCharacters("a");
writer.writeEndElement();
writer.writeStartElement("string");
writer.writeCharacters("b");
writer.writeEndElement();
writer.writeEndElement();
writer.writeEndDocument();
writer.close();
assertEquals("{'list':[{'string':['a','b']}]}".replace(''', '"'), out.toString());
ByteArrayInputStream in = new ByteArrayInputStream(out.toByteArray());
XMLStreamReader reader = mif.createXMLStreamReader(in);
assertEquals(XMLStreamConstants.START_ELEMENT, reader.next());
assertEquals("list", reader.getLocalName());
assertEquals(XMLStreamConstants.START_ELEMENT, reader.next());
assertEquals("string", reader.getLocalName());
assertEquals(XMLStreamConstants.CHARACTERS, reader.next());
assertEquals("a", reader.getElementText());
assertEquals(XMLStreamConstants.END_ELEMENT, reader.next());
assertEquals(XMLStreamConstants.START_ELEMENT, reader.next());
assertEquals("string", reader.getLocalName());
assertEquals(XMLStreamConstants.CHARACTERS, reader.next());
assertEquals("b", reader.getElementText());
assertEquals(XMLStreamConstants.END_ELEMENT, reader.next());
assertEquals(XMLStreamConstants.END_ELEMENT, reader.next());
}

public void testJettisonSingleElementArraysAreBroken() throws XMLStreamException {
    final MappedXMLOutputFactory mof;
    final MappedXMLInputFactory mif;
    final Configuration config = new Configuration();
    mof = new MappedXMLOutputFactory(config);
    mif = new MappedXMLInputFactory(config);
    ByteArrayOutputStream out = new ByteArrayOutputStream();
    XMLStreamWriter writer = mof.createXMLStreamWriter(out);
    ((AbstractXMLStreamWriter)writer).serializeAsArray("list");
    writer.writeStartDocument();
    writer.writeStartElement("list");
    writer.writeStartElement("string");
    writer.writeCharacters("a");
    writer.writeEndElement();
    writer.writeEndElement();
    writer.writeEndDocument();
    writer.close();
    assertEquals("{'list':[{'string':'a'}]}".replace('\'', '"'), out.toString());
    ByteArrayInputStream in = new ByteArrayInputStream(out.toByteArray());
    XMLStreamReader reader = mif.createXMLStreamReader(in);
    assertEquals(XMLStreamConstants.START_ELEMENT, reader.next());
    assertEquals("list", reader.getLocalName());
    assertEquals(XMLStreamConstants.START_ELEMENT, reader.next());
    assertEquals("string", reader.getLocalName());
    assertEquals(XMLStreamConstants.CHARACTERS, reader.next());
    assertEquals("a", reader.getElementText());
    assertEquals(XMLStreamConstants.END_ELEMENT, reader.next());
    assertEquals(XMLStreamConstants.END_ELEMENT, reader.next());
}

{code}

Hi all,

I have prepared the integration CodeIntelligenceTesting/oss-fuzz@d1c2376 of jettison into google oss-fuzz. This will enable continuous fuzzing of this project, which will be conducted by Google. Bugs that will be found by fuzzing will be reported to you.

The integration requires a primary contact, someone to deal with the bug reports submitted by oss-fuzz. The email address needs to belong to an established project committer and be associated with a Google account as per here. This will provide you with access to ClusterFuzz, crash reports, and fuzzer statistics. More than 1 person can be included. Please let me know who I should include, if anyone.

Ideally, the fuzz tests would live in this repo (jettison) instead of the oss-fuzz repo to better stay in sync with the code. We can create a PR to do that if you are interested.

Jazzer is used for fuzzing Java applications. Jazzer is a coverage-guided, in-process fuzzer for the JVM platform developed by Code Intelligence. It is based on libFuzzer and brings many of its instrumentation-powered mutation features to the JVM.
Jazzer has already found a lot of critical bugs in JVM applications.

Please let me know if you have any questions regarding fuzzing or the oss-fuzz integration.

poc as follow:

public class POC {
    public static void main(String[] args) throws JSONException {


            HashMap<String,Object> map=new HashMap<>();
            map.put("t",map);
            JSONObject jsonObject=new JSONObject(map);

    }
}

and the result:

Hi Colleagues,

The vulnerabilities CVE-2022-40149 and CVE-2022-40150 were fixed as a part of 1.5.1 version of Jettison. However we use 1.3.7 and 1.4.1 in two different projects. Are there any breaking changes in 1.5.1 compared to 1.3.7 or 1.4.1? Or is it safe to upgrade to 1.5.1 already?

Hi,

We need to upgrade from 1.2 to 1.5.4 to resolve CVE
Which incompatibility or breaking change exist ?

Regards

at org.codehaus.jettison.json.JSONTokener.syntaxError(JSONTokener.java:463)
at org.codehaus.jettison.json.JSONObject.(JSONObject.java:206)
at org.codehaus.jettison.json.JSONObject.(JSONObject.java:313)

and then it cites the JSON where "{" is in the first position ?!?!

==> it turns out the by moving the json file from Windows to the invisble "\uFEFF" is prefixed (byte order mark (BOM))

==> please visualize that too !

Sorry to reach you again.
Currently we found another cve reported on json-java https://nvd.nist.gov/vuln/detail/CVE-2023-5072 , due to the license reference to json-java, our scan tool BDBA also reported this vulnn on jettison.
Would you help assess that if jettison is affected by the vulnn? According to their fix,The enhancement occurs on JSONObject.
stleary/JSON-java#758
stleary/JSON-java#771

Originally posted by @ChewuuHi in #77 (comment)

reproduced case as follow:

public class poc {


    public static void main(String[] args) throws  JSONException {


        String s="{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{";
        new JSONObject(s);
    }
}

the result as follow:

stack overflow
It's a feature of the JavaScript language, documented in the ECMAScript standard (3rd edition section 7.3), that the U+2028 and U+2029 characters count as line endings. Consequently a JavaScript parser will treat any unencoded U+2028/9 character in the same way as a newline. Since you can't put a newline inside a string literal, you get a syntax error.

... therefore it looks like the JSONObject#quote(String string, boolean escapeForwardSlashAlways) should escape these two unicode characters too.

Here is the fix based on HEAD code, which works for me.

    public static String quote(String string, boolean escapeForwardSlashAlways) {
        if (string == null || string.length() == 0) {
            return "\"\"";
        }

        char         c = 0;
        int          i;
        int          len = string.length();
        StringBuilder sb = new StringBuilder(len + 4);
        String       t;

        sb.append('"');
        for (i = 0; i < len; i += 1) {
            c = string.charAt(i);
            switch (c) {
            case '\\':
            case '"':
                sb.append('\\');
                sb.append(c);
                break;
            case '/':
            	if (escapeForwardSlashAlways || i > 0 && string.charAt(i - 1) == '<') {
                    sb.append('\\');
            	}
                sb.append(c);
                break;
            case '\b':
                sb.append("\\b");
                break;
            case '\t':
                sb.append("\\t");
                break;
            case '\n':
                sb.append("\\n");
                break;
            case '\f':
                sb.append("\\f");
                break;
            case '\r':
                sb.append("\\r");
                break;
            case '\u2028':
                sb.append("\\u2028");
                break;
            case '\u2029':
                sb.append("\\u2029");
                break;
            default:
                if (c < ' ') {
                    t = "000" + Integer.toHexString(c);
                    sb.append("\\u" + t.substring(t.length() - 4));
                } else {
                    sb.append(c);
                }
            }
        }
        sb.append('"');
        return sb.toString();
    }

Thank You ;-)

For example, the description of optBoolean is

     * Get an optional boolean associated with a key.
     * It returns the defaultValue if there is no such key, or if it is not
     * a Boolean or the String "true" or "false" (case insensitive).

But actually it returns the defaultValue only when the key is not in the json, and throws a RuntimeException in other cases.

    public boolean optBoolean(String key, boolean defaultValue) {
        Object o = opt(key);
        if (o == null) {
        	return defaultValue;
        } else {
        	try {
        	    return doGetBoolean(key, o);
        	} catch (JSONException ex) {
        		throw new RuntimeException(ex);
        	}
        }
    }

Hi:

Below security vulnerability is detected by security scan tool BlackDuck. Not sure if it is false alarm but to put the issue here for reference.

BDSA-2022-3278
Description
Jettison is vulnerable to denial-of-service (DoS) due to an unspecified parsing issue which can lead to an out-of-memory error. An attacker could exploit this vulnerability by supplying an application with maliciously crafted XML or JSON.

JSON mapped attributes with values of non string data types produce an error when the builder attempts to parse the stream. The following have been observed to fail when specified as values:

1 numeric (with no quotes)
2 boolean (with no quotes)
3 a subset of escaped characters inside a quoted string (e.g.'\b' backspace ascii x08)
4 null

These are all legal values in the JSON spec. http://www.ietf.org/rfc/rfc4627.txt You can use this as a guideline for what to verify.

The case of string with only "[" is badly managed

When declaring a TypeConverter, it properly runs if the Java field is of type String but if it is of type Object in which case XStream puts the runtime type in a class attribute, the TypeConverter never runs.

The problem is in the MappedXMLStreamWriter.JSONPropertyObject class in the withProperty method as well as in MappedXMLStreamWriter.JSONPropertyString.
Current implementation:

Object value = property.getValue();
if (add && value instanceof String) {
  value = this.convention.convertToJSONPrimitive((String)value);
}

Suggested implementation idea (needs exception handling etc):

Object value = property.getValue();
if (add && value instanceof String) {
  value = this.convention.convertToJSONPrimitive((String)value);
} else if (add && value instanceof JSONObject && "string".equals(value.get("@class"))) {
  value.put("$",  this.convention.convertToJSONPrimitive((String)value.get("$")));
}

It looks like the changes made to the processAttributesAndNamespaces(Node n, JSONObject object) method in the MappedNamespaceConvention.java source back in the 2.0 release, no longer processes no prefix attributes correctly. In the 1.0 release, the following JSON:

{ "toy": { "@xmlns": "http://examples.com" }}

Produced the following XML, when converted:

<toy xmlns="http://examples.com"/>

It no longer does that, starting with the 2.0 release. One possible fix is to add:

if (o instanceof String) {
    String uri = o.toString();
    QName name = new QName( XMLConstants.DEFAULT_NS_PREFIX, k );
    n.setAttribute(name, uri); 
}

after the following if statement:

if ( o instanceof JSONObject ) {
    JSONObject jo = (JSONObject) o;
     for (Iterator<?> pitr = jo.keys(); pitr.hasNext();) {
         // set namespace if one is specified on this attribute.
         String prefix = (String) pitr.next();
         String uri = jo.getString( prefix );
         //                            if ( prefix.equals( "$" ) ) {
         //                                prefix = "";
         //                            }

        n.setNamespace( prefix, uri );
    }
}

Dear Jettison maintainers,

Multiple bugs were found during fuzzing by Jazzer in Jettison, for example [Out of memory and Stackoverflow]. We would like to provide you with access to the bugs at Google OSS-Fuzz before they get publicly disclosed.

What do we need from you?

We need an email address that is associated with a Google Account as per Accepting new projects. In the past we have already contacted you during the onboarding of your project, but the request was rejected or no email was shared with us.

What do you get by sharing your email address?

When a bug is found, you will receive an email that will provide you with access to ClusterFuzz, crash reports, code coverage reports and fuzzer statistics. Each finding will have a crashing input that you can use to easily reproduce the bug.

Attention: All bug details will be made public automatically after the deadline of 90 days has exceeded or after the fix is released. For projects without maintainers we will do our best to support the disclosure process. Depending on our resources we will try to create an issues for every bug in your public issues tracker. In addition, we will request CVEs for security related vulnerabilities.

Please let me know if you have any questions regarding fuzzing or the OSS-Fuzz integration.

Thank you for your reading and hope to hear from you soon!

I was under impression that it preserve the oder as how the object is created. I read it some where online. can you clarify? thanks.

Better a self-explanatory example

Collection collectionStrings = new ArrayList();
collectionStrings.add("a");
collectionStrings.add("b");

String[] arrayStrings = new String[]{"x", "y"};

JSONObject jo = new JSONObject();
jo.put("collection", collectionStrings);
jo.put("array", arrayStrings);

System.out.println(jo);

@@ OUTPUT @@
{"collection":["a","b"],"array":"[Ljava.lang.String;@7106e68e"}

From my point of view, JSONObject should handle properly the array and print ["x", "y"] instead of calling the method toString() of the array.

List results = new ArrayList();
results.add("aaa");
results.add(1L);
results.add("bbb");
results.add(2L);

expected result:
{"result":{"list":[
{"string":"aaa","long":1,"string":"bbb","long":2}

]}}
but actual:
{"result":{"list":[
{"string":["aaa","bbb"],"long":[1,2]}

]}}

Jettison seems to auto-merge the elements with same type, which saves space, but is incorrect behaviour. The order of a list is important and needs to be kept.

Have the ability to set a limit certainly but please remove the new default behavior and feel bad about adding it.

jettison includes json-java code（ org/codehaus/jettison/json), so BDBA detected dependency json-java with unknown version on jettison and reported CVE-2022-45688.
CVE-2022-45688:
A stack overflow in the XML.toJSONObject component of hutool-json v5.8.10 allows attackers to cause a Denial of Service (DoS) via crafted JSON or XML data.

Since jettison forks parts of json-java code and maintained by your own, is the latest version 1.5.4 really affected by this vulnerability?
From the fix commit(for CVE-2022-45688) in json-java, it seems affects the class that jettison doesn't include at all?

It would appreciated that jettison can help confirm the information if it's affected. Thanks.