[go: up one dir, main page]

Page MenuHomePhabricator

Application Security Review Request : swaggest/json-diff PHP library
Closed, ResolvedPublic

Description

Project Information

Description of the tool/project:
JSON diff/rearrange/patch/pointer library

Description of how the tool will be used at WMF:
Meant to be used to use JSON Patch (https://www.rfc-editor.org/rfc/rfc6902 / https://jsonpatch.com/) standard to edit Wikibase items using the upcoming Wikibase REST API.
Of WMF wikis, will be used at Wikidata initially.

Dependencies
No dependencies apart from PHP JSON extension as per project's composer.json

Has this project been reviewed before?
no

Working test environment

Please link or describe setup process for setting up a test environment.

Post-deployment

Name of team responsible for tool/project after deployment and primary contact.

Details

Risk Rating
Low

Event Timeline

sbassett triaged this task as Medium priority.Nov 21 2022, 9:10 PM

Hello @Reedy @sbassett as we've entered the final month of the quarter I respectfully dare to ask if you happen to be able to estimate whether the review would be likely concluded this quarter still, or would it continue into the first quarter of 2023? Asking to adjust WMDE's plans accordingly. Thanks!

HI @WMDE-leszek, my apologies but due to some unexpected resourcing issues we expect to complete this before the end of January. Again, we are sorry for the delay and will do our best to turn this out as soon as possible after the holiday break.

Thanks @Jcross! Not ideal news but we know we can plan with this, so thank you for the update.

sbassett changed the task status from Open to In Progress.Jan 4 2023, 5:16 PM
sbassett reassigned this task from Reedy to mmartorana.
sbassett moved this task from Upcoming Quarter Planning Queue to In Progress on the secscrum board.
sbassett added a subscriber: Reedy.

Hi @WMDE-leszek - I am going to post this security review within the next 3 weeks.

Security Review Summary - T316523 - 2023-01-20

Overall, the current vendor code under consideration appears to be in good shape per various security analyses performed below.
However: outdated packages, technical debt, maintainability, code cleanliness and overall usage/support require attention. For these reasons, I am assigning a risk rating of medium.

General Security Information

Statistic/InfoValueRisk
Repositoryhttps://github.com/swaggest/json-diff none
Relevant tag/branchv3.10.4 per 826548 none
Last commit reviewed (if relevant)f4e5117 none
Recent contributions to code (6 months)21 low
Active developers with > 10 commits1 high
Current overall usage178 stars, 27 forks medium
Current open security issues0 none
Methods for reporting security issuesnone medium

Vulnerable Packages
none

Outdated Packages
As reported via composer outdated:
(no explicit vulnerabilities reported, simply noting for completeness' sake.)

PackageCurrentWantedLatest (Remediation)
phperf/phpunit4.8.374.8.38
phpunit/php-token-stream1.4.12 criticalThis package is abandoned and no longer maintained. No replacement package was suggested.
phpunit/phpunit-mock-objects2.3.8 criticalThis package is abandoned and no longer maintained. No replacement package was suggested.
sebastian/exporter1.2.22.0.0
sebastian/recursion-context1.0.52.0.0

Scorecard score
5.6 / 10 medium
(see raw output: P42990)

General Security Issues

  1. gitleaks returned no results. low risk
  2. whispers returned no results. low risk
  3. scan scan:latest returned no results. low risk
  4. semgrep returned this issue:
src/JsonHash.php 
     php.lang.security.weak-crypto.weak-crypto
        Detected usage of weak crypto function. Consider using stronger alternatives.
        Details: https://sg.run/KlBn

         52┆ $itemHash = md5($itemPath . $this->xorHash($item, $itemPath), true);
          ⋮┆----------------------------------------
         67┆ $propertyHash = $propertyPath . md5($key, true) . $this->xorHash($value, $propertyPath);

Hello @mmartorana, thanks for the review. What is the expected procedure/what are the expected next steps? I'm willing to accept the security risk assessed. We'll work with the maintainer of the library on improving some of the pointed out issues but it is not a near-term improvement to expect, I suspect.
How should I accept the risk so that the library could be published to the WMF production environment?

Hi @WMDE-leszek - A risk rating of medium requires mitigations to reduce to a lower risk level or risk acceptance/ownership at the manager/director level at the WMF.

We've entered this as an accepted medium risk into the Security-Team's risk registry. If you have any questions, please first refer to our current (internal) risk management framework. If any risk treatment or mitigation plans are to be created, please feel free to follow up here with that information.

Thank you.

thanks @mmartorana -- please note that as WMDE staff I cannot access the risk management framework page as it is in WMF's internal wiki. Is there some more publicly available copy or subset of that framework?

Pardon my dumb question, does this:

We've entered this as an accepted medium risk into the Security-Team's risk registry.

mean the risk has been accepted and the use of library in WMF prod environment is fine or is the risk acceptance/ownership still pending? I fail to understand who has accepted the risk at the WMF's end -- if the question makes any sense.

Hey @WMDE-leszek -

As an engineering manager at WMDE, you can absolutely own risk for something deployed to Wikimedia production. For this instance of risk ownership, WMDE basically == WMF. I thought that WMDE folks had been given access to officewiki, but perhaps that is not the case. If you would like to review our current, fairly boilerplate risk management framework policy, we can either work to get you some kind of access to officewiki or I can transmit the contents of the current risk management framework to you some other way (Google docs, private Phab paste, etc.)

Thanks for the elaboration @sbassett.
I hereby accept the medium security risk of the library.
WMDE will however work on addressing some recognized issues and we might request re-assessing the risk at some later point.

Regarding the access to the risk management framework policy write up: We'd like to have a look certainly. I'd speculate getting WMDE staff access to officewiki might be a fairly convoluted effort (I will meanwhile ask my WMF contacts in higher ranks, we'll see what happens) so if there was some intermediate way, that'd be great. Which way to use ti share it I'd leave it at your discretion - we'd be fine with anything.
Thank you folks!

Thanks for the elaboration @sbassett.
I hereby accept the medium security risk of the library.
WMDE will however work on addressing some recognized issues and we might request re-assessing the risk at some later point.

No problem and thanks. Once any risks from this review have been confirmed mitigated, we're happy to reduce the risk of this component to low and remove it from our risk registry (low and/or no risk is automatically accepted by the WMF).

Regarding the access to the risk management framework policy write up: We'd like to have a look certainly. I'd speculate getting WMDE staff access to officewiki might be a fairly convoluted effort (I will meanwhile ask my WMF contacts in higher ranks, we'll see what happens) so if there was some intermediate way, that'd be great. Which way to use ti share it I'd leave it at your discretion - we'd be fine with anything.

Do you have a Google Suite-friendly email address? That might be the easiest way to securely share it with you - via a doc within the WMF's Google Suite. If you don't wish to publicly disclose an email address, feel free to find me on IRC or WMF's Slack instance, to which WMDE folks might now have access?

@mmartorana given we've accepted the risk please feel free to resolve this task or process it further, according to your processes. Thank you