T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:43
- Finding
- Session Cookie Jar Is Created Without Restrictive File Permissions## Vulnerability Details **File Location**: `SKILL.md`, lines 43–46 **Vulnerability Type**: Insecure storage of an authenticated session token **Risk Level**: Medium ### Vulnerable Code ```sh export CROWNTOWN_USERNAME='you@example.com' export CROWNTOWN_PASSWORD='your-portal-password' # or: op read "op://Private/CrownTown/password" export CT=https://portal.crowntowncompost.com JAR=~/.cache/crowntown-cookies.txt mkdir -p ~/.cache && : > "$JAR" ``` The session cookie is subsequently stored and used through this file: ```sh grep -q sessionid "$JAR" && echo "signed in" || echo "NOT signed in" ``` ### Technical Analysis The Skill creates a persistent curl cookie jar using shell redirection but does not set a restrictive `umask`, secure the cache directory, or apply permissions such as mode `0600` to the file. Its final permissions therefore depend on the user's environment. If the file already exists, truncating it with `: > "$JAR"` also preserves its existing permissions. After authentication, the jar contains the Django `sessionid` bearer token. Any local principal able to read that token can replay it without knowing the user's password. The Skill also leaves the cookie jar on disk and provides no explicit logout or cleanup procedure, extending exposure until the session expires or is invalidated. Exploitation requires local access sufficient to read the cookie jar, so this is not independently exploitable by a remote unauthenticated attacker. ### Attack Path 1. A user follows the documented setup and creates `~/.cache/crowntown-cookies.txt`. 2. The file inherits permissive permissions from the environment or retains insecure permissions from an existing file. 3. The user logs in, causing curl to write the authenticated Django `sessionid` into the jar. 4. Another local account or process reads and copies the cookie jar. 5. The attacker supplies the stolen cookie in requests to `portal.crowntowncompost.com`. 6. The portal treats the attacker as the auth ...[truncated 760 chars]
- Remediation
- ## Remediation Suggestions Create both the directory and cookie jar with explicit owner-only permissions: ```sh install -d -m 700 "$HOME/.cache" JAR="$HOME/.cache/crowntown-cookies.txt" rm -f -- "$JAR" install -m 600 /dev/null "$JAR" ``` Alternatively, establish a restrictive umask before creating the file: ```sh umask 077 mkdir -p "$HOME/.cache" JAR="$HOME/.cache/crowntown-cookies.txt" : > "$JAR" chmod 600 "$JAR" ``` Further hardening should include: - Verify that the jar is a regular file owned by the current user before authentication. - Reject symbolic links to prevent writing cookies through an attacker-controlled path. - Avoid using this workflow on shared or untrusted hosts. - Delete the cookie jar after the task when session reuse is unnecessary. - Document and invoke the portal's logout endpoint, if available, to invalidate the server-side session before deletion. - Keep the existing practice of reading the password through standard input rather than exposing it in process arguments.