Skip to content

Hardcoded Flask session signing secret enables session forgery #364

Description

@H2u8s

[Security] Hardcoded Flask session signing secret enables session forgery

Summary

meta/env_future_trading/wt4elegantrl/wtpy/monitor/WtMonSvr.py configures the Flask application with the publicly committed secret !@#$%^&*(). An attacker who knows this value can forge Flask session data accepted by the application, enabling user impersonation when WtMonSvr is deployed and reachable.

Affected Version

Affected version: commit 15405db81ef46790d430341166700a61ba51b70d on branch master.

Technical Details and Root Cause

At WtMonSvr.py:264, the application uses the fixed value !@#$%^&*() as its Flask secret_key:

After successful login, user information and an expiration value are stored in the Flask session at the login handling code:

@app.route("/mgr/login", methods=["POST"])

Authentication checks accept these session fields:

The role and loginid session values are also used for authorization and resource selection:

@app.route("/mgr/cmtuser", methods=["POST"])

Since the signing secret is constant and present in public source, a forged session can contain attacker-selected identity and role fields that pass the application’s session-based checks.

Impact

An attacker who can reach a deployed WtMonSvr instance and knows the committed secret may forge an authenticated session without valid credentials. The affected identity is determined by the forged session fields; impact may include user impersonation and access to role-controlled interfaces or resources. The exact reachable endpoints and highest privilege require maintainer confirmation based on deployment configuration.

Reproduction Conditions

Deploy and expose the WtMonSvr Flask application with the affected configuration. A non-destructive validation should verify that the application uses !@#$%^&*() as its session signing key and that authentication and authorization decisions consume the session fields referenced above.

Recommended Fix

Remove the committed default and require a unique, high-entropy secret for every deployment. Rotate the exposed value and store the replacement in a server-side secret manager or equivalent protected configuration. Review existing session claims and avoid trusting client-controlled identity or role data without appropriate server-side validation.

This observation was identified during our ongoing research on authentication token security. We would be happy to provide additional technical details or assistance with preparing a patch. Please feel free to contact us if any clarification is needed.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions