NASA-IMPACT / csdap-cumulus

SmallSat Cumulus Deployment
Other
1 stars 1 forks source link

Snyk Medium Vulnerability: follow-redirects Information Exposure #396

Open hbparache opened 1 week ago

hbparache commented 1 week ago

Introduced through @cumulus/common@18.2.0 and @cumulus/cmrjs@18.2.0 Fixed in follow-redirects@1.15.6 Exploit maturity Proof of Concept Show less detail Detailed paths Introduced through: csdap-cumulus@1.0.0 › @cumulus/common@18.2.0 › follow-redirects@1.15.5 Fix: No remediation path available. Introduced through: csdap-cumulus@1.0.0 › @cumulus/cmrjs@18.2.0 › @cumulus/cmr-client@18.2.0 › @cumulus/common@18.2.0 › follow-redirects@1.15.5 Fix: No remediation path available. Introduced through: csdap-cumulus@1.0.0 › @cumulus/common@18.2.0 › @aws-sdk/signature-v4-crt@3.575.0 › aws-crt@1.21.0 › axios@1.6.5 › follow-redirects@1.15.5 Fix: No remediation path available. …and 1 more

Security information Factors contributing to the scoring: Snyk: CVSS v3.1 6.5 - Medium Severity NVD: Not available. NVD has not yet published its analysis. Why are the scores different? Learn how Snyk evaluates vulnerability scores Overview Affected versions of this package are vulnerable to Information Exposure due to the handling of the Proxy-Authorization header across hosts. When using a dependent library, it only clears the authorization header during cross-domain redirects but allows the proxy-authentication header, which contains credentials, to persist. This behavior may lead to the unintended leakage of credentials if an attacker can trigger a cross-domain redirect and capture the persistent proxy-authentication header.

ShreyNiraula commented 4 days ago

This issue occurs from follow-redirects library used by axios library that only removes the authentication header, keeping the information in proxy-authentication header during the cross-domain redirects. This can be solved by upgrading the version of follow-redirects to version 1.15.6 or higher. However, since it is from @cumulus, this needs to be fixed by Core team.

chuckwondo commented 4 days ago

However, since it is from @Cumulus, this needs to be fixed by Core team.

Ideally, yes, since this is not a direct dependency, but a transitive dependency through Cumulus, the Cumulus team should address this.

However, this does not mean we need to wait for them to fix vulnerabilities introduced via Cumulus transitive dependencies. The "resolutions" section of package.json is specifically designed to allow overriding transitive dependency versions. Thus, adding the following entry to that section should eliminate this vulnerability:

"@cumulus/**/follow-redirects": "^1.15.6",

This is the approach I suggest you take for all current Dependabot alerts stemming from Cumulus transitive dependencies.

Further, all alerts stemming from Gemfile.lock can be dismissed because that file is used strictly for the development Docker image, which is not deployed or exposed in any manner, so the identified vulnerabilities are moot. For each such alert, click the "Dismiss alert" button and choose "Vulnerable code is not actually used".

hbparache commented 4 days ago

Hi Chuck, thanks for your feedback. I didn't realize that we can dismiss vulnerabilities coming from Gemfile.lock, I will dismiss those.