pboettch / json-schema-validator

JSON schema validator for JSON for Modern C++
Other
466 stars 134 forks source link

Error when validating CVE5 schema #226

Closed tsarquis88 closed 1 year ago

tsarquis88 commented 1 year ago

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

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
pboettch commented 1 year ago

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).

sebasfalcone commented 1 year ago

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

tsarquis88 commented 1 year ago

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.

sebasfalcone commented 1 year ago

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).

pboettch commented 1 year ago

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

tsarquis88 commented 1 year ago

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!

pboettch commented 1 year ago

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

sebasfalcone commented 1 year ago

Sure, on my way!

sebasfalcone commented 1 year ago

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

pboettch commented 1 year ago

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

sebasfalcone commented 1 year ago

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