-
Notifications
You must be signed in to change notification settings - Fork 0
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
Issues as result of security review #26
Comments
Thanks! This is great to deliver back to the community! I will create a PR in the https://github.com/jumbojett/OpenID-Connect-PHP project. |
@ricklambrechts did you report this in the community? If so, can you close this ticket? |
|
Allemaal opgelost of uit te leggen . . |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: