No Verification for Humanity ID Correspondence to Owner in receiveUpdate Function

[hats-bug-reporter]

Github username: --
Twitter username: --
Submission hash (on-chain): 0x5be1e274fa90c11cb4d2ed09f55f2a65b015bdb750ed9959dc9aa7736d96b740
Severity: medium

Description:
Description
The receiveUpdate function in the CrossChainProofOfHumanity contract does not verify that the provided _humanityId corresponds to the _owner before updating the humanity data. This could potentially be exploited if a malicious actor were able to call this function through an approved gateway with incorrect data, leading to incorrect or Incorrect updates to the humanity data.

Attack Scenario
Describe how the vulnerability can be exploited.

Attachments

1. Proof of Concept (PoC) File

The affected function is receiveUpdate in the CrossChainProofOfHumanity contract:

 function receiveUpdate(
        address _owner,
        bytes20 _humanityId,
        uint40 _expirationTime,
        bool _isActive
    ) external override allowedGateway(msg.sender) {//@audit-no verification of owner
        CrossChainHumanity storage humanity = humanityData[_humanityId];

        // Clear humanityId for past owner
        delete accountHumanity[humanity.owner];

        if (_isActive) {
            accountHumanity[_owner] = _humanityId;
            humanity.owner = _owner;
        } else delete humanity.owner;

        humanity.expirationTime = _expirationTime;

        // If it received update from another chain `isHomeChain` flag is marked as false
        //         in order to avoid bridging state update of an removed / expired humanity
        humanity.isHomeChain = false;//@check-this can be used to trick transferHuanity() check?

        emit UpdateReceived(_humanityId, _owner, _expirationTime, _isActive);
    }

• Expected Behavior :
  The function should verify that the _humanityId corresponds to the _owner before updating the humanity data. If the verification fails, the function should revert with an appropriate error message.

• Actual Behavior :
  The function updates the humanity data without verifying that the _humanityId corresponds to the _owner, potentially leading to incorrect or malicious updates.

Note

2. Revised Code File (Optional)

• Add a verification step in the receiveUpdate function to ensure that the _humanityId corresponds to the _owner before updating the humanity data.

[clesaege]

This could potentially be exploited if a malicious actor were able to call this function through an approved gateway with incorrect data, leading to incorrect or Incorrect updates to the humanity data.

So it looks like this report is saying is "If there is a vuln on another platform, there will be vuln there". Here your report assumes the existence of a vuln ("malicious actor were able to call this function through an approved gateway with incorrect data") to deduce a vuln. This is obviously invalid.

As per contest rules, are excluded:
Comments about the bridge being malicious.