Christmas Dinner

First Flight #31
Beginner FriendlyFoundrySolidity
100 EXP
View results
Submission Details
Severity: low
Invalid

Lack of Access Control in Refund Function

Summary

The refund function in the contract lacks proper access control, allowing any user, regardless of whether they have deposited assets or not, to call the function and trigger refund processes. This can lead to unintended behavior and potential abuse. Adding a proper validation check for deposited assets before processing refunds is necessary to secure the function.

Vulnerability Details

The current implementation of the refund function does not verify whether the caller has deposited any assets before allowing the refund process. As a result, users who have not deposited any assets can still call the function, leading to redundant operations and unnecessary state changes. The code snippet below illustrates the issue:

function refund() external nonReentrant beforeDeadline {
/// @audit = everyone can call refund function // lack of access
address payable _to = payable(msg.sender);
_refundERC20(_to);
_refundETH(_to);
emit Refunded(msg.sender);
}

This lack of a proper condition to validate the presence of refundable assets can allow abuse and affect the contract's efficiency and gas usage.

Impact

  • Unnecessary operations for users with no refundable assets.

  • Potential confusion among users when calling the refund function without prior deposits.

  • Increased gas costs due to redundant operations.

Tools Used

Manual code review.

Recommendations

Introduce a validation check in the refund function to ensure that the caller has refundable assets before processing the refund. The following code snippet demonstrates the corrected implementation:

function refund() external nonReentrant beforeDeadline {
address payable _to = payable(msg.sender);
// Check if the user has any refundable assets
if (
balances[_to][address(i_USDC)] == 0 &&
balances[_to][address(i_WBTC)] == 0 &&
balances[_to][address(i_WETH)] == 0 &&
etherBalance[_to] == 0
) {
revert("No Assets to Refund");
}
// Proceed with the refund
_refundERC20(_to);
_refundETH(_to);
emit Refunded(msg.sender);
}

Explanation of the Condition

  • balances[_to][i_USDC] == 0: Checks if the user has no USDC balance.

  • balances[_to][i_WBTC] == 0: Checks if the user has no WBTC balance.

  • balances[_to][i_WETH] == 0: Checks if the user has no WETH balance.

  • etherBalance[_to] == 0: Checks if the user has no ETH balance.

If all these conditions are true, the function will revert with the message "No Assets to Refund."

Recommendations Summary

  1. Add a validation check to ensure the caller has refundable assets.

  2. Use a comprehensive condition to check all supported asset balances.

  3. Revert the transaction if the user has no refundable assets to prevent unnecessary operations.

Implementing these recommendations will enhance the function's security and operational efficiency.

Updates

Lead Judging Commences

0xtimefliez Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
0xtimefliez Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

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