fix: validate receiver is msg.sender in all deposit/creation functions (Issue #1)#10
Open
korpo1337 wants to merge 1 commit into
Open
Conversation
…s (Issue intuition-box#1) Issue: The deposit(), createAtoms(), createTriples(), and depositBatch() functions accept a 'receiver' parameter without validating that it matches msg.sender. This allows a dApp integrating the Fee Proxy to set the receiver to an arbitrary address (the proxy contract itself, the dApp's own wallet, or any third-party address), as long as that address has approved the proxy on the MultiVault. Impact: User funds (msg.value) are spent by the caller, but shares are credited to an arbitrary receiver. This breaks the fund-flow invariant and enables unauthorized share redirection. Fix: Added 'require(receiver == msg.sender)' check (via custom error IntuitionFeeProxy_ReceiverNotCaller) to all four functions that accept a receiver parameter. Updated NatSpec docs to reflect the new invariant. Changes: - src/IntuitionFeeProxy.sol: Added receiver validation to deposit(), createAtoms(), createTriples(), and depositBatch() - src/libraries/Errors.sol: Added IntuitionFeeProxy_ReceiverNotCaller error - test/IntuitionFeeProxy.test.ts: Added 8 tests covering receiver validation for all four functions (4 revert cases + 4 success cases) All 42 tests passing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix for Issue #1: Receiver not validated as msg.sender
Problem
The
deposit(),createAtoms(),createTriples(), anddepositBatch()functions accept areceiverparameter without validating that it matchesmsg.sender. This allows a dApp integrating the Fee Proxy to set thereceiverto an arbitrary address (the proxy contract itself, the dApp's own wallet, or any third-party address), as long as that address has approved the proxy on the MultiVault.Impact: User funds (
msg.value) are spent by the caller, but shares are credited to an arbitrary receiver — enabling unauthorized share redirection.Solution
Added
receiver == msg.sendervalidation (via custom errorIntuitionFeeProxy_ReceiverNotCaller) to all four functions that accept areceiverparameter.Changes
src/IntuitionFeeProxy.soldeposit(),createAtoms(),createTriples(),depositBatch()+ updated NatSpec docssrc/libraries/Errors.solIntuitionFeeProxy_ReceiverNotCallercustom errortest/IntuitionFeeProxy.test.tsTest Results
All existing tests continue to pass. All new receiver validation tests pass.
Bounty
This PR addresses Bounty 2A ($200 USDC) from Issue #2.