What checks or kind of security should I implement if I'm developing an onchain program without using Anchor-lang?
Add a comment
|
1 Answer
The biggest difference is that you will have to manually check that each account is what you think it is. Anchor uses a discriminator to tell if Account A is really Account A and not Account B. If you do not use Anchor, you have to watch out for this, or someone can swap Account B in when they shouldn't. Anchor gives you a lot of tools to validate that accounts are exactly what they should be.
This is really hard, and even major organizations have failed to do this correctly. For example, the Wormhole exploit was based on a failure to validate a single account: https://www.certik.com/resources/blog/1kDYgyBcisoD2EqiBpHE5l-wormhole-bridge-exploit-incident-analysis
-
You mean verifying Program Accounts such as if Account A is SYSVAR account or not, Account B is TOKEN PROGRAM account or not? These? I'm already checking for these values by comparing the input accounts with their respective program id's. That's why am trying to know what should I do in-order to make program more secure if I don't want to use Anchor. Commented Mar 16, 2023 at 13:51
-
What I'm doing now is, in my program first 4 accounts are different programs like ATA Program, Token Program, System Program and my own program. And am checking each of those accounts to verify they are the program id they should be, or throw error. I'm also planning to add checks for other accounts like if Account E is owned by Account A or not which is System Program and Account F is owned by Account B or not which is ATA Program or not and same for the mint account which should be owned by Token Program account. Also implement checks if there's more then 1 signer and mutable set properly. Commented Mar 16, 2023 at 14:11
-