DatingDapp
First Flight #33
Beginner FriendlyFoundrySolidityNFT
100 EXP
View results
Previous Next
Submission Details
Severity: low
Invalid

[L-1] Duplicate Matches in LikeRegistry Contract

ghufranhassan1

Summary

The LikeRegistry contract allows users to be matched multiple times with the same person due to the absence of checks for duplicate entries in the matches array. There is no mechanism in place to check if a user is already in the matches array of another user before adding them again. This means that if the same two users like each other again, they will be added to each other's matches array again, resulting in duplicate entries.

Vulnerability Details

The LikeRegistry contract has a low-severity vulnerability where users can be matched multiple times with the same person due to the lack of checks for duplicate entries in the matches array. This results in increased storage and gas costs, potential confusion for users, and performance inefficiencies. Additionally, it may misalign with the intended business logic of maintaining unique matches. Addressing this issue can improve the contract's efficiency, reduce costs, and enhance user experience by ensuring data integrity and clarity.

Impact

  • Duplicate entries increase the size of the matches array, leading to higher storage costs on the blockchain.

  • A user can repeatedly match with the same person and deploy multiple MultiSigWallets which will waste gas

Tools

Manual Review

Below is the POC and result

function testUniqueMatchesInvariant() public {
// User1 likes User2
vm.prank(user1);
likeRegistry.likeUser{value: 1 ether}(user2);
​
// User2 likes User1, creating a mutual match
vm.prank(user2);
likeRegistry.likeUser{value: 1 ether}(user1);
​
// Check matches for user1
address[] memory matchesUser1 = likeRegistry.getMatches();
// Ensure user1 has exactly one match with user2
assertEq(matchesUser1.length, 1, "User1 should have 1 unique match");
assertEq(matchesUser1[0], user2, "User1's match should be User2");
​
// User1 likes User2 again
vm.prank(user1);
likeRegistry.likeUser{value: 1 ether}(user2);
​
// User2 likes User1 again
vm.prank(user2);
likeRegistry.likeUser{value: 1 ether}(user1);
​
// Check matches for user1 again
matchesUser1 = likeRegistry.getMatches();
assertEq(matchesUser1.length, 1, "User1 should still have 1 unique match");
}

Recommendations

Check if a MultiSigWallet already exists before creating a new one

+mapping(address => mapping(address => address)) public userMultiSigWallets;
​
function matchRewards(address from, address to) internal {
​
uint256 matchUserOne = userBalances[from];
uint256 matchUserTwo = userBalances[to];
userBalances[from] = 0;
userBalances[to] = 0;
​
uint256 totalRewards = matchUserOne + matchUserTwo;
uint256 matchingFees = (totalRewards * FIXEDFEE ) / 100;
uint256 rewards = totalRewards - matchingFees;
totalFees += matchingFees;
​
//userMultiSigWallets[from][to] stores the address of the MultiSigWallet created for the users from and to
+ require(userMultiSigWallets[from][to] == address(0), "MultiSig already exists");
​
​
// Deploy a MultiSig contract for the matched users
MultiSigWallet multiSigWallet = new MultiSigWallet(from, to);
​
//The address of the newly created MultiSigWallet is stored in the userMultiSigWallets mapping for both [from][to] and [to][from]. This ensures that the wallet can be accessed using either order of the user pair.
+ userMultiSigWallets[from][to] = address(multiSigWallet);
+ userMultiSigWallets[to][from] = address(multiSigWallet);
​
// Send ETH to the deployed multisig wallet
(bool success, ) = payable(address(multiSigWallet)).call{value: rewards}("");
require(success, "Transfer failed");
}
​
​
Updates

Appeal created

n0kto Lead Judge 6 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Users mistake, only impacting themselves.

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

ghufranhassan1 Submitter
6 months ago
n0kto Lead Judge
6 months ago
ghufranhassan1 Submitter
6 months ago
n0kto Lead Judge 6 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Users mistake, only impacting themselves.

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.