Curious about using tx-sender for validating the sender

[junomonster]

From the SIP-010, it mentions the sender argument must same as the tx-sender

Contract implementers should take note to perform authorization of the transfer method. For example, a fungible token contract that wants to make sure that only the transaction's sender is able to move the requested tokens might first check that the sender argument is equal to tx-sender.

The example token in this repo also validates sender equals to the tx-sender as above SIP.

stacks-fungible-token/contracts/example-token.clar

Lines 27 to 35 in db64977

	;; Transfers tokens to a recipient
	(define-public (transfer (amount uint) (sender principal) (recipient principal) (memo (optional (buff 34))))
	(if (is-eq tx-sender sender)
	(begin
	(try! (ft-transfer? example-token amount sender recipient))
	(print memo)
	(ok true)
	)
	(err u4)))

The curious thing is, why it uses tx-sender rather than contract-caller. Imagine that the EOA account interact with the malicious contract, the contract calls(transfer to the attacker) the SIP-010 token contract without a as-contract function. SIP-010 token thinks the sender is the EOA account since it checks sender == tx-sender. At the end The EOA account's fund is hacked by the contract (an attacker).

• https://github.com/stacksgov/sips/blob/main/sips/sip-002/sip-002-smart-contract-language.md#principals-and-owner-verification

Therefore, vulnerable to any kind of phishing attack is intended?

[whoabuddy]

If you look at the specification for a STX transfer, it also authenticates with tx-sender and this is an acceptable pattern for defining an asset on Stacks.

There is another layer of protection with post conditions that are sent with transactions, and they help to specify the expected outcome of the transaction. If those conditions are not met then the transaction fails. (great explanation here)

Using contract-caller is important for protected functions and other situations where a contract should not be able to act on behalf of a user, and there are some great tips on security (and much more) here as well.

[junomonster]

If you look at the specification for a STX transfer, it also authenticates with tx-sender and this is an acceptable pattern for defining an asset on Stacks.

There is another layer of protection with post conditions that are sent with transactions, and they help to specify the expected outcome of the transaction. If those conditions are not met then the transaction fails. (great explanation here)

Using contract-caller is important for protected functions and other situations where a contract should not be able to act on behalf of a user, and there are some great tips on security (and much more) here as well.

Thanks for the detailed answer. I am clear about why stacks & clarity use a tx-sender as the sender when transferring the assets. As you mentioned, the user can simply notice that the malicious contract is trying to phishing by checking the post-conditions.

However, the user does not really have to append the post-conditions to transfer the assets. But the wallet program will append the post-conditions like no-asset-should-be-transferred when the websites just want to call the clarity smart contract, which I mentioned for phishing scenario.

Thanks!