T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:52
- Finding
- Shell Command Injection Through Unsanitized Supabase Request Parameters<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:52-81`, `SKILL.md:120-123`, and `SKILL.md:129-133` **Vulnerability Type**: Shell command injection and unsafe construction of HTTP requests **Risk Level**: High ### Vulnerable Code ```bash curl -s "[URL]/rest/v1/[table]?select=*&[filters]" \ -H "apikey: [KEY]" \ -H "Authorization: Bearer [KEY]" ``` ```bash curl -s -X POST "[URL]/rest/v1/[table]" \ -H "apikey: [KEY]" \ -H "Authorization: Bearer [KEY]" \ -H "Content-Type: application/json" \ -d '[JSON]' ``` ```bash curl -s -X PATCH "[URL]/rest/v1/[table]?[filter]" \ -H "apikey: [KEY]" \ -H "Authorization: Bearer [KEY]" \ -H "Content-Type: application/json" \ -H "Prefer: return=representation" \ -d '[JSON]' ``` ```bash curl -s -X DELETE "[URL]/rest/v1/[table]?[filter]" \ -H "apikey: [KEY]" \ -H "Authorization: Bearer [KEY]" ``` The skill also instructs the agent to construct these values directly: ```text Parse the user's data, construct JSON, POST it. ``` ```text Construct the filter, confirm with user before executing: "This will delete rows from [table] where [condition]. Proceed? (y/n)" ``` The RPC command uses another dynamically selected path and JSON body: ```bash curl -s -X POST "[URL]/rest/v1/rpc/[function_name]" \ -H "apikey: [ANON_KEY]" \ -H "Authorization: Bearer [ANON_KEY]" \ -H "Content-Type: application/json" \ -d '{"param": "value"}' ``` ### Technical Analysis The skill requires user-controlled project URLs, table names, filters, RPC function names, and JSON values to be substituted into shell command templates. It does not require strict validation, URL encoding, JSON-safe serialization, or shell-safe argument handling. Values inserted into double-quoted shell strings can introduce command substitutions such as `$(command)` or backtick expressions if the agent generates and executes the resulting command as shell source. Values inserted into the single-quoted `-d '[JSON]'` body can termina ...[truncated 2300 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Avoid generating executable shell command strings from user input. Use a structured HTTP client that accepts the URL, path, query parameters, headers, and JSON body as separate values. 2. If `curl` must be used: - Pass dynamic values through positional parameters rather than interpolating them into shell source. - Use `curl --get --data-urlencode` for query parameters. - Percent-encode each dynamic path component. - Generate JSON with a serializer such as `jq --arg` or `jq --argjson`; never concatenate JSON into shell-quoted text. - Disable interpretation of user input as shell syntax. 3. Validate identifiers with strict allowlists. For example, table, column, and RPC names should match an approved pattern such as `^[A-Za-z_][A-Za-z0-9_]*$` and, where possible, be checked against known schema objects. 4. Validate `SUPABASE_URL` before attaching credentials: - Require HTTPS. - Reject embedded credentials, fragments, control characters, and unexpected ports. - Restrict the hostname to the user's explicitly approved Supabase origin, such as the expected `*.supabase.co` project hostname or a separately confirmed custom domain. - Do not follow redirects to a different origin while retaining authorization headers. 5. Parse filters into a structured representation and allow only supported PostgREST operators. Encode column names and values independently instead of accepting a raw filter string. 6. Retain confirmation for destructive UPDATE and DELETE operations, but display the normalized destination, table, filter, and affected operation after validation. Confirmation must supplement rather than replace input sanitization. 7. Add explicit instructions prohibiting execution when any dynamic value cannot be safely validated or encoded. ]]>