Summary

The smart contract DSCEngine.sol contains a vulnerability in the depositCollateral function, where the isAllowedToken modifier does not validate whether the provided tokenCollateralAddress is a valid ERC20 token contract. As a result, the contract accepts any address that is not address(0) as a valid token address, regardless of whether it complies with the ERC20 token standard. This issue can lead to several problems, including the acceptance of invalid tokens, potential contract incompatibility, and incorrect token balance updates.

Vulnerability Details

The depositCollateral function utilizes the isAllowedToken modifier, which is intended to check the validity of the tokenCollateralAddress. However, this modifier only verifies whether s_priceFeeds[token] is not address(0) but does not validate if it is a legitimate ERC20 token contract. Consequently, the contract allows non-ERC20 token contracts, resulting in potential contract execution errors and unexpected behavior.

Impact

1. Invalid Token Deposit: Users can deposit non-ERC20 tokens as collateral, leading to potential issues when handling invalid tokens within the contract. The amount will still get added to the s_collateralDeposited array, potentially causing inconsistency in the contract's data.

2. Contract Incompatibility: Interacting with non-ERC20 token contracts using the IERC20 interface can result in contract execution errors, leading to contract failure or unexpected behavior. The transferFrom operation, which attempts to move the collateral amount from the user's address to the contract address, will revert when dealing with non-ERC20 tokens.

Tools Used

• VS code

• Manual Review

Recommendations

Include the check for a valid ERC20 token contract within a revert statement,can use the try and catch blocks as follows:

This implementation ensures that only valid ERC20 token contracts are allowed as collateral, and it provides a revert statement if an invalid token address is used.