T09 · Insecure Skill Coding Practices
- Location
references/session-management.md:63- Finding
Authentication state is stored in predictable files without enforced access controls
- Content
View full analysis
Vulnerability Details
File Location:
references/session-management.md:63-87; related examples appear inreferences/authentication.md:28-42,references/authentication.md:60-82,references/authentication.md:85-102,templates/authenticated-session.sh:14-20, andtemplates/authenticated-session.sh:88-89
Vulnerability Type: Insecure storage of reusable authentication state and unsafe temporary-file usage
Risk Level: MediumVulnerable Code
bash ### Authenticated Session Reuse ```bash #!/bin/bash # Save login state once, reuse many times STATE_FILE="/tmp/auth-state.json" # Check if we have saved state if [[ -f "$STATE_FILE" ]]; then agent-browser state load "$STATE_FILE" agent-browser open https://app.example.com/dashboard else # Perform login agent-browser open https://app.example.com/login agent-browser snapshot -i agent-browser fill @e1 "$USERNAME" agent-browser fill @e2 "$PASSWORD" agent-browser click @e3 agent-browser wait --load networkidle # Save for future use agent-browser state save "$STATE_FILE" fitext The authenticated-session template similarly defaults to a relative, persistent file: ```bash LOGIN_URL="${1:?Usage: $0 <login-url> [state-file]}" STATE_FILE="${2:-./auth-state.json}" if [[ -f "$STATE_FILE" ]]; then echo "Loading saved authentication state..." agent-browser state load "$STATE_FILE" agent-browser open "$LOGIN_URL" agent-browser wait --load networkidle fi # Save state for future runs # agent-browser state save "$STATE_FILE"Technical Analysis
Browser state files contain security-sensitive cookies and browser storage that may include reusable session tokens. The documented workflow writes that state to the fixed path
/tmp/auth-state.json, while the template recommends./auth-state.jsonor an arbitrary caller-supplied path.The examples ...[truncated 2509 chars]
- Remediation
View remediation
Remediation Suggestions
-
Store state under a user-private runtime or configuration directory rather than a fixed shared
/tmppath:bash umask 077 STATE_DIR="${XDG_RUNTIME_DIR:-$HOME/.local/state}/agent-browser" mkdir -p -- "$STATE_DIR" chmod 700 -- "$STATE_DIR" STATE_FILE="$STATE_DIR/auth-state.json" -
If state is needed only for the current workflow, generate an unpredictable path and remove it on exit:
bash umask 077 STATE_DIR="$(mktemp -d)" STATE_FILE="$STATE_DIR/auth-state.json" cleanup() { rm -f -- "$STATE_FILE" rmdir -- "$STATE_DIR" 2>/dev/null || true } trap cleanup EXIT -
After saving persistent state, explicitly restrict access:
bash agent-browser state save "$STATE_FILE" chmod 600 -- "$STATE_FILE" -
Before loading an existing state file, verify that it is a regular, non-symbolic-link file owned by the current user. Reject unexpected ownership, permissions, and paths.
-
Avoid sharing one fixed state filename between users, jobs, or application environments. Use per-user and per-application directories and filenames.
-
Add state files to version-control ignore rules, encrypt persistent state at rest where feasible, and establish a short retention period.
-
Revoke affected sessions and delete saved state securely after suspected disclosure. CI workflows should avoid persisting authentication state unless strictly necessary.
-