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

DatingDapp Smart Contract Security Analysis: LikeRegistry

akasharora963

Smart Contract Security Analysis: LikeRegistry

=====================================================

Summary

The LikeRegistry contract implements a social interaction system with NFT integration and ETH-based rewards. A critical vulnerability was identified in the balance tracking mechanism, along with several security concerns that could compromise the contract's integrity.

Vulnerability Details

1. Missing Balance Tracking

Severity: High (9/10)

Type: Untracked ETH Payments

Location: likeUser function

Description: The contract accepts ETH payments but fails to track them in the userBalances mapping

Impact: Users can send ETH without their balances being recorded, leading to:

  • Loss of funds

  • Inaccurate reward calculations

  • Potential contract freeze

  • Inconsistent state management

function likeUser(address liked) external payable {
require(msg.value >= 1 ether, "Must send at least 1 ETH");
// Missing: userBalances[msg.sender] += msg.value;
// ... rest of function
}

2. Reentrancy Risk

Severity: High (8/10)

Type: Unprotected External Calls

Location: matchRewards function

Description: Direct ETH transfers using call.value without proper protection

Impact: Potential for reentrancy attacks that could:

  • Drain contract funds

  • Manipulate reward distribution

  • Freeze user assets

  • Cause unintended state changes

(bool success,) = payable(address(multiSigWallet)).call{value: rewards}("");
require(success, "Transfer failed");

3. State Management Issues

Severity: Medium (6/10)

Type: Inconsistent State Updates

Location: Multiple functions

Description: State modifications occur before external calls, violating the Checks-Effects-Interactions pattern

Impact: Could lead to:

  • Race conditions

  • Inconsistent state

  • Unexpected behavior

  • Potential fund mismanagement

Impact

The identified vulnerabilities could result in:

  1. Financial Loss

    • Users may lose ETH sent for likes without being tracked

    • Potential theft of accumulated rewards

    • Unauthorized access to contract funds

    • Estimated potential loss: High

  2. System Compromise

    • Reentrancy attacks could drain contract funds

    • Inconsistent state management could lead to unexpected behavior

    • Potential freezing of user assets

    • System reliability: Medium risk

  3. Data Integrity

    • Inaccurate balance tracking

    • Potential mismatch between actual and recorded rewards

    • Unreliable match history

    • Data consistency: Medium risk

Tools Used

The following security tools were utilized in this analysis:

  1. Static Analysis

    • Slither: For detecting common vulnerabilities and code patterns

    • Solhint: For identifying style issues and potential security risks

  2. Security Frameworks

    • OpenZeppelin's Secure Development Guidelines

    • Consensys Smart Contract Security Best Practices

  3. Code Review

    • Manual analysis of critical functions

    • Review of state management patterns

Recommendations

1. Implement Proper Balance Tracking

Priority: High

function likeUser(address liked) external payable {
// Track balance before any state changes
userBalances[msg.sender] += msg.value;
// Rest of function implementation
}

2. Add Reentrancy Protection

Priority: High

import {ReentrancyGuard} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
contract LikeRegistry is ReentrancyGuard {
// ... rest of contract
}

3. Implement Checks-Effects-Interactions Pattern

Priority: Medium

function likeUser(address liked) external payable {
// Effects
userBalances[msg.sender] += msg.value;
// Interactions
if (likes[liked][msg.sender]) {
matches[msg.sender].push(liked);
matches[liked].push(msg.sender);
matchRewards(liked, msg.sender);
}
​
// Events
emit Liked(msg.sender, liked);
}
function matchRewards(address from, address to) internal {
// 1. Checks
uint256 matchUserOne = userBalances[from];
uint256 matchUserTwo = userBalances[to];
// 2. Effects
userBalances[from] = 0;
userBalances[to] = 0;
// 3. Interactions
uint256 totalRewards = matchUserOne + matchUserTwo;
// ... rest of implementation
}

4. Add Error Handling for valid address

Priority: Medium

modifier onlyValidAddress(address _address) {
require(_address != address(0), "Invalid address");
_;
}
​
function likeUser(address liked) external payable onlyValidAddress(liked) {
// ... rest of implementation
}
Updates

Appeal created

n0kto Lead Judge 7 months ago
Submission Judgement Published
Validated
Assigned finding tags:

finding_likeUser_no_userBalances_updated

Likelihood: High, always. Impact: High, loss of funds

Support

FAQs

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