Trick or Treat

Description: The use of keccak256 hash functions on predictable values like block.timestamp, block.number, or similar data, including modulo operations on these values, should be avoided for generating randomness, as they are easily predictable and manipulable. The PREVRANDAO opcode also should not be used as a source of randomness. Instead, utilize Chainlink VRF for cryptographically secure and provably random values to ensure protocol integrity.

• Found in src/TrickOrTreat.sol Line: 57

  uint256(keccak256(abi.encodePacked(block.timestamp, msg.sender, nextTokenId, block.prevrandao))) % 1000 + 1;

Impact:

1. Attackers can predict or manipulate the outcome of the randomness, leading to unfair advantages.

2. Vulnerable to front-running and other exploits, compromising the fairness and integrity of the protocol.

Proof of Concept:

• Scenario: An attacker could monitor the blockchain for transactions and manipulate the block timestamp or other parameters to influence the random number generation.

• Exploit: By controlling the block timestamp or mining a block, an attacker can ensure they receive a favorable outcome.

Recommended Mitigation:

1. Do not use block.timestamp, now or blockhash as a source of randomness

2. Try to use Chainlink VRF for cryptographically secure and provably random values to ensure protocol integrity.