T09 · Insecure Skill Coding Practices
- Location
github-trending-daily.py:23- Finding
Hard-Coded DingTalk Webhook Credential
- Content
View full analysis
Vulnerability Details
File Location:
github-trending-daily.py, line 23
Vulnerability Type: Hard-coded secret / plaintext access token
Risk Level: HighVulnerable Code
python DINGTALK_WEBHOOK = "https://oapi.dingtalk.com/robot/send?access_token=0d8da1a9a2f0360d7a4c086bb849127b53ed36984db025c5c649083185ebd8fe"Technical Analysis
A DingTalk robot webhook URL containing an access token is embedded directly in the source code. Anyone who can read the repository, a distributed Skill package, source archives, logs containing the source, or repository history can recover this credential.
The script uses this URL as an authorization-bearing endpoint when transmitting Markdown messages. Possession of the URL may therefore allow an attacker to submit messages directly to the associated DingTalk robot without running the Skill. A configured DingTalk security keyword could limit accepted payloads, but it is not a substitute for protecting and rotating the webhook credential.
Attack Path
- An attacker obtains a copy of the Skill source or accesses its repository history.
- The attacker extracts the complete DingTalk webhook URL and
access_tokenfrom line 23. - The attacker constructs a DingTalk-compatible JSON request, including any required security keyword.
- The attacker sends the request directly to the exposed webhook endpoint.
- If the credential remains active and server-side controls accept the request, the robot posts the attacker-controlled message to its configured DingTalk destination.
Impact Assessment
Successful exploitation does not provide local operating-system privileges or arbitrary code execution. It may provide unauthorized use of the configured DingTalk robot within the webhook's existing scope.
Potential impact includes:
- Impersonating the legitimate notification Skill.
- Sending spam, misleading links, or social-engineering content.
- Disrupting the integrity and reliability of automated notif ...[truncated 154 chars]
- Remediation
View remediation
Remediation Suggestions
- Revoke and rotate the exposed DingTalk webhook token immediately; removing it from the current source alone does not invalidate copies or repository history.
- Remove the webhook URL from source code and load it from a protected environment variable or secret manager, for example:
python import os DINGTALK_WEBHOOK = os.environ.get("DINGTALK_WEBHOOK") if not DINGTALK_WEBHOOK: raise RuntimeError("DINGTALK_WEBHOOK is not configured")- Configure the secret only in the runtime environment. Restrict access to configuration files and ensure they are excluded from version control.
- Redact webhook URLs and tokens from application output, exception reporting, CI logs, and diagnostic bundles.
- Enable available DingTalk safeguards, such as request signing, keyword restrictions, source IP restrictions, and rate limits. Store signing secrets using the same protected mechanism.
- Add automated secret scanning to commits and CI pipelines to prevent future credential disclosure.
- If repository history is accessible, remove the credential from historical revisions where practical while still treating rotation as mandatory.