T09 · Insecure Skill Coding Practices
Error
- Location
- manifest.json:7
- Finding
- Caller-controlled billing identity is exposed without declared authentication## Vulnerability Details **File Location**: `manifest.json:7-10`; related billing behavior documented in `skill.md:17-21` **Vulnerability Type**: Missing authentication for a billing-related API **Risk Level**: High ### Vulnerable Code `manifest.json:7-10` ```json "auth": { "type": "none" }, "api": { "type": "openapi", ``` `skill.md:17-21` ```markdown # ## 💰 计费与支付协议 # * **单次定价**：0.001 USD # * **支付机制**：本技能深度集成 **SkillPay 协议**。 # * **扣费流程**：调用时需传入 `user_id` 参数，系统将自动通过 SkillPay 平台进行透明的微额结算，开发者不存储用户支付私钥，确保资金安全。 ``` The billing documentation states that the caller supplies a `user_id` and that the system uses it for automatic SkillPay settlement. However, the manifest explicitly declares that the API requires no authentication. The supplied artifacts do not define a signed payment authorization, authenticated principal, ownership check, nonce, timestamp, or replay protection that securely binds the supplied identifier to its owner. ### Technical Analysis A caller-controlled identifier is not an authentication credential. If the backend trusts `user_id` when selecting the account to charge, an unauthenticated caller could submit another user's identifier. Even if SkillPay performs additional undocumented server-side checks, the published interface contract is insecure and does not communicate the controls clients must provide. The backend implementation is not included in the audited package, so successful unauthorized charging cannot be verified statically. The confirmed configuration issue is that a billing-related API is advertised with no authentication while its documented billing flow depends on caller-supplied identity. ### Attack Path 1. An attacker discovers or guesses another user's SkillPay identifier. 2. The attacker sends a POST request to the public `/api/v1/macro-report` endpoint. 3. The attacker places the target identifier in the request body's `user_id` field. 4. The API receives ...[truncated 737 chars]
- Remediation
- ## Remediation Suggestions - Require authenticated access to every billing-related operation. - Bind `user_id` to an authenticated principal instead of trusting a caller-selected identifier. - Require a server-verifiable SkillPay authorization token or signed payment intent covering the user, operation, amount, audience, and expiration time. - Add unique nonces and timestamps, persist consumed nonces, and reject expired or replayed authorizations. - Use opaque, non-enumerable account identifiers and apply rate limits to identity and payment failures. - Return authorization failures without revealing whether a submitted user identifier exists. - Update the manifest and OpenAPI security schemes to accurately describe the required authentication mechanism. - Add integration tests proving that altered identities, missing signatures, expired requests, and replayed requests are rejected before report generation or billing.