Apache Johnzon

Reporting New Security Problems with Apache Johnzon

The Apache Software Foundation takes a very active stance in eliminating security problems and denial of service attacks against Apache projects.

We strongly encourage folks to report such problems to the private security mailing list first, before disclosing them in a public forum.

Please note that the security mailing list should only be used for reporting undisclosed security vulnerabilities in Apache projects and managing the process of fixing such vulnerabilities. We cannot accept regular bug reports or other queries at this address. All mail sent to this address that does not relate to an undisclosed security problem will be ignored.

If you need to report a bug that isn't an undisclosed security vulnerability, please use the bug reporting system.

###Questions about:

  • how to configure Johnzon securely
  • if a vulnerability applies to your particular application
  • obtaining further information on a published vulnerability
  • availability of patches and/or new releases

should be addressed to the mailing list.

The private security mailing address is: security (at) apache (dot) org

Known vulnerabilities are listed on the vulnerabilities page.

BigInteger and Java

JSON-P/JSON-B exposes API using BigDecimal and BigInteger. The bridge between these two types is BigDecimal#toBigInteger which has a slow implementation in Java without careness or scale max validation.

Johnzon does some sanity checks on this value but at some point we recommend you to stay away from these API and handle big numbers using String type and parse them yourself since you are the only ones knowing the correct functional and relevant validation of the scale before a instantiation.

If you know you don't need such big types, prefer using plain primitives (or wrappers).

JSON Schema validation

If you validate untrusted payloads with johnzon-jsonschema, prefer setting JsonSchemaValidatorFactory#setFailFast(boolean) to true.

By default all keywords of the schema are evaluated and all errors are aggregated. With fail fast enabled the first failing keyword stops the validation: since the cheap structural keywords (type, minItems/maxItems, minLength/maxLength, pattern, …) are evaluated before the expensive ones (uniqueItems, nested properties, …), a hostile payload is rejected without paying for the whole schema. The valid/invalid verdict is identical in both modes, only the number of reported errors changes.

See the JSON Schema section of the index page for more details.