T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/image_ocr.py:69
- Finding
- Authentication Credential Material Exposed in Request URL<![CDATA[ ## Vulnerability Details **File Location**: `scripts/image_ocr.py`, lines 69–81 and 135–140 **Vulnerability Type**: Authentication material exposure through URL query parameters **Risk Level**: Medium ### Vulnerable Code ```python # Build authorization string authorization = f'hmac username="{self.api_key}", algorithm="hmac-sha256", headers="host date request-line", signature="{signature}"' authorization_base64 = base64.b64encode(authorization.encode('utf-8')).decode('utf-8') # Build final URL with query parameters params = { 'authorization': authorization_base64, 'host': host, 'date': date } return f"{self.API_HOST}?{urlencode(params)}" ``` The generated URL is subsequently used for the network request: ```python # Send request response = requests.post( auth_url, json=request_data, headers={"Content-Type": "application/json"}, timeout=60 ) ``` ### Technical Analysis The authorization value contains the API key identifier and an HMAC signature: ```text hmac username="<API key>", algorithm="hmac-sha256", ..., signature="<signature>" ``` This value is Base64-encoded and placed in the URL query string. Base64 is an encoding mechanism, not encryption, so any party that obtains the URL can decode the authorization value without a secret. URLs are frequently recorded by reverse proxies, HTTP debugging infrastructure, application-performance monitoring systems, exception handlers, server access logs, and network observability products. HTTPS protects the request while it is transmitted, but it does not prevent the complete URL from being recorded at endpoints or trusted intermediary infrastructure. The API secret itself is not directly included in the URL. Furthermore, the signature contains a date and may therefore have a limited replay window. These constraints limit the scope of exploitation, but they do not eliminate disclosure of the API key identifier or possible replay of captured signed requests. This behavio ...[truncated 1993 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Prefer an authorization header** - Confirm whether the iFlytek endpoint supports authentication through the standard `Authorization` header or another dedicated header. - If supported, place the authorization value in that header instead of the query string. 2. **Redact authentication query parameters** - If the vendor protocol requires query-string authentication, configure clients, proxies, gateways, monitoring systems, and server logs to redact the `authorization` parameter. - Ensure exception-reporting and tracing systems do not capture the complete authenticated URL. 3. **Avoid exposing the generated URL** - Do not print, serialize, persist, or include `auth_url` in errors or diagnostic output. - Add an explicit URL-sanitization helper for any future logging. 4. **Restrict log access and retention** - Apply least-privilege access controls to proxy, application, and observability logs. - Minimize retention of records containing query strings. - Encrypt retained logs and audit access to them. 5. **Strengthen replay resistance** - Use the shortest timestamp validity period supported by the service. - Where supported, include a unique request nonce or request identifier in the signed material. - Monitor for repeated use of identical signatures. 6. **Rotate potentially exposed credentials** - If authenticated URLs may already have entered logs, review those systems and rotate the affected API key and secret as a precaution. ]]>