T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:61
- Finding
- Weather Queries Use Unencrypted HTTP Transport## Vulnerability Details **File Location**: `SKILL.md`, lines 61–76 **Vulnerability Type**: Plaintext HTTP communication **Risk Level**: Medium The documented wttr.in commands omit the explicit `https://` scheme: ```bash # One-line summary curl "wttr.in/北京?format=3" # More detailed current weather curl "wttr.in/北京?0" # Tomorrow curl "wttr.in/上海?1" # Weekly view curl "wttr.in/杭州?format=v2" # Custom one-line summary curl -s "wttr.in/深圳?format=%l:+%c+%t+(体感+%f),+风%w,+湿度%h" # JSON curl "wttr.in/北京?format=j1" ``` ### Technical Analysis When curl receives a URL without an explicit scheme, it commonly infers HTTP for this form of hostname. Consequently, the initial request is not guaranteed to use authenticated and encrypted TLS transport. Even if the service normally redirects HTTP requests to HTTPS, the original request and redirect response remain exposed to interception. The requested location and query parameters can be observed by a network-positioned attacker. An active attacker can also prevent a legitimate redirect and return a forged weather response directly. Because the skill is expected to summarize command output for the user, manipulated data may be presented as trustworthy weather information. ### Attack Path 1. A user requests weather information for a location. 2. The agent follows one of the documented wttr.in examples. 3. curl initiates a plaintext HTTP request because the URL has no explicit HTTPS scheme. 4. An attacker controlling or monitoring the local network, proxy, gateway, or another network segment observes the requested location. 5. An active attacker intercepts the request and returns fabricated weather data instead of allowing a secure connection or redirect. 6. The agent processes the forged response and gives the user inaccurate weather or travel advice. ### Impact Assessment The issue can disclose queried location information and compromise the integrity of weat ...[truncated 354 chars]
- Remediation
- ## Remediation Suggestions 1. Change every wttr.in URL to use an explicit `https://` scheme. 2. Restrict curl to HTTPS so protocol downgrades cannot occur. 3. Enable failure reporting to prevent HTTP error pages from being treated as valid weather data. 4. Retain redirect handling only when needed, while continuing to prohibit redirects to plaintext protocols. Recommended hardened form: ```bash curl --fail --show-error --location --proto '=https' \ "https://wttr.in/北京?format=3" ``` Apply the same controls to all wttr.in examples in `SKILL.md`. Where supported by the execution environment, also consider `--proto-redir '=https'` to ensure that redirects remain HTTPS-only.