T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/send_media.py:334
- Finding
- Bearer Access Token Exposed in the Media Upload URL<![CDATA[ ## Vulnerability Details **File Location**: `scripts/send_media.py:334-342` **Vulnerability Type**: Bearer token exposure through a URL query parameter **Risk Level**: Medium ### Vulnerable Code ```python url = f"https://oapi.dingtalk.com/media/upload?access_token={access_token}&type={media_type}&robotCode={urllib.parse.quote(robot_code)}" req = urllib.request.Request( url, data=body_data, headers={ 'Content-Type': f'multipart/form-data; boundary={boundary}' } ) ``` ### Technical Analysis The media upload request embeds the DingTalk OAuth access token directly in the URL query string. Although the request uses HTTPS and is sent to an official DingTalk endpoint, TLS only protects the URL while it is in transit. It does not prevent the complete URL from being retained by HTTP client diagnostics, reverse proxies, monitoring systems, exception telemetry, or server-side access logs. Bearer tokens should generally be transported in an authorization header because any party that obtains such a token can use it without additional proof of identity. Placing the token in the URL increases its exposure surface compared with header-based authentication. This behavior supports the Skill's declared DingTalk media-upload functionality and does not indicate deliberate exfiltration to an unrelated service. The issue is the insecure transport location of the credential. ### Attack Path 1. A user invokes the Skill to upload a local media file. 2. The script obtains a DingTalk OAuth access token using the configured client credentials. 3. The script places the token in the media upload URL as `access_token`. 4. A proxy, diagnostic facility, monitoring service, or server access log records the complete request URL. 5. An attacker or unauthorized operator with access to those records extracts the token. 6. The attacker reuses the bearer token against DingTalk APIs before it expires. ### Impact Assessment Successful exploitation could pro ...[truncated 469 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Use a DingTalk media upload API that accepts the access token in an authorization header rather than a query parameter. 2. If the legacy endpoint strictly requires a query parameter: - Disable request URL logging for this endpoint. - Add URL-redaction logic that replaces the `access_token` value before logging or reporting errors. - Ensure proxies, telemetry agents, and monitoring systems do not retain query strings. - Keep access-token lifetimes as short as the platform permits. - Grant the DingTalk application only the permissions required for media upload and message sending. 3. Avoid including request URLs in exceptions or debug output. 4. Add tests verifying that tokens never appear in application logs, command output, or returned error objects. ]]>