validate messageFrom to prevent identity spoofing#8
Closed
paul-research wants to merge 1 commit into
Closed
Conversation
Require messageFrom matches actual sender/owner to prevent users from impersonating others in message events. - Add validation in Recibo.sol (5 functions) and ReciboToken.sol (3 functions) - Fix missing spender check in permitWithMsg - Add error messages to all require statements - Update test fixtures accordingly All 103 tests pass. Gas increase: ~500 per call.
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.
Validate messageFrom to prevent spoofing
Problem
messageFrominReciboInfois not validated. Anyone can set it to an arbitrary address:This will get flagged in audit.
Solution
Applied to all functions in both Recibo.sol and ReciboToken.sol.
Bonus: Added missing
spender != address(this)check inpermitWithMsg.Potential pushback & responses
"We're adding AA soon, won't this block relayers?"
Yes, but that's the point. Current design has no signature verification - anyone can spoof.
When we add AA, we'll add separate functions:
sendMsg()- simple, direct calls (this PR)sendMsgWithSignature()- supports relayers (Phase 2)Both need to be secure. Can't ship AA with an insecure fallback function.
"But calldata has tx.from, so we can verify off-chain"
Events are for indexing. Not every UI/indexer will parse calldata for tx.from.
Attack vector: phishing notifications ("Circle sent you a message!").
Arc Chain = financial messaging with USDC gas = higher security bar.
"messageFrom is for flexibility"
Without signature verification, it's for spoofing.
AA requires EIP-712 signatures anyway. This PR doesn't prevent AA
Breaking change
Impact: Minimal. Python client already uses sender_address correctly.
Only affects hypothetical relayer code (which doesn't exist yet and would need signatures anyway).