CVE-2021-21241 in Flask-Security-Too
Summary
by MITRE • 01/12/2021
The Python "Flask-Security-Too" package is used for adding security features to your Flask application. It is an is a independently maintained version of Flask-Security based on the 3.0.0 version of Flask-Security. In Flask-Security-Too from version 3.3.0 and before version 3.4.5, the /login and /change endpoints can return the authenticated user's authentication token in response to a GET request. Since GET requests aren't protected with a CSRF token, this could lead to a malicious 3rd party site acquiring the authentication token. Version 3.4.5 and version 4.0.0 are patched. As a workaround, if you aren't using authentication tokens - you can set the SECURITY_TOKEN_MAX_AGE to "0" (seconds) which should make the token unusable.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/11/2021
The vulnerability identified as CVE-2021-21241 affects the Flask-Security-Too Python package, a widely used security extension for Flask applications that provides authentication and authorization features. This package serves as an independently maintained fork of the original Flask-Security, specifically based on version 3.0.0, and is commonly deployed in web applications requiring robust security mechanisms. The flaw exists in versions between 3.3.0 and 3.4.4, creating a significant security risk that impacts the authentication token handling mechanism within the package's login and password change endpoints.
The technical implementation flaw stems from improper handling of authentication tokens in HTTP GET requests to the /login and /change endpoints. When users authenticate or change their passwords through these endpoints, the system returns authentication tokens in the response body without requiring CSRF protection. This design decision creates a critical vulnerability because GET requests are inherently susceptible to cross-site request forgery attacks and are often cached or logged by intermediaries. The absence of CSRF token validation for these specific endpoints allows malicious actors to craft malicious websites that can silently steal authentication tokens from authenticated users who visit those sites, effectively enabling session hijacking attacks.
The operational impact of this vulnerability extends beyond simple token theft, representing a serious breach of web application security principles. Attackers can exploit this weakness by embedding malicious JavaScript code in third-party websites that make GET requests to the vulnerable endpoints, thereby obtaining valid authentication tokens without user interaction. This creates a pathway for unauthorized access to user accounts, potential data breaches, and privilege escalation attacks. The vulnerability particularly affects applications that rely on token-based authentication mechanisms and could lead to complete account compromise, as demonstrated by the ATT&CK framework's T1566 technique for credential access through social engineering.
The security implications align with CWE-352, which specifically addresses Cross-Site Request Forgery vulnerabilities, and CWE-287, which covers improper authentication mechanisms. The vulnerability demonstrates a failure in implementing proper request validation and token management practices, as outlined in OWASP Top Ten categories A07:2021 - Identification and Authentication Failures. Organizations using affected versions of Flask-Security-Too face significant risk exposure, particularly those with applications handling sensitive user data or requiring strong authentication controls. The patch released in versions 3.4.5 and 4.0.0 addresses the core issue by implementing proper CSRF protection for these endpoints and ensuring that authentication tokens are not exposed through GET requests.
Mitigation strategies for this vulnerability include immediate upgrading to patched versions 3.4.5 or 4.0.0, which provide proper CSRF protection mechanisms. For organizations unable to upgrade immediately, the recommended workaround involves setting SECURITY_TOKEN_MAX_AGE to zero seconds, effectively rendering authentication tokens immediately invalid. This temporary solution prevents token reuse but does not address the underlying CSRF vulnerability. Additional protective measures include implementing Content Security Policy headers, monitoring for suspicious authentication token usage patterns, and ensuring proper input validation across all endpoints. Security teams should also conduct thorough vulnerability assessments of their Flask applications to identify other potential CSRF vulnerabilities and implement comprehensive security testing practices to prevent similar issues in the future.