Code Hardening

The following is an example of this bug in action. The blueprint shown below is a claim handler blueprint. Each user is given a badge that gives them the right to claim their resources. The component stores the claims in a KeyValueStore<NonFungibleLocalId, Vault> which maps the non-fungible local ID of the claimer to a vault containing their resources. When a claimer requests to claim their resources they pass a Proof of their user badge and the component returns everything in their claim vault back to them.

In the misconfigured example shown below, the claim method does not check for the resource address of the passed Proof, it just gets the non-fungible local ID, fetches the associated Vault, and then returns all of the resources in the vault. In this case, an attacker can create a resource, mint NFTs of this resource of the non-fungible IDs that they wish to request claims for and be able to successfully perform the claims as the resource address of the Proof is not checked.

Mitigating this attack is quite simple and made easy by the fact that Proofs do not expose any information about their contents until they are converted into CheckedProofs through methods like check, check_with_message, and skip_checking. In the correctly configured example shown below the check method is called on the Proof to first validate that it is a user badge, only then does the claim process continue.

use scrypto::prelude::*;

// ⛔️ Misconfigured
mod misconfigured {
    use super::*;

    #[blueprint]
    mod claim_handler {
        /// Stores the resource claims for users and returns the resources when
        /// the user presents their badge.
        struct ClaimHandler {
            /// Maps the non-fungible local ID of the user's claim badge to the
            /// vault containing the resources that they can claim.
            claims: KeyValueStore<NonFungibleLocalId, Vault>,
        }

        impl ClaimHandler {
            pub fn claim(&mut self, proof: Proof) -> Bucket {
                // ⛔️ The resource address of the passed proof was not checked.
                // Thus, it may not have been an actual user badge, it could
                // very well have been a proof of a non-fungible that an
                // attacker created and they can mint of it the IDs they wish to
                // claim assets that do not belong to them.
                let non_fungible_local_id = proof
                    .skip_checking()
                    .as_non_fungible()
                    .non_fungible_local_id();

                self.claims
                    .get_mut(&non_fungible_local_id)
                    .unwrap()
                    .take_all()
            }
        }
    }
}

// ✅ Correctly Configured
mod correctly_configured {
    use super::*;

    #[blueprint]
    mod claim_handler {
        /// Stores the resource claims for users and returns the resources when
        /// the user presents their badge.
        struct ClaimHandler {
            /// Maps the non-fungible local ID of the user's claim badge to the
            /// vault containing the resources that they can claim.
            claims: KeyValueStore<NonFungibleLocalId, Vault>,

            /// The resource manager of the user badge that's minted for users
            /// to allow them to claim their resources later. This is stored for
            /// two reasons:
            /// 1. To mint additional user badges for future claims.
            /// 2. To check the passed badge against when the claim method is
            ///    called.
            user_badge: ResourceManager,
        }

        impl ClaimHandler {
            pub fn claim(&mut self, proof: Proof) -> Bucket {
                let non_fungible_local_id = proof
                    // ✅ This checks that the passed proof is of the user badge
                    // resource address; thus mitigating any chance for an
                    // attacker to provide a proof of a matching local ID but
                    // of a different resource.
                    .check(self.user_badge.address())
                    .as_non_fungible()
                    .non_fungible_local_id();

                self.claims
                    .get_mut(&non_fungible_local_id)
                    .unwrap()
                    .take_all()
            }
        }
    }
}

The following is an example showing an application that is using Proof amounts in a vulnerable way. This is a Decentralized Autonomous Organization (DAO) blueprint where participants in the DAO could cast votes for different proposals. Any entity holding the DAO resources is considered to be a participant and allowed to cast votes of a maximum weight equal to the amount of DAO resources they possess.

In the misconfigured example shown below, the vote method takes a Proof of the DAO resources, uses the proof amount to determine the voting weight, and then performs whatever logic is needed to cast a vote of the given weight to the proposal. There are some issues with this:

1. Voters can vote multiple times since the DAO tokens were not taken away from them.

2. Voters can create a proof and call the vote method multiple times to inflate their voting power.

The attack method shown in the example below is an example of how an attacker might go about exploiting such a vulnerability. Using a single legitimate proof, an attacker can increase their voting weight by simply calling the vote method of the DAO with clones of the legitimate proof as many times as they want.

Therefore, applications similar to the DAO shown in this example can not rely on proof amounts alone; they must also factor in a mechanism to disallow double voting. The simplest and most straightforward mechanism to do that borrows some ideas from the design of XRD and Liquid Stake Units (LSUs): When casting a vote users must pass in a bucket of their DAO resources which is used to determine the vote weight, the DAO keeps the DAO resources and returns to the user some kind of replacement or claim resources that they can use at any point of time to re-cast their vote or claim their DAO resources after the voting period has concluded. Snippets of that are shown in the well-configured example below.

use scrypto::prelude::*;

#[derive(ScryptoSbor)]
pub enum Vote {
    Yes,
    No,
    Abstain,
}

// 💀 Attacker
mod attacker {
    use super::*;

    #[blueprint]
    mod attacker {
        struct Attacker;

        impl Attacker {
            /// 💀 This function shows how an attacker might exploit this. Using
            /// 1 legitimate proof, they're able to multiply their voting power
            /// by 100 by cloning the proof multiple times.
            pub fn attack(legitimate_proof: Proof) {
                let dao: Global<super::misconfigured::dao::Dao> = todo!();
                let proof = legitimate_proof.skip_checking();
                for _ in 0..100 {
                    dao.vote(proof.clone().0, 1, Vote::Yes);
                }
            }
        }
    }
}

// ⛔️ Misconfigured
mod misconfigured {
    use super::*;

    #[blueprint]
    mod dao {
        /// A DAO where participants can vote on proposals.
        struct Dao {
            /// The address of the resource used for the voting. This is the
            /// resource users give to the component in order to vote and this
            /// is what determines their voting weight.
            voting_resource: ResourceManager,
        }

        impl Dao {
            /// ⛔️ This method uses proofs for voting which allows an attacker
            /// to inflate a vote in two main ways:
            ///
            /// 1. Clone the proof and call this method again.
            /// 2. Since they still own the resources, they can just create
            ///    another proof from that bucket or vault and pass it again.
            ///
            /// By passing proof of the same resources multiple times they can
            /// inflate the voting results by casting duplicate votes.
            pub fn vote(
                &mut self,
                proof: Proof,
                _proposal_id: u64,
                _vote: Vote,
            ) {
                let _vote_weight =
                    proof.check(self.voting_resource.address()).amount();
                info!("Congratulations, you've voted!");

                /* Remaining of the voting logic goes here. */
            }
        }
    }
}

// ✅ Correctly Configured
mod correctly_configured {
    use super::*;

    #[blueprint]
    mod dao {
        /// A DAO where participants can vote on proposals.
        struct Dao {
            /// The address of the resource used for the voting. This is the
            /// resource users give to the component in order to vote and this
            /// is what determines their voting weight.
            voting_resource: ResourceManager,

            /// The address of the resource given to the voters after they vote
            /// and after their voting resources are taken away from them. This
            /// resource can be exchanged for the voting resource when the vote
            /// period ends.
            voting_claim_resource: ResourceManager,
        }

        impl Dao {
            /// This fixes the vulnerability seen in the misconfigured [`vote`]
            /// by taking a bucket of the vote resources instead of a proof.
            ///
            /// This method does the following:
            ///
            /// * Ensures that the correct bucket of resources was passed in.
            /// * Calculates the voting weight.
            /// * Deposits the voting resources into a vault.
            /// * Mint an equivalent amount of voting claim resources and return
            ///   them to the caller.
            ///
            /// [`vote`]: [`super::misconfigured::dao::Dao::vote`]
            pub fn vote(
                &mut self,
                bucket: Bucket,
                _proposal_id: u64,
                _vote: Vote,
            ) {
                assert_eq!(
                    bucket.resource_address(),
                    self.voting_resource.address()
                );
                let _vote_weight = bucket.amount();
                info!("Congratulations, you've voted!");

                /* Remaining of the voting logic goes here. */
            }
        }
    }
}

The following is an example showing a blueprint vulnerable to state explosion. This blueprint is of a decentralized exchange where the liquidity is stored in a mapping of the pair resource addresses to the pair vaults. In the misconfigured example an IndexMap is used. As more pairs are created, this map can eventually become large enough that it becomes very expensive to load. This makes it so that swaps are very expensive to do as each call to the swap method reads the component state which has this
very large map. In the worst-case scenario, this map could become large enough that reading it exceeds the cost unit limit, making it impossible to make any calls to the exchange component, essentially locking the component and all of the assets contained within. The correctly configured example mitigates this by switching the IndexMap with a KeyValueStore.

use scrypto::prelude::*;

// ⛔️ Misconfigured
mod misconfigured {
    use super::*;

    #[blueprint]
    mod decentralized_exchange {
        /// A decentralized exchange allowing users to swap resources as well as
        /// contribute liquidity.
        struct DecentralizedExchange {
            /// ⛔️ This maps the address of the two resources of the pair to
            /// their respective vaults. There are two main problems with this:
            ///
            /// 1. This map's size is not bounded and can keep growing
            ///    indefinitely
            /// 2. The map is not lazy loaded; its loaded in full with each
            ///    method call to the component.
            ///
            /// This means that it is possible for this map to become large
            /// enough that any call to this component becomes either very
            /// expensive or would outright exceed the cost unit limit and
            /// lead such transactions to fail. In the context of this example
            /// if that happens then users would be unable to swap tokens and
            /// liquidity providers would be unable to redeem their pool units
            /// which would effectively result in loss of assets!
            pairs: IndexMap<(ResourceAddress, ResourceAddress), (Vault, Vault)>,
        }

        impl DecentralizedExchange {
            /* Implementation of the decentralized exchange */
        }
    }
}

// ✅ Correctly Configured
mod correctly_configured {
    use super::*;

    #[blueprint]
    mod decentralized_exchange {
        /// A decentralized exchange allowing users to swap resources as well as
        /// contribute liquidity.
        struct DecentralizedExchange {
            /// ✅ Key value stores are lazily loaded instead of being eagerly
            /// loaded. This means that none of the [`KeyValueStore`] entries
            /// are loaded when the component state is read, only the [`NodeId`]
            /// of the [`KeyValueStore`] is loaded. Thus, [`KeyValueStore`] can
            /// grow in size indefinitely without leading to state explosion
            /// problems.
            pairs: KeyValueStore<
                (ResourceAddress, ResourceAddress),
                (Vault, Vault),
            >,
        }

        impl DecentralizedExchange {
            /* Implementation of the decentralized exchange */
        }
    }
}

The following is an example of a mathematical equation that can be coded in two different ways: one where it is impossible to overflow and another where it can easily overflow. This equation calculates how much of resource an amount of pool units corresponds to.

The two ways of representing the above equation in code are as follows:

let pool_unit_amount: Decimal = todo!();
let pool_unit_total_supply: Decimal = todo!();
let reserves: Decimal = todo!();

/// ⛔️ Easily Overflows!
let redemption_amount = pool_unit_amount * reserves / pool_unit_total_supply;

/// ✅ Impossible to Overflow!
let redemption_amount = pool_unit_amount / pool_unit_total_supply * reserves;

In the above example, both ways of calculating the redemption amount are mathematically equivalent. However, the first way can overflow quite easily whereas it is impossible for the second way to overflow. Multiplying pool_unit_amount by reserves can overflow if both numbers are large. However, restructuring the calculation so that the pool_unit_amount is first divided by pool_unit_total_supply and then multiplied with the reserves results in a calculation where it is not only hard to overflow but actually impossible. This is because .

The following is an example of code that is vulnerable to this issue and how it can be mitigated through take_advanced:

// Divisibility = 2
let vault: Vault = todo!();

let pool_unit_amount: Decimal = dec!(1);
let pool_unit_total_supply: Decimal = dec!(3);
let reserves: Decimal = dec!(10);

// redemption_amount = 3.333333333333333333
let redemption_amount = pool_unit_amount / pool_unit_total_supply * reserves;

// ⛔️ A withdraw of 3.333333333333333333 is invalid for a resource with a 
// divisibility of two. Any decimal with more than 2 decimal places would lead
// this to fail.
let bucket = vault.take(redemption_amount);

// ✅ Correctly handles the divisibility by rounding towards zero.
let bucket = vault.take_advanced(
    redemption_amount, 
    WithdrawStrategy::Rounded(RoundingMode::ToZero)
);

The following is an example showing a blueprint whose method auth is misconfigured in a few different ways. The final blueprint in the example shows a properly configured blueprint. This is a payment splitter blueprint that allows deposits to be split among a group of entities according to percentages defined in the component. Payment splitters have admins that can change the percentage share of the participants. Only the payment splitter manager is allowed to mint additional admin badges by calling the mint_admin_badge on payment splitter components. It is important in this example that this method is only callable by the payment splitter manager. Otherwise, anybody can mint an admin badge and assume admin powers.

In the first misconfigured example the enable_method_auth! macro is not used; thus, method auth is completely disabled, and all methods with visibility of pub in the blueprint are public and callable by all. As a result, mint_admin_badge can be called by anyone. The second misconfigured example has enabled method auth and defined that the blueprint has a manager role. However, the mint_admin_badge method is not assigned to the manager role, it is incorrectly assigned to the PUBLIC role making it callable by all. In the third misconfigured example, method auth is correctly enabled, a manager role is correctly defined, and the mapping of the mint_admin_badge method to the manager role is correctly done, however, the manager role is assigned a rule of rule!(allow_all) which makes mint_admin_badge callable by all. Finally, the last blueprint is correctly configured.

use scrypto::prelude::*;

// ⛔️ Misconfigured
mod misconfigured1 {
    use super::*;

    #[blueprint]
    mod payment_splitter {
        /// Allows for deposited resources to be split across multiple different
        /// parties according to the percentages defined by the component.
        struct PaymentSplitter;

        impl PaymentSplitter {
            /// ⛔️ Method auth is not enabled. Thus, this functions is public
            /// and callable by all!
            pub fn mint_admin_badge(&mut self) -> Bucket {
                todo!()
            }
        }
    }
}

// ⛔️ Misconfigured
mod misconfigured2 {
    use super::*;

    #[blueprint]
    mod payment_splitter {
        enable_method_auth! {
            roles {
                manager => updatable_by: [];
            },
            methods {
                // ⛔️ The method is mapped to the public role. Thus, it can be
                // called by all!
                mint_admin_badge => PUBLIC;
            }
        }

        /// Allows for deposited resources to be split across multiple different
        /// parties according to the percentages defined by the component.
        struct PaymentSplitter;

        impl PaymentSplitter {
            pub fn mint_admin_badge(&mut self) -> Bucket {
                todo!()
            }
        }
    }
}

// ⛔️ Misconfigured
mod misconfigured3 {
    use super::*;

    #[blueprint]
    mod payment_splitter {
        enable_method_auth! {
            roles {
                manager => updatable_by: [];
            },
            methods {
                mint_admin_badge => restrict_to: [manager];
            }
        }

        /// Allows for deposited resources to be split across multiple different
        /// parties according to the percentages defined by the component.
        struct PaymentSplitter;

        impl PaymentSplitter {
            pub fn instantiate() -> Global<PaymentSplitter> {
                Self.instantiate()
                    .prepare_to_globalize(OwnerRole::None)
                    // ⛔️ The `mint_admin_badge` method requires the `manager`
                    // role but this role is defined as being AllowAll. Thus,
                    // this method is callable by all!
                    .roles(roles! { manager => rule!(allow_all); })
                    .globalize()
            }

            pub fn mint_admin_badge(&mut self) -> Bucket {
                todo!()
            }
        }
    }
}

// ✅ Correctly Configured
mod correctly_configured {
    use super::*;

    #[blueprint]
    mod payment_splitter {
        enable_method_auth! {
            roles {
                manager => updatable_by: [];
            },
            methods {
                // Only the manager role can call the mint_admin_badge method.
                mint_admin_badge => restrict_to: [manager];
            }
        }

        /// Allows for deposited resources to be split across multiple different
        /// parties according to the percentages defined by the component.
        struct PaymentSplitter;

        impl PaymentSplitter {
            pub fn instantiate(
                manager_rule: AccessRule,
            ) -> Global<PaymentSplitter> {
                Self.instantiate()
                    .prepare_to_globalize(OwnerRole::None)
                    // The manager role is set to the rule passed to the
                    // constructor function, this should not just be an
                    // allow_all.
                    .roles(roles! { manager => manager_rule; })
                    .globalize()
            }

            pub fn mint_admin_badge(&mut self) -> Bucket {
                todo!()
            }
        }
    }
}