Flask-AppBuilder 使用 OpenID 认证类型时存在不正确的身份验证

The impact of CVE-2024-25128 is significant due to its potential for unauthorized privilege escalation. An attacker could deploy a custom OpenID service, accessible to the vulnerable Flask-AppBuilder application. By crafting malicious HTTP requests, the attacker can manipulate the authentication flow, causing the application to authenticate against their controlled service. This allows the attacker to impersonate legitimate users and gain access to sensitive data and functionality within the application. The blast radius extends to any data or actions accessible by users with elevated privileges within the Flask-AppBuilder application.

Organizations deploying Flask-AppBuilder with the AUTHTYPE AUTHOID authentication method are at significant risk. This includes applications utilizing custom OpenID providers or those deployed in environments where attackers can potentially control external services. Shared hosting environments where multiple applications share the same Flask-AppBuilder instance are also particularly vulnerable.

• python / flask: Inspect Flask-AppBuilder configuration for AUTHTYPE AUTHOID. Monitor application logs for unusual OpenID authentication requests.

# Example: Check Flask-AppBuilder configuration
import os
appbuilder_config = os.environ.get('FLASK_APPBUILDER_CONFIG', '')
if 'auth_type' in appbuilder_config.lower() and 'auth_oid' in appbuilder_config.lower():
    print('Potential vulnerability: AUTH_TYPE AUTH_OID detected')

• generic web: Monitor access logs for requests to OpenID endpoints with unusual parameters. Check response headers for unexpected redirects. • database (mysql, postgresql): If Flask-AppBuilder uses a database for storing user credentials, review database queries for suspicious authentication patterns.

1. 2024-02-28Disclosure

   disclosure

1. 已保留2024-02-05
2. 发布日期2024-02-28
3. 修改日期2024-08-26
4. EPSS 更新日期2026-04-02

The primary mitigation for CVE-2024-25128 is to upgrade Flask-AppBuilder to version 4.3.11 or later. If an immediate upgrade is not feasible, consider implementing temporary workarounds. Carefully review and restrict the allowed OpenID providers configured within the application. Implement strict input validation on all user-supplied data related to authentication. Monitor authentication logs for suspicious activity, particularly requests originating from unexpected OpenID providers. After upgrading, confirm the fix by attempting to authenticate using a different OpenID provider and verifying that the application does not accept requests from unauthorized sources.