T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/verify_bankcard_three.py:25
- Finding
- Banking, identity, and credential data transmitted over plaintext HTTP<![CDATA[ ## Vulnerability Details **File Location**: `scripts/verify_bankcard_three.py:25`, `scripts/verify_bankcard_three.py:111-120`; insecure direct-call instructions also appear in `SKILL.md:59-60` **Vulnerability Type**: Plaintext transmission of sensitive information **Risk Level**: High ### Vulnerable Code ```python API_URL = "http://v.juhe.cn/verifybankcard3/query" ``` ```python params = urllib.parse.urlencode({ "key": api_key, "bankcard": bankcard, "realname": realname, "idcard": idcard, }) url = f"{API_URL}?{params}" try: with urllib.request.urlopen(url, timeout=15) as resp: data = json.loads(resp.read().decode("utf-8")) ``` The Skill documentation explicitly recommends the same insecure request: ```text GET http://v.juhe.cn/verifybankcard3/query?key=YOUR_KEY&bankcard=卡号&realname=姓名&idcard=身份证号 ``` ### Technical Analysis The script constructs an unencrypted HTTP request containing: - The full bank card number - The cardholder's legal name - The full national identity number - The Juhe API credential Because the endpoint uses `http://` rather than `https://`, TLS does not protect the confidentiality, integrity, or authenticity of the request and response. Network intermediaries can inspect the request or alter the returned verification result. All sensitive values are also embedded in the URL query string. URLs are commonly recorded by HTTP servers, reverse proxies, gateways, monitoring systems, and debugging tools. Consequently, even if transport encryption were added, using query parameters would still create avoidable logging exposure unless the provider requires this request format and all relevant logs are appropriately protected. The script masks the bank card and identity numbers in its final terminal JSON output, but this masking happens only after the complete values have already been transmitted. It therefore does not mitigate network or URL-log exposure. Sending these values to the declared Juhe veri ...[truncated 1701 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace the HTTP endpoint with the provider's officially supported HTTPS endpoint. Do not silently fall back to HTTP. 2. Confirm that certificate and hostname verification remain enabled. Fail closed if TLS negotiation or certificate validation fails. 3. If the provider supports it, send sensitive values in a POST body rather than in URL query parameters. 4. Send the API credential through the provider's recommended authorization header where supported, instead of embedding it in the URL. 5. Prevent redirects from HTTPS to HTTP, or validate every redirect target before following it. 6. Update `SKILL.md` so that all documented examples use HTTPS and discourage direct requests that expose personal data in URLs. 7. Inform users clearly that their bank card number, legal name, and identity number will be sent to a third-party verification provider, and obtain appropriate consent before transmission. 8. Avoid accepting the API key through `--key` where possible because command-line arguments can appear in shell history and process listings. Prefer a protected environment variable or a credential store. 9. Ensure `.env` files containing credentials are excluded from version control and have restrictive filesystem permissions. 10. Minimize logging throughout the request path and redact bank card numbers, identity numbers, names, API keys, and complete request URLs from errors and diagnostic output. ]]>