T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/freshrss.sh:27
- Finding
- FreshRSS API credentials exposed through an unencrypted and unencoded authentication URL<![CDATA[ ## Vulnerability Details **File Location**: `scripts/freshrss.sh`, lines 27–29 **Vulnerability Type**: Credentials embedded in a GET URL without HTTPS enforcement or URL encoding **Risk Level**: Medium ### Vulnerable Code ```bash auth_login() { local RESPONSE RESPONSE=$(curl -s "${API_BASE}/accounts/ClientLogin?Email=${FRESHRSS_USER}&Passwd=${FRESHRSS_API_PASSWORD}") ``` ### Technical Analysis The authentication request interpolates `FRESHRSS_USER` and `FRESHRSS_API_PASSWORD` directly into a GET URL. This creates the following security risks: 1. **Credential exposure through process arguments:** The expanded URL, including the API password, is supplied as a `curl` command-line argument. A sufficiently privileged local process may be able to observe it through process-inspection facilities while the request is running. 2. **Credential leakage into logs:** URLs can be recorded by the FreshRSS server, reverse proxies, monitoring systems, debugging tools, or other HTTP infrastructure. Embedding credentials in the query string therefore increases the chance that they will be retained in plaintext logs. 3. **Plaintext transmission is permitted:** The script accepts an arbitrary `FRESHRSS_URL` and does not require an `https://` scheme. If the URL uses HTTP, the username, password, authentication token, and retrieved feed data can be observed or modified by an on-path attacker. 4. **Missing URL encoding:** Credentials are concatenated without percent-encoding. Characters such as `&`, `#`, `?`, `+`, or `=` can change the interpretation of the query string, cause authentication failure, or introduce unintended request parameters. ### Attack Path 1. A user configures the Skill with a FreshRSS URL and API credentials. 2. The `auth_login` function expands the username and password into the `curl` URL. 3. An attacker obtains the resulting URL by: - inspecting process arguments with sufficient local permissions; - accessing application, reverse-pro ...[truncated 1065 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require `FRESHRSS_URL` to use HTTPS and reject insecure or malformed schemes before sending credentials: ```bash case "$FRESHRSS_URL" in https://*) ;; *) echo "Error: FRESHRSS_URL must use HTTPS." >&2 exit 1 ;; esac ``` 2. Use the authentication endpoint's POST capability, if supported by the deployed FreshRSS version, instead of placing credentials in the query string. 3. Apply proper form encoding to both the username and password. Use `curl` facilities such as `--data-urlencode` rather than manually concatenating values. 4. Avoid exposing secrets in process arguments. Supply sensitive request data through standard input, a protected file descriptor, or another mechanism that does not place the expanded password in the command line. If a temporary credential file is unavoidable, create it with restrictive permissions, ensure reliable cleanup with `trap`, and never place it in a shared predictable path. 5. Add transport and HTTP error handling, for example `--fail-with-body --show-error --silent`, and configure reasonable connection and request timeouts. 6. Ensure reverse proxies and FreshRSS access logs do not record authentication request bodies or sensitive query parameters. Rotate the API password if URLs containing it may already have been logged. 7. Consider validating `FRESHRSS_URL` to reject embedded credentials, fragments, control characters, and unexpected URL forms before constructing `API_BASE`. ]]>