T09 · Insecure Skill Coding Practices
Error
- Location
SKILL.md:1129- Finding
Delegated Payment Token Sent to an Unverified Merchant Endpoint
- Content
View full analysis
dict: """Execute an ACP purchase using a Shared Payment Token. The flow: 1. Initiate checkout at the ACP merchant endpoint 2. Authorize via SPT 3. Record the transaction in GreenHelix for tracking """ # Step 1: Initiate checkout checkout_resp = http_client.post( checkout_url, json={ "service_id": service_id, "payment_method": "spt", "spt_token": spt_token, }, timeout=15, ) checkout_resp.raise_for_status() checkout_data = checkout_resp.json() ``` ### Technical Analysis The function transmits a Stripe Shared Payment Token directly to the caller- or vendor-provided `checkout_url`. It does not verify: - That the endpoint uses HTTPS. - That the endpoint belongs to the intended merchant. - That its origin is present in a trusted allowlist or signed merchant directory. - That redirects remain on an approved origin. - That DNS resolution does not target a private, loopback, link-local, or otherwise restricted address. - That the token is cryptographically bound to the expected merchant, service, amount, and endpoint. A malicious marketplace entry or compromised vendor record can therefore substitute an attacker-controlled checkout endpoint. The timeout limits request duration but does not protect the credential. ### Attack Path 1. An attacker publishes or modifies a vendor listing containing a malicious `checkout_url`. 2. The procurement agent discovers and selects the listing. 3. The payment router calls `purchase_acp` with a valid delegated payment token. 4. `purchase_acp` posts the raw `spt_token` to the attacker-controlled URL. 5. The attacker capture ...[truncated 907 chars]- Remediation
View remediation