Problem Statement
The token generator in use produces tokens with insufficient entropy, which are used as the sole access key for orders.
Description
Custom RNG implementation based on openssl_random_pseudo_bytes().
Exceptions thrown by this function are not caught → not fail-safe.
The $crypto_strong parameter is not evaluated , so it is not guaranteed that the generated bytes are cryptographically strong.
Reference
https://www.php.net/manual/en/function.openssl-random-pseudo-bytes.php
No guaranteed usage of a cryptographically secure random number generator (CSPRNG).
Hardcoded token length (10 characters , default in OrderFactory).
Optional numeric-only tokens .
No rate limiting on public endpoints that use these tokens.
No ReBAC and no additional authorization checks.
Impact
IDOR / BOLA due to guessable tokens.
Brute-force attacks are realistically possible.
Entropy
Best case (alphanumeric): ~59 bits
Worst case (numeric only): ~33 bits
In general, < 50 bits is security-critical for publicly exposed tokens.
Mitigation
Generate tokens with ≥ 128 bits of effective entropy
(e.g. random_bytes(32)).
Tokens must never be used as the sole authorization mechanism
(see issue Updatability #2 – Missing ReBAC).
Enforce ReBAC / user binding.
Apply rate limiting to all token-based endpoints .
@raphael-kat @papillo-solutions
Problem Statement
The token generator in use produces tokens with insufficient entropy, which are used as the sole access key for orders.
Description
openssl_random_pseudo_bytes().$crypto_strongparameter is not evaluated, so it is not guaranteed that the generated bytes are cryptographically strong.Reference
https://www.php.net/manual/en/function.openssl-random-pseudo-bytes.php
OrderFactory).Impact
Entropy
Mitigation
(e.g.
random_bytes(32)).(see issue Updatability #2 – Missing ReBAC).
@raphael-kat @papillo-solutions