pboettch/json-schema-validator

Error when validating CVE5 schema

Closed this issue · 11 comments

I'm trying to validate some json files against the official CVE5 json schema, but the schema-validator fails even with a CVE5 basic example. Apparently, the lib is failing in this line.

I've managed to validate this schema in jsonchemavalidator.net.

Steps to reproduce

  • Build lib (out-of-source)
  • ./json-schema-validate CVE_JSON_5.0_bundled.json < basic-example.json

Expected behaviour

Validation of the schema without errors

Current behaviour

ERROR: '""' - '{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Example Enterprise","vendor":"Example.org","versions":[{"lessThan":"1.0.6","status":"affected","version":"1.0.0","versionType":"semver"}]}],"descriptions":[{"lang":"en","value":"OS Command Injection vulnerability parseFilename function of example.php in the Web Management Interface of Example.org Example Enterprise on Windows, MacOS and XT-4500 allows remote unauthenticated attackers to escalate privileges.\n\nThis issue affects:\n  *  1.0 versions before 1.0.6\n  *  2.1 versions from 2.16 until 2.1.9."}],"problemTypes":[{"descriptions":[{"description":"CWE-78 OS Command Injection","lang":"en"}]}],"providerMetadata":{"orgId":"b3476cb9-2e3d-41a6-98d0-0f47421a65b6"},"references":[{"url":"https://example.org/ESA-22-11-CVE-1337-1234"}]}},"cveMetadata":{"assignerOrgId":"b3476cb9-2e3d-41a6-98d0-0f47421a65b6","cveId":"CVE-1337-1234","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.0"}': no subschema has succeeded, but one of them is required to validate
schema validation failed

This is due to the schema needing a uri-format-validation. Some fields in it are using "format": "uri" which is by default not supported by this library. See here: https://github.com/pboettch/json-schema-validator/blob/main/src/string-format-check.cpp

What you can do in your application is to provide a custom checker (at validator creation time) which will handle or ignore uri and thus the instances to be validated.

Or, even, contribute a URI-checker to the library. (Maybe by using the json-uri stuff which is already there).

I've added a simple else-if that catches that case (doesn't check for a valid uri) and the same error arises

We will keep testing this out

As @sebasfalcone says, after adding

if (format == "uri") {
    return;
}
...

the lib validates correctly the basic-example. But, if I edit the basic-example and force it to not being compliant with the schema, the same error arises.

First problem:

no subschema has succeeded, but one of them is required to validate error message when validating against valid jsons.

Solution

Add a validator for URI on the string-format-check.cpp file (working on it)


"New" problem

no subschema has succeeded, but one of them is required to validate error message when validating against invalid jsons. This is not all that wrong but would be nice to have a good error message.

I believe this is related to this method and the way it handles errors (as you stated on the comment).

Yeah, there is a branch where the subschema-validation-error gets more explicit, but it hasn't been merged, because... I don't remember - lack of time. Please check this branch to see whether this improves your situation. https://github.com/pboettch/json-schema-validator/tree/error-check

Now, at error-check branch, I have the same behaviour but with another error message:

required property 'rejectedReasons' not found in object

But it's weird because the basic-example should not have the rejectedReasons key on it. Looks like the problem is more obscure than the uri validation...

At the moment, we can use the lib to validate compliant jsons.

By the way, thanks for the support on this!

I merged the uri-check, could you please retry?

Sure, on my way!

Works like a charm. Tested with nlohmann 3.8.0

PD: we were usign 3.7.3 before, now we where forced to upgrade to 3.8.0

nlohmann keeps a nice backward compatibility IIRC. You could go up to the latest version IMO.

I'am sure of that. But its a big project and a decision like that need a lot of approvals and justifications

By the way, we can close this issue <3
Thank you for all the help