CVSS: 5.4EPSS: 0%CPEs: 1EXPL: 0CVE-2020-15105 – In Django Two-Factor Authentication, user passwords are stored in clear text in the Django session
https://notcve.org/view.php?id=CVE-2020-15105
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authentication code. This means that the password is stored in clear text in the session for an arbitrary amount of time, and potentially forever if the user begins the login process by entering their username and password and then leaves before entering their two-factor authentication code. The severity of this issue depends on which type of session storage you have configured: in the worst case, if you're using Django's default database session storage, then users' passwords are stored in clear text in your database. In the best case, if you're using Django's signed cookie session, then users' passwords are only stored in clear text within their browser's cookie store. • https://github.com/Bouke/django-two-factor-auth/blob/master/CHANGELOG.md#112---2020-07-08 https://github.com/Bouke/django-two-factor-auth/commit/454fd9842fa6e8bb772dbf0943976bc8e3335359 https://github.com/Bouke/django-two-factor-auth/security/advisories/GHSA-vhr6-pvjm-9qwf • CWE-312: Cleartext Storage of Sensitive Information •
CVSS: 2.4EPSS: 0%CPEs: 1EXPL: 0CVE-2020-4071 – Timing attack on django-basic-auth-ip-whitelist
https://notcve.org/view.php?id=CVE-2020-4071
In django-basic-auth-ip-whitelist before 0.3.4, a potential timing attack exists on websites where the basic authentication is used or configured, i.e. BASIC_AUTH_LOGIN and BASIC_AUTH_PASSWORD is set. Currently the string comparison between configured credentials and the ones provided by users is performed through a character-by-character string comparison. This enables a possibility that attacker may time the time it takes the server to validate different usernames and password, and use this knowledge to work out the valid credentials. This attack is understood not to be realistic over the Internet. • https://github.com/tm-kn/django-basic-auth-ip-whitelist/security/advisories/GHSA-m38j-pmg3-v5x5 https://groups.google.com/forum/#%21msg/django-developers/iAaq0pvHXuA/fpUuwjK3i2wJ • CWE-208: Observable Timing Discrepancy •
CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0CVE-2019-10682
https://notcve.org/view.php?id=CVE-2019-10682
django-nopassword before 5.0.0 stores cleartext secrets in the database. django-nopassword versiones anteriores a 5.0.0, almacena secretos en texto sin cifrar en la base de datos. • https://github.com/relekang/django-nopassword/blob/8e8cfc765ee00adfed120c2c79bf71ef856e9022/nopassword/models.py#L14 https://github.com/relekang/django-nopassword/commit/d8b4615f5fbfe3997d96cf4cb3e342406396193c https://github.com/relekang/django-nopassword/compare/v4.0.1...v5.0.0 • CWE-312: Cleartext Storage of Sensitive Information •
CVSS: 8.8EPSS: 0%CPEs: 1EXPL: 0CVE-2020-5224 – Session key exposure through session list in Django User Sessions
https://notcve.org/view.php?id=CVE-2020-5224
In Django User Sessions (django-user-sessions) before 1.7.1, the views provided allow users to terminate specific sessions. The session key is used to identify sessions, and thus included in the rendered HTML. In itself this is not a problem. However if the website has an XSS vulnerability, the session key could be extracted by the attacker and a session takeover could happen. En Django User Sessions (django-user-sessions) versiones anteriores a 1.7.1, las vistas proporcionadas permiten a usuarios finalizar sesiones específicas. • https://github.com/Bouke/django-user-sessions/security/advisories/GHSA-5fq8-3q2f-4m5g https://github.com/jazzband/django-user-sessions/commit/f0c4077e7d1436ba6d721af85cee89222ca5d2d9 • CWE-287: Improper Authentication CWE-326: Inadequate Encryption Strength •
CVSS: 6.1EPSS: 0%CPEs: 1EXPL: 0CVE-2019-15486
https://notcve.org/view.php?id=CVE-2019-15486
django-js-reverse (aka Django JS Reverse) before 0.9.1 has XSS via js_reverse_inline. django-js-reverse (también conocido como Django JS Reverse) anterior de la versión 0.9.1 tiene XSS a través de js_reverse_inline. • https://github.com/ierror/django-js-reverse/compare/v0.9.0...v0.9.1 https://github.com/ierror/django-js-reverse/pull/81 • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') •