T09 · Insecure Skill Coding Practices
Warning
- Location
scripts/env.sh:5- Finding
JWT Bearer Tokens Stored Without Restrictive File Permissions
- Content
View full analysis
/dev/null || true)" fi if [[ -n "$email" ]]; then local file file="$(jwt_state_file_for_email "$email")" if [[ -f "$file" ]]; then JWT="$(cat "$file" 2>/dev/null || true)" return 0 fi fi JWT="${JWT:-}" } save_jwt_to_state() { local token="${1:-}" local email="${2:-${SESSION_EMAIL:-}}" if [[ -z "$token" || -z "$email" ]]; then return 0 fi mkdir -p "$STATE_DIR" local file file="$(jwt_state_file_for_email "$email")" printf '%s' "$token" > "$file" printf '%s' "$email" > "$JWT_STATE_CURRENT_EMAIL_FILE" } ``` ### Technical Analysis The skill persistently writes JWT bearer tokens and the current user's email address into predictable files beneath `scripts/.state`. It does not set a restrictive `umask`, explicitly assign mode `0600` to token files, or enforce mode `0700` on the state directory. Consequently, effective permissions depend on the process environment and its existing umask. In a permissively configured or shared runtime, other local users or processes may be able to read these files. A JWT is a bearer credential: possession is generally sufficient to authenticate as the affected user until the token expires or is revoked. The persistent `current_email` selector also allows later invocations without an explicit `SESSION_EMAIL` to load the most recently used account. This creates a risk ...[truncated 1250 chars]- Remediation
View remediation