Location
- frontend/app/claim/[token]/
- frontend/lib/ (the call site that validates a token against bridgelet-sdk)
Problem
The /claim/[token] route accepts an arbitrary token in the URL and
presumably calls bridgelet-sdk to validate it. If there's no rate
limiting or anti-enumeration protection at the frontend layer (in addition
to whatever exists, or doesn't yet exist, at the SDK layer), an attacker
could script requests to this route trying many token values, hoping to
find a currently-valid, unclaimed token before its rightful recipient does.
Impact
Depending on the claim token's entropy and the SDK's default 30-day expiry
window (documented in bridgelet-sdk), a sufficiently determined attacker
performing sustained enumeration has a nonzero and worth-quantifying chance
of guessing a valid, unclaimed token and redeeming funds intended for
someone else. This is a direct funds-theft vector, not just a nuisance.
Fix
- Confirm the claim token's entropy (length/character set) is large enough
that brute-force guessing is computationally infeasible even without
rate limiting, and document that analysis.
- Regardless, add rate limiting at the edge (Next.js middleware or hosting-
platform level) for repeated /claim/[*] requests from a single
IP/fingerprint within a short window, coordinated with whatever rate
limiting exists (or should be added) in bridgelet-sdk.
- Ensure failed/invalid claim attempts don't leak information that would
help an attacker distinguish "token doesn't exist" from "token exists but
is expired/already claimed" (timing or response-shape side channels).
Acceptance criteria
Location
Problem
The
/claim/[token]route accepts an arbitrary token in the URL andpresumably calls
bridgelet-sdkto validate it. If there's no ratelimiting or anti-enumeration protection at the frontend layer (in addition
to whatever exists, or doesn't yet exist, at the SDK layer), an attacker
could script requests to this route trying many token values, hoping to
find a currently-valid, unclaimed token before its rightful recipient does.
Impact
Depending on the claim token's entropy and the SDK's default 30-day expiry
window (documented in bridgelet-sdk), a sufficiently determined attacker
performing sustained enumeration has a nonzero and worth-quantifying chance
of guessing a valid, unclaimed token and redeeming funds intended for
someone else. This is a direct funds-theft vector, not just a nuisance.
Fix
that brute-force guessing is computationally infeasible even without
rate limiting, and document that analysis.
platform level) for repeated
/claim/[*]requests from a singleIP/fingerprint within a short window, coordinated with whatever rate
limiting exists (or should be added) in
bridgelet-sdk.help an attacker distinguish "token doesn't exist" from "token exists but
is expired/already claimed" (timing or response-shape side channels).
Acceptance criteria