Issues as result of security review #26
Description
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.
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.