[C-1] Catastrophic Time Validation Vulnerability Creating Exploitable Contract State

Description

The contract doesn't validate that eventStartDate is less than eventEndDate in the constructor, creating a critical vulnerability that can be exploited in multiple ways. This flaw fundamentally breaks the contract's temporal logic and creates exploitable states.

Risk

Likelihood: HIGH

Impact: HIGH

If eventStartDate > eventEndDate, multiple catastrophic states are created:

1. Deposit Trap: Users can deposit even after the event has technically ended (if current time > endDate but < startDate), as the contract only checks block.timestamp >= eventStartDate to prevent deposits

2. Winner Selection Manipulation: A malicious owner can exploit this to set an arbitrary winner if they deploy with an end date in the past

3. Permanent Fund Lock: If owner never calls setWinner(), all funds remain permanently locked

Proof of Concept

The PoC demonstrates how a malicious deployer can create a broken contract by setting the end date before the start date:

This creates multiple exploitable states:

1. Users can deposit funds (as block.timestamp < startDate)

2. Owner can immediately set any winner (as block.timestamp > endDate)

3. Only users who selected the owner's chosen winner can withdraw

Recommended Mitigation

The fix adds proper validation in the constructor:

These checks prevent deployment with invalid time parameters, ensuring the contract's temporal logic functions correctly and can't be manipulated to trap user funds.

To futher improve consider adding following constants MIN_TIME_BEFORE_EVENT_START, MAX_TIME_BEFORE_EVENT_START and MIN_EVENT_TIME, MAX_EVENT_TIME to avoid unreasonable time.