✅Quiz

Secureum Bootcamp Security Pitfalls & Best Practices 201 Quiz • Ventral DigitalVentral Digital

Slot 5 Quiz

Note: All 8 questions in this quiz are based on the InSecureumToken contract shown below. This is the same contract you see for all the 8 questions in this quiz. The InSecureumToken contract implements a token contract which allows users to buy tokens by depositing Ether (at a certain conversion ratio), and transfer tokens.

pragma solidity 0.7.0;

contract InSecureumToken {

mapping(address => uint) private balances;

uint public decimals = 10**18; // decimals of the token
uint public totalSupply; // total supply
uint MAX_SUPPLY = 100 ether; // Maximum total supply

event Mint(address indexed destination, uint amount);

function transfer(address to, uint amount) public {
   // save the balance in local variables
   // so that we can re-use them multiple times
   // without paying for SLOAD on every access
   uint balance_from = balances[msg.sender];
   uint balance_to = balances[to];
   require(balance_from >= amount);
   balances[msg.sender] = balance_from - amount;
   balances[to] = safeAdd(balance_to, amount);
}


/// @notice Allow users to buy token. 1 ether = 10 tokens
/// @dev Users can send more ether than token to be bought, to donate a fee to the protocol team.
function buy(uint desired_tokens) public payable {
   // Check if enough ether has been sent
   uint required_wei_sent = (desired_tokens / 10) * decimals;
   require(msg.value >= required_wei_sent);

   // Mint the tokens
   totalSupply = safeAdd(totalSupply, desired_tokens);
   balances[msg.sender] = safeAdd(balances[msg.sender], desired_tokens);
   emit Mint(msg.sender, desired_tokens);
}


/// @notice Add two values. Revert if overflow
function safeAdd(uint a, uint b) pure internal returns(uint) {
   if (a + b < a) {
      revert();
   }
   return a + b;
}
}

---

Q1 The InSecureumToken contract strictly follows the specification of

• A) ERC20

• B) ERC777

• C) ERC721

• D) None of the above

Comment:

Since decimals was defined as uint (same as uint256) and not as uint8 as ERC20 or ERC777 standardized, it can't strictly be either of them. And since this is clearly a fungible token contract, it can't be ERC721.

Q2 To avoid lock of funds, the following feature(s) MUST be implemented before contract deployment

• A) A transferFrom() function

• B) A burn() function

• C) A way to withdraw/exchange/use Ether from the contract

• D) None of the above

Q3 Which of the following assertion(s) is/are true (without affecting the security posture of the contract)?

• A) buy() does not need payable keyword

• B) balances must be private

• C) transfer() can be external

• D) safeAdd() can be public

Q4 The total supply is limited by

• A) 10**18

• B) 100 * 10**18

• C) 100

• D) None of the above -> MAX_SUPPLY is not used in the code

Q5 The following issue(s) is/are present in the codebase

• A) An integer underflow allows one to drain Ether

• B) Unsafe rounding allows one to receive new tokens for free -> uint required_wei_sent = (desired_tokens / 10) * decimals

• C) A division by zero allows one to trap/freeze the system

• D) None of the above

Q6 The following issue(s) is/are present in the codebase

• A) A front-running allows one to pay less than expected for tokens

• B) A lack of access control allows one to receive tokens for free

• C) Incorrect balance update allows one to receive new tokens for free

• D) None of the above

Comment:

No requests made before/after a function call would be able to change the token price. All of the functions are intended to be used by users, so no "access control" would be possible without excluding users. A user can send all of their tokens to themselve, which will double their balance due to the pre-loaded variable reuse.

Q7 The following issue(s) is/are present in the codebase

• A) A reentrancy allows one to drain Ether

• B) A reentrancy allows one to drain the tokens

• C) A reentrancy allows one to receive new tokens for free

• D) None of the above

Q8 The following issue(s) is/are present in the codebase

• A) An integer overflow allows one to drain Ether

• B) An integer overflow allows one to receive new tokens for free

• C) An integer overflow allows one to trap/freeze the system

• D) None of the above

Comment:

While it is indeed possible to exploit an overflow at the multiplication ((desired_tokens / 10) * decimals), it doesn't allow you to receive FREE tokens (although it makes them a bargain).