Exemple - Decentralized registry system
Consider a decentralized registry system where users can claim domain names by combining a username with a top-level domain. The contract uses a mapping to track ownership, with the key generated by hashing the concatenated strings. This design appears reasonable at first glance since each user should have a unique combination of name and domain.
The vulnerability lies in the boundary ambiguity between the two string parameters. When Alice attempts to register ("alice", "example.com"), the contract concatenates these into "aliceexample.com" before hashing.
However, an attacker monitoring the mempool can front-run her transaction by registering ("aliceexample", ".com") instead, which produces the identical concatenated string and therefore the same hash.
Scenario: Alice registers ("alice", "example.com")
Attack: Bob finds a collision and registers first
When Alice attempts registration, it fails because Bob already owns that hash key. Bob effectively squatted on Alice's intended registration through collision.
Below is a small proof of concept to find collisions:
Exemple 2 - Signature Collision Attack
Hash collisions in signature verification can enable privilege escalation:
An attacker can craft colliding (action, target) pairs to reuse a valid signature for unauthorized operations:
Admin signs: ("transfer", "100")
Attacker submits: ("transfe", "r100") with the same signature