Users Can Perform Denial of Service (DoS) Attacks on Humanity IDs

Github username: -- Twitter username: -- Submission hash (on-chain): 0xf014e96f4f8533a3214d64663a058f10af28039a51d7fdb43028c97bb0241330 Severity: low

Description:

Summary

Users can exploit the system by repeatedly creating requests with zero deposit, leading to a denial of service (DoS) on a specific _humanityId. This prevents legitimate users from making valid requests.

Vulnerability Detail

In the claimHumanity function, which ultimately calls _requestHumanity, users can create requests with msg.value = 0. The issue arises in the following code:

function _requestHumanity(bytes20 _humanityId) internal returns (uint256 requestId) {
    // Human must not be in the process of claiming a humanity.
    require(humanityData[accountHumanity[msg.sender]].requestCount[msg.sender] == 0);

    Humanity storage humanity = humanityData[_humanityId];

    requestId = humanity.requests.length;

    Request storage request = humanity.requests.push(); //@audit DOS
}

Here, each time a request is made, the length of humanity.requests increases. If an attacker continuously creates these requests, they can make the humanity.requests array extremely large, causing the system become unusable for that particular _humanityId. This makes it impossible for legitimate users to add valid requests.

Impact

Attackers can make a specific _humanityId unusable by flooding it with a large number of requests, causing a DoS attack. This attack is particularly feasible on Layer 2 (L2) networks, where transaction fees are much lower, making it cheaper for attackers to execute this strategy.

Recommendation

Enforce a requestBaseDeposit requirement in the claimHumanity function to ensure that each request has a minimum cost, discouraging attackers from spamming the system with requests.
Allow admin to withdraw requests.

hats-finance / Proof-Of-Humanity-V2-0xef0709445d394a22704850c772a28a863bb780b0