| शीर्षक | man-group dtale <=3.22.0 Improper Restriction of Excessive Authentication Attempts |
|---|
| विवरण | When authentication is enabled, D-Tale exposes a /login route that accepts username/password via an HTML form. On failure it simply re-renders the login template with an error and permits an immediate retry. The implementation contains:
-No rate limiting (no per-IP or per-account request throttling),
-No account lockout after repeated failures,
-No incremental delay / exponential backoff,
-No CAPTCHA or challenge-response,
-No attempt counter of any kind.
An attacker can therefore submit credential guesses as fast as the network and server allow. At a conservative 50–500 requests/second, a 1,000,000-entry wordlist (e.g. rockyou) is exhausted in roughly 5.6 hours down to ~36 minutes. Because credentials are stored and compared in plaintext (no hashing/salting), and the comparison uses Python's non-constant-time ==, any weak or default password is recovered quickly. The plaintext storage means the configured password is also directly disclosed by any read of the config file (~/.config/dtale.ini or DTALE_CONFIG), and the non-constant-time compare is a theoretical timing side channel (largely masked by network jitter in practice, hence listed as compounding rather than primary).
Once a valid username/password is found, the attacker logs in normally, the server sets session["logged_in"] = True / session["username"], and the requires_auth decorator grants full access to all protected routes. |
|---|
| स्रोत | ⚠️ https://github.com/man-group/dtale/issues/961 |
|---|
| उपयोगकर्ता | ZAST.AI (UID 87884) |
|---|
| सबमिशन | 26/06/2026 10:29 AM (2 महीनों पहले) |
|---|
| संयम | 14/08/2026 08:57 PM (2 months later) |
|---|
| स्थिति | स्वीकृत |
|---|
| VulDB प्रविष्टि | 390087 [mangroup dtale तक 3.22.0 Login Endpoint dtale/auth.py login सूचना का प्रकटीकरण] |
|---|
| अंक | 20 |
|---|