Reinitialization Attacks

Back to course Share on twitter

Previous Lesson Next Lesson

Objectives

By the end of this lesson, you'll be able to:

Explain security risks associated with a reinitialization vulnerability
Use long-form Rust check if an account has already been initialized
Using Anchor’s `init` constraint to initialize accounts, which automatically sets an account discriminator that is checked to prevent the reinitialization of an account

Progress

How to approach the Program Security unit

Signer authorization

Lab: Check signers are correct before processing transactions

Owner checks

Lab: Check owners are correct before processing transactions

Account data matching

Lab: Check account data is correct before processing transactions

Reinitialization attacks

Lab: Ensure accounts can only be initialised once to prevent overriding existing data

Duplicate mutable accounts

Lab: Ensure accounts are distinct

Type cosplay

Lab: Implement checks for correct account types

Arbitrary CPIs

Lab: Ensure CPIs are only called by the correct program

Bump seed canonicalization

Lab: Ensure bump seeds are always canonical

Closing accounts and revival attacks

Lab: Ensure accounts that are closed can't be reused

PDA sharing

Lab: Ensure PDA design avoids shared accounts