Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulnerabilities missing due to user-agent #37

Open
ThomGeG opened this issue Jul 11, 2022 · 1 comment
Open

Vulnerabilities missing due to user-agent #37

ThomGeG opened this issue Jul 11, 2022 · 1 comment

Comments

@ThomGeG
Copy link

ThomGeG commented Jul 11, 2022

Apologies, as this is almost certainly the wrong place to be raising this but I didn't find anywhere more appropriate.

I'm currently using the lovely DependencyCheck plugin in a number of projects of mine and have noticed a discrepancy in reported vulnerabilities for at least one dependency depending on the user-agent used to make the request.

javax.mail:mail:1.5.0-b01 has 1 reported vulnerability, sonatype-2017-0492. When you use the below curl to grab any/all vulnerabilities, you'll receive it no problem.

curl -X 'POST' \
  'https://ossindex.sonatype.org/api/v3/component-report' \
  -H 'accept: application/vnd.ossindex.component-report.v1+json' \
  -H 'Content-Type: application/vnd.ossindex.component-report-request.v1+json' \
  -d '{
  "coordinates": [
    "pkg:maven/javax.mail/mail@1.5.0-b01"
  ]
}'
[{"coordinates":"pkg:maven/javax.mail/mail@1.5.0-b01","description":"","reference":"https://ossindex.sonatype.org/component/pkg:maven/javax.mail/mail@1.5.0-b01?utm_source=curl&utm_medium=integration&utm_content=7.80.0","vulnerabilities":[{"id":"sonatype-2017-0492","displayName":"sonatype-2017-0492","title":"1 vulnerability found","description":"1 non-CVE vulnerability found. To see more details, please create a free account at https://ossindex.sonatype.org/ and request for this information using your registered account","cvssScore":4.3,"cvssVector":"CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","cwe":"CWE-699","reference":"https://ossindex.sonatype.org/vulnerability/sonatype-2017-0492","externalReferences":[]}]}]

However if you add a user-agent starting with "dependency-check" then the response will no longer include the previously found vulnerability.

curl -X 'POST' \
  'https://ossindex.sonatype.org/api/v3/component-report' \
  -H 'accept: application/vnd.ossindex.component-report.v1+json' \
  -H 'Content-Type: application/vnd.ossindex.component-report-request.v1+json' \
  -A 'dependency-check/7.1.1 (Windows 10; 10.0; amd64; 11.0.14.1)' \
  -d '{
  "coordinates": [
    "pkg:maven/javax.mail/mail@1.5.0-b01"
  ]
}'
[{"coordinates":"pkg:maven/javax.mail/mail@1.5.0-b01","description":"","reference":"https://ossindex.sonatype.org/component/pkg:maven/javax.mail/mail@1.5.0-b01?utm_source=dependency-check&utm_medium=integration","vulnerabilities":[]}]

I've had a glance through the source code here in the hopes there's some piece of documentation that explains why the API server itself is being influenced in this manner by the user-agent but I haven't seen anything. My best guess is something around wanting to avoid reporting duplicate vulnerabilities for DependencyCheck since it's also going to search the NVD for them back when support for OSS was first added. In this case however, the vulnerability in question doesn't appear in the NVD.

Is anybody with access to the source for the API server or just a better background with this able to elaborate on the behavior? It's got me concerned there may be a small treasure trove of more reported vulnerabilities in the OSS Index I'm not seeing because I use DependencyCheck.

Cheers

@ThomGeG
Copy link
Author

ThomGeG commented Jul 12, 2022

I've done some searching through the issues in DependencyCheck and found when this behavior seems to have been added and why; jeremylong/DependencyCheck#4527

Looks like back in May Sonatype made some changes that weren't compatible with DependencyCheck, so to give them time to address it a temporary filter was applied to omit the offending entries when the requests were coming from DependencyCheck.

I'll post a question there as to what the plan was to remove the filtering, as it's still in place despite DependencyCheck having been updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant