Submitting NVD API CVE Search by cpeName with special characters

106 Views Asked by At

I'm currently working on a NVD API query of CVEs based on cpeName. As I see a number of posts already related to the NVD API I can tell there are a lot of challenges which have come with it. One I am currently facing is querying the CVE API for vulnerabilities which apply to a cpeName with special characters.

Please reference the following documentation for the CVE-specific API endpoint:

https://nvd.nist.gov/developers/vulnerabilities

The very first parameter is to search by cpeName. Should be super easy. And it is! If the cpeName doesn't have special characters. The cpeName's I have retrieved using the CPE dictionary API contain special characters which are the ones I am using to reference this followup call to retrieve the CVEs.

Here is the dictionary search tool available for interactive use. This is where you can review the product details including the version 2.3 cpeName.

https://nvd.nist.gov/products/cpe/search

I did a debug when running the above search for "cpe:2.3:a:cisco:unified_contact_center_express:12.5(1):su1::::::" and see the request is actually being sent with URL encoding.

https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Acisco%3Aunified_contact_center_express%3A12.5%5C%281%5C%29%3Asu1%3A*%3A*%3A*%3A*%3A*%3A*

I took this information and ran with it to attempt using URL encoding against the CVE API which is: https://services.nvd.nist.gov/rest/json/cves/2.0

And cpeName is verified as: cpeName = cpe:2.3:a:cisco:unified_contact_center_express:12.5(1):su1::::::

With all of this in mind... fullUrl = "https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:cisco:unified_contact_center_express:12.5(1):su1::::::"

It isn't hard to see how backslashes and parenthesis might mess with things. I haven't even been able to get this to work in Postman let alone within my script. I've tried various forms patterns of URL encoding with no success. I've confirmed the content-type header is not necessary for the endpoint to support URL-Encoding of spaces but have not been able to confirm backlashes, parenthesis, or whatever pattern might be necessary to get this query to work. I would greatly appreciate any input or assistance in getting the above mentioned.

0

There are 0 best solutions below