T09 · Insecure Skill Coding Practices
- Location
SKILL.md:31- Finding
Ambiguous Preauthorization Can Bypass Order-Specific User Confirmation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:31-40, with conflicting requirements atSKILL.md:117-123
Vulnerability Type: Authorization workflow inconsistency
Risk Level: HighEvidence
The following is an English translation of the relevant source section:
markdown ## Trigger Conditions - The user explicitly requests that an order be placed. - The market-monitor produces a signal and the user has granted prior authorization (`confidence ≥ 0.85`). ## Preconditions (all must be satisfied before execution) 1. The user has explicitly confirmed the trading intent. 2. All risk checks have passed. 3. The trading pair is in the allowlist. 4. The API key for the target exchange is configured and valid.The security requirements later state:
markdown ## Security Constraints - User confirmation is mandatory and cannot be skipped or automatically confirmed by code. - exec = deny, write = deny. - All trading records are written to the audit log by the gateway. - Risk-control violations are automatically rejected and generate an alert.Technical Analysis
The trigger conditions permit execution when
market-monitorproduces a signal with a confidence value of at least0.85and the user has granted prior authorization. However, the preconditions and security constraints require explicit user confirmation and prohibit automatic confirmation.The specification does not define whether prior authorization satisfies the mandatory confirmation requirement. It also does not require a new confirmation tied to the final exchange, pair, side, order type, quantity, price, and total amount generated from the monitoring signal.
Because this Skill authorizes irreversible financial operations, an implementation may reasonably but unsafely interpret broad prior authorization as confirmation for every subsequent qualifying signal. No confirmation identifier, expiration period, immutab ...[truncated 1371 chars]
- Remediation
View remediation
Remediation Suggestions
- Require fresh, order-specific confirmation after all order parameters and risk checks have been finalized.
- Explicitly state that monitor preauthorization may initiate preparation of an order but cannot authorize submission.
- Bind confirmation to an immutable digest containing the exchange, pair, side, type, quantity, price or slippage limit, stop loss, take profit, and estimated amount.
- Assign every confirmation a unique identifier and short expiration period.
- Invalidate confirmation if any material order parameter changes.
- Require the user to confirm again after expiration, price deviation beyond an approved tolerance, or partial execution that changes the remaining strategy.
- Fail closed whenever confirmation state is missing, ambiguous, stale, or inconsistent.
- Record the confirmation identifier, parameter digest, timestamp, and final submitted parameters in the gateway audit log.