T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/login.py:4
- Finding
- Reusable Authentication State Stored in a Predictable Plaintext Project File<![CDATA[ ## Vulnerability Details **File Location**: `scripts/login.py:4, 23-25`; `scripts/post.py:5, 16-17` **Vulnerability Type**: Plaintext storage of sensitive authentication data **Risk Level**: Medium ### Vulnerable Code From `scripts/login.py`: ```python STATE_FILE = os.path.join(os.path.dirname(os.path.dirname(__file__)), "state.json") ``` ```python # Save the authentication state context.storage_state(path=STATE_FILE) print(f"Session saved to {STATE_FILE}") ``` From `scripts/post.py`: ```python STATE_FILE = os.path.join(os.path.dirname(os.path.dirname(__file__)), "state.json") ``` ```python context = browser.new_context(storage_state=STATE_FILE) page = context.new_page() ``` ### Technical Analysis The login script exports Playwright browser storage state to a predictable file named `state.json` in the project root. Playwright storage-state files can contain reusable authentication cookies and local-storage values associated with the authenticated Xiaohongshu account. The implementation does not enforce owner-only file permissions, encrypt the stored state, move it to a protected user-specific credential directory, or provide source-control exclusion and lifecycle guidance. Actual default permissions depend on the operating system and process `umask`, but the script itself does not guarantee that the file is accessible only to the account owner. The publishing script subsequently loads this file directly into a new browser context, demonstrating that the stored data is intended to restore an authenticated session. If the file is exposed through permissive local permissions, backups, project archives, synchronization, or accidental source-control commits, another party may be able to reuse the session subject to Xiaohongshu's server-side session validation and expiration controls. ### Attack Path 1. A user runs `scripts/login.py` and authenticates to Xiaohongshu. 2. The script writes the resulting cookies and browser storage values to the ...[truncated 1402 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Store authentication state outside the project tree in an operating-system-appropriate user-private configuration or credential directory. 2. Create the destination directory with owner-only permissions and enforce restrictive permissions on the state file, such as mode `0600` on POSIX systems. 3. Write the state atomically to avoid partially written or unexpectedly inherited files. 4. Add `state.json` and equivalent session artifacts to `.gitignore`, packaging exclusions, backup exclusions, and documentation. 5. Clearly label the file as sensitive authentication material and warn users not to share, upload, archive, or commit it. 6. Where practical, protect the state using an operating-system credential store or encryption backed by a key that is not stored alongside the encrypted file. 7. Provide a logout or session-revocation workflow and a secure cleanup command that removes local state and invalidates the corresponding server-side session. 8. Validate ownership and permissions before loading an existing state file. Refuse to use files that are accessible by unintended users where the platform supports this check. 9. Consider requiring explicit user confirmation immediately before publishing, especially when a previously saved session is restored. ]]>