T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/git_ctrl.py:140
- Finding
- Write-operation confirmation is enforced only through a caller-controlled flag<![CDATA[ ## Vulnerability Details **File Location**: `scripts/git_ctrl.py`, lines 140–148 **Vulnerability Type**: Insufficient authorization and confirmation enforcement **Risk Level**: Medium ### Vulnerable Code ```python parser.add_argument("--confirm", action="store_true") parser.add_argument("-n", type=int, default=10) parser.add_argument("--json", action="store_true") args = parser.parse_args() repos = load_repos() if args.command in WRITE_COMMANDS and not args.confirm: print(f"⚠️ '{args.command}' modifies the repo. Add --confirm to proceed.", file=sys.stderr) ``` ### Technical Analysis The skill states that write operations require explicit confirmation, but the implementation treats the presence of the caller-controlled `--confirm` command-line flag as proof that authorization was obtained. There is no independent confirmation prompt, approval token, trusted interaction state, or binding between the approval and the repository and operation being authorized. Consequently, any process or agent capable of invoking the script can add `--confirm` itself and immediately execute `pull` or `push`. The check therefore prevents accidental invocation without the flag but does not establish that the user knowingly approved the operation. This is especially relevant in an agent environment, where generated tool arguments may be influenced by misunderstood requests or malicious content. The affected operations can communicate with configured Git remotes. A push may transmit committed repository content, while a pull may modify the local working tree. Such network access is necessary for the declared synchronization functionality, but it should occur only after trustworthy authorization. ### Attack Path 1. An attacker influences an agent or another process that is permitted to execute the skill. 2. The influenced caller invokes a write operation and supplies the confirmation flag directly, for example: ```bash python3 scripts/git_ctrl.py push the ...[truncated 1563 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Do not treat a freely supplied Boolean command-line flag as proof of user consent. - Require confirmation through a trusted interaction channel that the invoking agent cannot synthesize on its own. - If non-interactive execution is required, issue a short-lived, single-use approval token from a trusted controller after explicit user confirmation. - Bind each approval to: - The exact command (`push` or `pull`). - The canonical repository path. - The remote and branch involved. - A short expiration time. - A nonce to prevent replay. - Before approval, display the exact operation and relevant consequences. For pushes, show the remote URL, branch, and commits to be transmitted. For pulls, show the remote branch and warn that the working tree may change. - Consider separating read-only and write-capable operations into different entry points or capabilities so routine status checks cannot silently transition into writes. - Canonicalize and revalidate the repository path immediately before execution. - Record authorization and execution events without logging credentials, tokens, or sensitive repository content. - Retain the current prohibition on destructive and forced operations, but document that remote Git operations necessarily use the current user's configured credentials and can transfer repository data. ]]>