You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The application uses $_REQUEST[''] to access a HTTP parameter(s) instead of explicitly using $_GET or $_POST; this allows for parameter pollution, enabling an attacker to potentially confuse and/or bypass certain business-logic in a security-sensitive authentication context.
It's strongly recommended to always explicitly use either $_GET or $_POST and not allow for both at the same time.
I understand this is an old 3rd party library, but it should still be addressed given it's sensitive context and an anti-pattern.
Title : Using a Vulnerable 3rd Party Component
Component: netresearch/jsonmapper
Priority: LOW
I.e. the application uses the 'video/psalm' component in the build-pipeline, which itself is dependant on the vulnerable library.
Since 1) this is a 'Dev/Test' dependency, we rate the impact lower than a 'Production dependency' and secondly 2) No exploitable path was observed (i.e. the application using the specific, vulnerable code-construct) - although that's not a 100% guarantee it's not used in the Dev/Test pipelines , 3) The impact is Denial of Service (i.e. undermining the Availability but NOT the Integrity and Confidiality) and lastly 4) There is no 'fix' / update available; we deem this a LOW priority in this context (i.e. not a HIGH as the screenshot might imply) for on the backlog and follow up within 3 months; i.e. we do want this addressed in the end-state, but it's not blocking for the release unless no other releases are planned within 3 to 6 months.
Title : Using 28 Outdated 3rd partyt Components / Possible Life-Cycle-Management (LCM) technical Debt.
Priority: LOW
As the screenshot shows; the application uses 28 outdated (but NOT vulnerable !) components (i.e. components with newer versions available, 2 of those (ralouphie/getallheaders@ 3.0.3 and paragonie/random_compat@ v9.99.100) are production dependencies; the other ones mere Dev/Test dependencies, which have a LOWER risk-rating, but given supplychain attacks are focusing on these Dev/Test dependencies recently - with successful attacks against well-known enterprises and organisations as a result), this does need addressing too.
Some components are a significant number of releases of years behind, implying there is no automated LCM (like for example using Dependabot) solution to address this. Using older components undermines the response capabilities whenever a vulnerability in such a component is found; i.e. when you're 99 versions behind, you'll probably need to do a lot of work to be able to upgrade to the latest version; the longer you wait the more complex & expensive this becomes, meaning a potential new vulnerability can (potentially) not be addressed in a timely fashion.
It's strongly recommended to update outdated components as part of the regular work-flow for each release, for example by automating it using something like the free & open source Dependabot and updating all these dependencies to the latest version for a next release. Given there are no vulnerabilities (yet !), the priority is set to LOW; it's more about improving the process than about doing the update once.
The text was updated successfully, but these errors were encountered:
security review has been done by the security team.
for the details see https://helpdesk.rdobeheer.nl/#ticket/zoom/10245 or below
1 HIGH
2 LOW
After discussion with Jaap he came to the conclusion that fixing the LOW LCM issue would be really nice to fix
Title : HTTP Parameter Pollution
File : BaseOpenIDConnectClient.php
Priority: HIGH
The application uses $_REQUEST[''] to access a HTTP parameter(s) instead of explicitly using $_GET or $_POST; this allows for parameter pollution, enabling an attacker to potentially confuse and/or bypass certain business-logic in a security-sensitive authentication context.
See also: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution
It's strongly recommended to always explicitly use either $_GET or $_POST and not allow for both at the same time.
I understand this is an old 3rd party library, but it should still be addressed given it's sensitive context and an anti-pattern.
Title : Using a Vulnerable 3rd Party Component
Component: netresearch/jsonmapper
Priority: LOW
I.e. the application uses the 'video/psalm' component in the build-pipeline, which itself is dependant on the vulnerable library.
Since 1) this is a 'Dev/Test' dependency, we rate the impact lower than a 'Production dependency' and secondly 2) No exploitable path was observed (i.e. the application using the specific, vulnerable code-construct) - although that's not a 100% guarantee it's not used in the Dev/Test pipelines , 3) The impact is Denial of Service (i.e. undermining the Availability but NOT the Integrity and Confidiality) and lastly 4) There is no 'fix' / update available; we deem this a LOW priority in this context (i.e. not a HIGH as the screenshot might imply) for on the backlog and follow up within 3 months; i.e. we do want this addressed in the end-state, but it's not blocking for the release unless no other releases are planned within 3 to 6 months.
Title : Using 28 Outdated 3rd partyt Components / Possible Life-Cycle-Management (LCM) technical Debt.
Priority: LOW
As the screenshot shows; the application uses 28 outdated (but NOT vulnerable !) components (i.e. components with newer versions available, 2 of those (ralouphie/getallheaders@ 3.0.3 and paragonie/random_compat@ v9.99.100) are production dependencies; the other ones mere Dev/Test dependencies, which have a LOWER risk-rating, but given supplychain attacks are focusing on these Dev/Test dependencies recently - with successful attacks against well-known enterprises and organisations as a result), this does need addressing too.
Some components are a significant number of releases of years behind, implying there is no automated LCM (like for example using Dependabot) solution to address this. Using older components undermines the response capabilities whenever a vulnerability in such a component is found; i.e. when you're 99 versions behind, you'll probably need to do a lot of work to be able to upgrade to the latest version; the longer you wait the more complex & expensive this becomes, meaning a potential new vulnerability can (potentially) not be addressed in a timely fashion.
It's strongly recommended to update outdated components as part of the regular work-flow for each release, for example by automating it using something like the free & open source Dependabot and updating all these dependencies to the latest version for a next release. Given there are no vulnerabilities (yet !), the priority is set to LOW; it's more about improving the process than about doing the update once.
The text was updated successfully, but these errors were encountered: