T09 · Insecure Skill Coding Practices
- Location
scripts/test_proxy.py:25- Finding
Proxy Credentials Exposed Through Command-Line Arguments and Console Output
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Kuaidaili proxy skill is mostly purpose-aligned, but it handles API and proxy credentials in ways that can expose them in command history, URLs, and logs.
Use Review-level caution before installing. Prefer environment variables or a secret manager, avoid passing real API signatures or proxy passwords in command-line arguments, avoid running this in CI or shared terminals without log redaction, and rotate any credentials that have already appeared in command history or captured output.
scripts/test_proxy.py:25Proxy Credentials Exposed Through Command-Line Arguments and Console Output
scripts/get_proxies.py:110Kuaidaili API Credentials Accepted Through Insecure Command-Line Arguments
scripts/get_proxies.py:62API Credentials Embedded in GET URLs May Leak Through Exception and Infrastructure Logs
Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.
params = {"secret_id": secret_id, "signature": signature}
try:
resp = requests.get(BALANCE_API, params=params, timeout=10)
resp.raise_for_status()
data = resp.json()
Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.
api_url = PROXY_TYPES.get(proxy_type, API_BASE)
try:
resp = requests.get(api_url, params=params, timeout=10)
resp.raise_for_status()
if format == "json":
The code aligns with one part of the description: retrieving proxy IPs from Kuaidaili, including selecting proxy type, count, area, protocol, and optional order_id as a request parameter. However, the broader declared description claims additional capabilities—checking account balance, managing proxy orders, and testing proxy connectivity—that are not present in this code chunk. There is no logic for querying balance endpoints, creating/updating/canceling orders, or validating proxy reachability. This is a description-to-behavior mismatch due to overclaiming material capabilities beyond what the code actually does.
The skill documents use of environment variables and outbound network access to a third-party proxy API, but it does not declare any tool scope such as permissions or allowed-tools. That omission weakens reviewability and policy enforcement, making it easier for a skill to access secrets and external services without explicit user or platform visibility.
The documentation instructs users to supply API credentials via environment variables or command-line arguments and shows those credentials being transmitted to an external service, but it gives no warning about credential sensitivity, logging exposure, shell history leakage, or third-party privacy implications. In a proxy-service skill, this is more sensitive because the service mediates outbound traffic and may expose account usage, network metadata, and potentially operational destinations.
This markdown file documents use of authentication secrets (secret_id, signature) and an administrative operation to set an IP whitelist, but it does not include any warning about protecting credentials or the impact of changing access controls. For markdown files, SQP-2 applies when descriptions omit warnings about behaviors that could affect privacy, security, or system integrity.
The script transmits API credentials as URL query parameters in a GET request, which can be exposed through client logs, proxy logs, browser/history equivalents, monitoring systems, or upstream infrastructure even when HTTPS is used. In a proxy-service integration, these secrets are valuable because compromise could allow account abuse, quota exhaustion, or unauthorized access to account information.
This markdown file describes setting API credentials and running commands that fetch proxies and test proxy connectivity, which can transmit account and network data to an external service. The README does not include any warning or disclosure about external network access, credential handling, or the implications of testing third-party proxies.
The usage example hard-codes a Chinese location value ("北京"), which suggests a locale-specific input convention without explaining that the skill is region-specific or offering alternatives. Under the language/locale policy, locale constraints should be optional, documented, or justified rather than implicitly imposed.
The file presents all user-facing documentation in Chinese and does not offer a language option or explain a region-specific requirement. Under SQP-3, forcing a specific language without user opt-in can be a natural-language policy violation.
The file's title, usage context, argument descriptions, and error messages are all presented only in Chinese, with no option for another language or explanation that the skill is intentionally region-specific. This can violate language/locale policy when a skill mandates a specific language without user opt-in.
The file's user-facing natural language, including the module description, usage context, and function docstring, is entirely in Chinese. Under the policy rule, a skill that imposes a specific language without opt-in or documented locale justification is a natural-language policy concern.
No suspicious patterns detected.