T09 · Insecure Skill Coding Practices
- Location
scripts/create_order.py:39- Finding
Test-only payment safety claims are not enforced by the implementation
- Content
View full analysis
Vulnerability Details
File Location:
scripts/create_order.py:39-62
Related Locations:SKILL.md:10-20,README.md:3-9,scripts/create_order.py:229-230
Vulnerability Type: Unenforced security boundary and misleading operational scope
Risk Level: HighVulnerable Code
python url = "https://moss.lakala.com/ord-api/unified/v3" request_data = { "head": { "versionId": "1.0", "serviceId": "lfops.moss.order.pay", "serviceSn": generate_service_sn(), "systemCode": "MOSS", "channelId": "API", "businessChannel": "C00000404" }, "request": { "order_no": order_no, "total_amount": str(total_amount), "mer_no": "M00002042", "pay_scene": "0", "account_type": "ALIPAY,WECHAT,UQRCODEPAY", "order_eff_time": "30", "subject": subject, "remark": remark, "callback_url": callback_url } }The successful execution path also displays the returned payment URL and directs the user to use it to complete payment.
Technical Analysis
The Skill documentation states that all operations occur in a test environment, do not involve real funds, and produce links without payment capability. The implementation does not technically enforce those guarantees.
The script sends an order directly to
https://moss.lakala.com/ord-api/unified/v3, specifies Alipay, WeChat, and UnionPay QR payment channels, extracts the returned counter URL, and presents it as a payment link. It contains no sandbox environment selector, test-host allowlist, mock transport, test-merchant verification, maximum test amount, or explicit confirmation before the external request.The hardcoded merchant number
M00002042is described as a test merchant, but that status is not verified by the code. Consequently, the repository alone cannot establish that the endpoint and returned links are i ...[truncated 1639 chars]- Remediation
View remediation
Remediation Suggestions
- Replace the endpoint with a provider-documented sandbox endpoint or use a local mock server by default.
- Require explicit environment configuration, such as
--environment sandbox, and reject any other environment unless the user provides separate, informed confirmation. - Maintain an allowlist of approved sandbox hosts and validate the configured endpoint before transmitting an order.
- Verify that the merchant identifier is assigned to the sandbox environment rather than relying on a documentation statement.
- Validate returned payment URLs against an approved sandbox hostname before displaying them.
- Add a strict test-amount ceiling and clearly label every generated order and URL as sandbox data.
- Do not tell users that payment is impossible unless that property is guaranteed by enforceable technical controls.
- For any production-capable mode, require explicit confirmation, separate merchant configuration, authentication or signing controls, and prominent warnings that funds may be transferred.
- Document exactly which order fields are sent to the external service and obtain user confirmation before transmission.
