Secureum Book
  • 🛡️Secureum Bootcamp
    • 🛡️Secureum Bootcamp
    • 🙌Participate
    • 📜History
  • 📚LEARN
    • Introduction
      • 🔷1. Ethereum Basics
        • 1.1 Ethereum: Concept, Infrastructure & Purpose
        • 1.2 Properties of the Ethereum Infrastructure
        • 1.3 Ethereum vs. Bitcoin
        • 1.4 Ethereum Core Components
        • 1.5 Gas Metering: Solving the Halting Problem
        • 1.6 web2 vs. web3: The Paradigm Shift
        • 1.7 Decentralization
        • 1.8 Cryptography, Digital Signature & Keys
        • 1.9 Ethereum State & Account Types
        • 1.10 Transactions: Properties & Components
        • 1.11 Contract Creation
        • 1.12 Transactions, Messages & Blockchain
        • 1.13 EVM (Ethereum Virtual Machine) in Depth
        • 1.14 Transaction Reverts & Data
        • 1.15 Block Explorer
        • 1.16 Mainnet & Testnets
        • 1.17 ERCs & EIPs
        • 1.18 Legal Aspects in web3: Pseudonymity & DAOs
        • 1.19 Security in web3
        • 1.20 web2 Timescales vs. web3 Timescales
        • 1.21 Test-in-Prod. SSLDC vs. Audits
        • Summary: 101 Keypoints
      • 🌀2. Solidity
        • 2.1 Solidity: Influence, Features & Layout
        • 2.2 SPDX & Pragmas
        • 2.3 Imports
        • 2.4 Comments & NatSpec
        • 2.5 Smart Contracts
        • 2.6 State Variables: Definition, Visibility & Mutability
        • 2.7 Data Location
        • 2.8 Functions
        • 2.9 Events
        • 2.10 Solidity Typing
        • 2.11 Solidity Variables
        • 2.12 Address Type
        • 2.13 Conversions
        • 2.14 Keywords & Shorthand Operators
        • 2.15 Solidity Units
        • 2.16 Block & Transaction Properties
        • 2.17 ABI Encoding & Decoding
        • 2.18 Error Handling
        • 2.19 Mathematical & Cryptographic Functions
        • 2.20 Control Structures
        • 2.21 Style & Conventions
        • 2.22 Inheritance
        • 2.23 EVM Storage
        • 2.24 EVM Memory
        • 2.25 Inline Assembly
        • 2.26 Solidity Version Changes
        • 2.27 Security Checks
        • 2.28 OpenZeppelin Libraries
        • 2.29 DAppSys Libraries
        • 2.30 Important Protocols
        • Summary: 201 Keypoints
      • 🔏3. Security Pitfalls & Best Practices
        • 3.1 Solidity Versions
        • 3.2 Access Control
        • 3.3 Modifiers
        • 3.4 Constructor
        • 3.5 Delegatecall
        • 3.6 Reentrancy
        • 3.7 Private Data
        • 3.8 PRNG & Time
        • 3.9 Math & Logic
        • 3.10 Transaction Order Dependence
        • 3.11 ecrecover
        • 3.12 Unexpected Returns
        • 3.13 Ether Accounting
        • 3.14 Transaction Checks
        • 3.15 Delete Mappings
        • 3.16 State Modification
        • 3.17 Shadowing & Pre-declaration
        • 3.18 Gas & Costs
        • 3.19 Events
        • 3.20 Unary Expressions
        • 3.21 Addresses
        • 3.22 Assertions
        • 3.23 Keywords
        • 3.24 Visibility
        • 3.25 Inheritance
        • 3.26 Reference Parameters
        • 3.27 Arbitrary Jumps
        • 3.28 Hash Collisions & Byte Level Issues
        • 3.29 Unicode RTLO
        • 3.30 Variables
        • 3.31 Pointers
        • 3.32 Out-of-range Enum
        • 3.33 Dead Code & Redundant Statements
        • 3.34 Compiler Bugs
        • 3.35 Proxy Pitfalls
        • 3.36 Token Pitfalls
        • 3.37 Special Token Pitfalls
        • 3.38 Guarded Launch Pitfalls
        • 3.39 System Pitfalls
        • 3.40 Access Control Pitfalls
        • 3.41 Testing, Unused & Redundand Code
        • 3.42 Handling Ether
        • 3.43 Application Logic Pitfalls
        • 3.44 Saltzer & Schroeder's Design Principles
        • Summary: 201 Keypoints
      • 🗜️4. Audit Techniques & Tools
        • 4.1 Audit
        • 4.2 Analysis Techniques
        • 4.3 Specification, Documentation & Testing
        • 4.4 False Positives & Negatives
        • 4.5 Security Tools
        • 4.6 Audit Process
        • Summary: 101 Keypoints
      • ☝️5. Audit Findings
        • 5.1 Criticals
        • 5.2 Highs
        • 5.3 Mediums
        • 5.4 Lows
        • 5.5 Informationals
        • Summary: 201 Keypoints
  • 🌱CARE
    • CARE
      • CARE Reports
  • 🚩CTFs
    • A-MAZE-X CTFs
      • Secureum A-MAZE-X
      • Secureum A-MAZE-X Stanford
      • Secureum A-MAZE-X Maison de la Chimie Paris
Powered by GitBook
On this page
  • Withdrawal of Funds
  • selfdestruct
  1. LEARN
  2. Introduction
  3. 3. Security Pitfalls & Best Practices

3.2 Access Control

Access control is perhaps the most significant and fundamental aspect of security. When it comes to smart contracts, what it means is access to functions. Incorrect or insufficient access control or authorization related to system actors, rules, assets and permissions, may certainly lead to security issues. Indeed, the notion of assets, actors and actions in the context of trust and threat models should be reviewed with the utmost care to avoid such security issues.

Remember that functions can have different visibility. public and external functions are those that can be called by any user interacting with the smart contract.

So from an access control perspective, we need to make sure that the right set of addresses can call these functions. We need to ask know if it might be okay for anyone to access these functions, any address to access this function, or it might be required only for the Owner to access this or there could be an extensive role based access control that is desirable as well.

This means that when we are reviewing smart contracts for security, we need to make sure that the right access control is enforced by the use of the correct modifiers. That make sure that the correct checks are enforced on the different sets of addresses used with the smart contract. Any of these missing checks either missing modifiers or the use of incorrect addresses or even the access control specification might allow attackers to control critical logic that is executed within some of these critical functions.

Withdrawal of Funds

Smart contracts typically manage a significant amount of funds related to the amount of Ether or the ERC20 tokens that they hold and manage it in different ways for different users. So they have different functionality for users to deposit these funds and similarly they have different mechanisms for users to withdraw their funds.

These withdrawal functions need to be protected, from an access control perspective. What this means is that, if these withdrawal functions are unprotected, that's if they are public and external and they do not have the right access control enforced on the different addresses via checks implemented within the modifiers applied on these functions, then it may let attackers call these unprotected withdrawal functions and withdraw Ether or ERC20 tokens that belong to other users. This unauthorized withdrawal leads to loss of funds for the users and loss of funds for the protocol itself.

So in this context of withdrawal of funds access control again becomes important, the security checks have to make sure that the right access control is applied with respect to the different addresses or different modifiers on these withdrawal.

selfdestruct

The use of the selfdestruct primitive is critical and dangerous from a security perspective. Remember that SELFDESTRUCT is an EVM instruction that is further supported by a Solidity primitive, which when used within the smart contract, destroys or kills that contract and transfers all its Ether balance to the specified recipient address.

So from a security perspective, any smart contract that uses selfdestruct within a particular function, needs to protect access to that function because, if not, an user can mistakenly call that function or an attacker can intentionally call that function to kill that contract and remove its existence thereafter.

This means that from a security perspective, unauthorized calls to functions within smart contracts that may use the self-destruct primitive should be prevented, so that the contract does not get killed intentionally or mistakenly.

Access control to such functions again becomes critical to make sure that only authorized users may call such functions. At a high level, even the use of self-destruct is considered as being very risky and dangerous from a security perspective.

Previous3.1 Solidity VersionsNext3.3 Modifiers

Last updated 1 year ago

📚
🔏