T09 · Insecure Skill Coding Practices
- Location
weather.sh:272- Finding
Plaintext HTTP Requests Expose Location Queries and Weather Responses
- Content
View full analysis
Vulnerability Details
File Location:
weather.sh, lines 272 and 284
Vulnerability Type: Plaintext transmission of location data and untrusted terminal output
Risk Level: MediumComplete Vulnerable Code
bash # Fetch weather data from wttr.in local weather_data weather_data=$(curl -s "wttr.in/${city_en}?format=j1" 2>/dev/null) || { get_error_message "$lang" "fetch_failed" return 1 } if [[ -z "$weather_data" ]]; then get_error_message "$lang" "city_not_found" return 1 fi # For now, use simple format local result result=$(curl -s "wttr.in/${city_en}?format=3" 2>/dev/null) || { get_error_message "$lang" "fetch_failed" return 1 }The response is subsequently printed without control-character sanitization:
bash echo "$result"Technical Analysis
Both
curlURLs omit an explicithttps://scheme. Curl consequently treats these as plaintext HTTP requests. The user-supplied location, which may be a city or precise coordinates, is transmitted without transport encryption.An attacker with an on-path network position can observe the queried location and alter the server response. Because the resulting text is printed directly to the user's terminal, a modified response may contain misleading weather information or terminal control sequences. The location is also interpolated into the URL without explicit URL encoding, reducing request robustness for characters with special URL significance.
Although
weather.shis documented as a reference implementation rather than the primary JavaScript entry point, it is executable and contains a complete main routine, so the vulnerable behavior can be invoked directly.Attack Path
- A user invokes
weather.shwith a city name or coordinate pair. - The script places that location in a request to
wttr.inover plaintext HTTP. - An attacker capable of observing or modifying the user's network traffic intercepts the request.
- The attacker learns the requ ...[truncated 1008 chars]
- A user invokes
- Remediation
View remediation
Remediation Suggestions
- Require HTTPS explicitly for every request:
bash weather_data=$(curl \ --fail \ --silent \ --show-error \ --proto '=https' \ --connect-timeout 5 \ --max-time 15 \ "https://wttr.in/${encoded_city}?format=j1")Apply the same controls to the second request.
-
URL-encode the location before inserting it into the request path. Prefer a reliable encoding implementation rather than directly interpolating
city_en. -
Avoid making two requests when one validated JSON response can provide all required data. Parse the HTTPS JSON response locally.
-
Sanitize externally supplied text before writing it to a terminal. At minimum, remove nonessential C0/C1 control characters and escape sequences.
-
Do not discard all curl errors with
2>/dev/null; retain safe diagnostic information so TLS and protocol failures are visible. -
Consider removing
weather.shfrom the distributable package if it is only a reference implementation, or clearly prevent its execution and direct users exclusively to the HTTPS-based JavaScript implementation.