T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/ari.py:1144
- Finding
- Server-Controlled Auto-Confirmation Can Trigger Paid Analysis Without Explicit User Approval<![CDATA[ ## Vulnerability Details **File Location**: `scripts/ari.py:1144-1148` and `scripts/ari.py:1353-1357` **Vulnerability Type**: Server-controlled authorization of chargeable operations **Risk Level**: Medium ### Vulnerable Code From `scripts/ari.py:1144-1148`: ```python # 首次体验免确认（服务端策略 skill.autoConfirm）：前几次小额直接生成，不再多问一轮。 auto_confirmed = False if not confirm and q_data.get("autoConfirm") and q_data.get("sufficient"): confirm = True auto_confirmed = True ``` From `scripts/ari.py:1353-1357`: ```python # 首次体验免确认：服务端 autoConfirm=true 且「采集 + 报告」合计不超过单次上限时，直接跑完。 # 在聊天里多问一句「确认吗」，很多用户就不回了——先让他拿到结果。 auto_max = int(analysis_quote.get("autoConfirmMaxCredits") or 0) auto_confirmed = (not args.confirm and bool(analysis_quote.get("autoConfirm")) and sufficient and total_credits <= auto_max) ``` The behavior is also directed by `SKILL.md:95-97` and `SKILL.md:148-151`, which instruct the Agent to proceed without asking the user when the service returns an auto-confirmation state. ### Technical Analysis The CLI normally uses the local `--confirm` option as the authorization boundary for chargeable operations. These branches bypass that boundary when the remote API returns `autoConfirm=true`. Both the permission to proceed and, in the VOC path, the applicable spending threshold are derived from remote response fields. Consequently, the same service that reports the price and account state can authorize execution without a fresh user decision. This is unsafe because a compromised service, incorrect backend policy, account-state error, or malformed response could cause a command invoked without `--confirm` to perform a paid operation. The charge occurs before the user receives the post-execution `autoConfirmNote`. This issue does not grant operating-system privileges or expose arbitrary local files. Its scope is the authenticated ARI account and the consumption of its available credits. ### Attack Path 1. A user requests a VOC or oth ...[truncated 1427 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require a local `--confirm` flag for every operation that can consume credits. A remote response must not be sufficient to convert an unconfirmed request into a chargeable request. 2. Treat `autoConfirm` and `autoConfirmMaxCredits` as informational fields only. Return the quote to the user instead of automatically executing it. 3. If persistent automatic approval is required, make it an explicit local user preference: - Store the preference in the protected local configuration. - Require the user to set a numeric maximum explicitly. - Apply a conservative local upper bound. - Never increase that limit based on a server response. 4. Bind approval to the complete quoted transaction, including operation type, ASIN, site, collection pages, and exact maximum credit cost. Re-quote if any field changes. 5. Display the exact charge and balance before execution, then require affirmative approval unless a previously configured local limit covers the transaction. 6. Record a local audit entry for automatically approved transactions, including timestamp, request identifier, quoted amount, and the local policy that authorized execution. 7. Update `SKILL.md` so that the Agent does not interpret a server-provided auto-confirmation flag as user consent. ]]>