DatingDapp

Summary

The likeUser() function in the LikeRegistry contract improperly handles multiple interactions from the same participant. When a user interacts with more than one recipient using likeUser(), all previously sent Ether is allocated to the first successfully matched user, rather than being distributed correctly according to individual transactions. This occurs due to the lack of a mechanism to differentiate the amounts sent to different recipients.

Vulnerability Details

The contract currently maintains a single mapping, mapping(address => uint256) public userBalances, which tracks the total Ether deposited by a user. However, this design does not distinguish between different recipients when a user interacts with multiple addresses. When a participant executes likeUser() multiple times with different recipients, the total Ether amount is aggregated under a single balance rather than being attributed correctly to each interaction.

For example, consider the following transactions:

If likeUser() is executed for two different recipients, the contract records the sender’s total deposited amount but does not track how much was sent to each specific recipient. As a result, when the first recipient matches, they receive the entire accumulated balance, rather than only the amount that was meant for them.

This issue is exacerbated by the previously identified flaw where msg.value is not correctly recorded in userBalances, further preventing accurate fund tracking. Even if the balance update mechanism is corrected, the inability to separate transactions based on sender-recipient pairs remains a fundamental design flaw.

Impact

The mishandling of multiple likeUser() interactions creates a significant financial risk. If a user interacts with multiple recipients but only one is successfully matched, that recipient receives all the Ether previously sent by the sender, regardless of the intended allocation. This leads to unfair distribution and potential financial losses for the sender. Additionally, this design flaw may discourage users from engaging with multiple participants, limiting the effectiveness and scalability of the contract.

Tools Used

Manual Audit

Recommendations

To resolve this issue, the contract should track Ether balances separately for each sender-recipient pair rather than aggregating all deposits under a single balance. One approach is to replace the current userBalances mapping with a more granular structure, such as mapping(address => mapping(address => uint256)), which allows the contract to store and manage balances on a per-recipient basis.

Additionally, the contract should implement a mechanism to ensure that the correct amount is transferred when a match occurs, preventing a single recipient from receiving more Ether than they were allocated. This may include enforcing stricter logic within matchRewards() to distribute funds based on the actual msg.value contributed for each recipient.

By introducing these modifications, the contract can ensure fair and accurate Ether distribution while preventing unintended fund misallocations.