Guarantee not dispensing native assets to a Franken address

Question

As I understand it, a "mangled" address can be used to spoof ownership of a wallet who's stake address is NOT of a wallet controlled by the one doing the spoofing.

Put another way: I can use someone else's address, and my own address, combined together to fool a dApp into dispensing some native assets to ME even though they should only be claimable by the owner of the wallet who's stake address I have mangled with my spending address.

What is a very concrete way for a dApp to NEVER fall prey to this "exploit"?

It is put this way on a thread I found:

It is not possible if the dApp does not send native assets to the address paying the fee, but instead to the address that last did a delegation of the stake key of the address paying the fee, which requires a signature of that stake key and, hence, guarantees the ownership.

So...

1. what about a wallet that never delegated?

2. If someone uses a Franken Address to claim something or benefit somehow how can I make sure the TRUE owner is the one claiming/benefiting by finding the address to send to from the last time the stake address portion delegated? This must be a possible lookup in db-sync, and I am not sure how to look it up.

I am looking for a guaranteed way of ensuring native assets will (and ADA?) can only ever be sent to the actual wallet of the stake address, not to a wallet pretending to be that wallet by using a franken address.

I believe the simple way to avoid this as an issue is to ALWAYS require a user SIGN any transaction that sends them something or benefits them somehow...in this way, no spoofing is possible.

Answer 1

What is a very concrete way for a dApp to NEVER fall prey to this "exploit"?

Simple: you do not have keys to sign the payment credentials which are the payment part of the address.

And If a dApp is checking the stake key instead of the payment key, that is a major, major security flaw in their contract.

Your dApp should be using only and only the payment credentials of the address.

Answer 2

1. what about a wallet that never delegated?

Using the strategy outlined above you cannot accept tokens from users who never delegated, so you would need to handle it somehow in your application and not allow those types of users.

If someone uses a Franken Address to claim something or benefit somehow how can I make sure the TRUE owner is the one claiming/benefiting by finding the address to send to from the last time the stake address portion delegated? This must be a possible lookup in db-sync, and I am not sure how to look it up.

Blockfrost has an endpoint to get someone's delegation history

https://cardano-preprod.blockfrost.io/api/v0/accounts/stake_test123.../delegations?order=desc

Now is this the best way of avoiding the Frankenstein address vulnerability? It depends on your application, but I will say probably not.

A different way would be to ask for a CIP-08 signature from the user stake-key. If he can sign an arbitrary message with his staking-key, it means he has the stake-key, you can require this whenever a user wants to claim something.

Another possibility would be to force the user to include the stake address signature in the transaction and invalidate it otherwise. This is useful if you don't want to require the user to sign something twice like in the example above. You can do this by using the transaction to re-delegate to whatever pool he already was delegated (or to a new one if he wasn't previously). This will tell whatever browser wallet he is using that the transaction needs a staking-key witness.