T09 · Insecure Skill Coding Practices
- Location
SKILL.md:50- Finding
Authentication Credentials May Be Sent to Unvalidated Configurable Endpoints
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill does what it claims, but it handles live PingCode session cookies and Git tokens in a way that needs careful review before use.
Review this skill before installing. Use it only for a PingCode account where automated work-item creation and hour logging are acceptable, store cookies and tokens with restrictive permissions, prefer least-privilege short-lived Git tokens, verify the configured PingCode and Git hosts before use, and do not export more cookies than necessary.
SKILL.md:50Authentication Credentials May Be Sent to Unvalidated Configurable Endpoints
README.md:65PingCode Session Cookies and Git Tokens Are Stored in Plaintext Without Required Access Controls
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
mkdir -p ~/.openclaw/skills/pingcode-timelogger
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
mkdir -p ~/.openclaw/skills/pingcode-timelogger
The README instructs users to export and store all PingCode cookies, which are effectively active session credentials and may allow full account access if stolen. Because the guidance lacks explicit warnings, scope minimization, file-permission advice, or safer alternatives, it normalizes insecure credential handling and increases the chance of credential leakage through local files, backups, logs, or accidental sharing.
The README tells users to create a plaintext Git token file using a shell echo command, but does not warn that the token is a reusable secret that may grant repository read or write access. This can expose the token through shell history, insecure file permissions, backups, or accidental disclosure, especially on shared systems.
The skill is designed to automate authenticated actions over time against PingCode and Git services, relying on persisted local configuration and session material. While this appears operational rather than malicious, persisted session context combined with broad triggers can enable repeated access to external systems without sufficiently fresh user intent, increasing the risk of unintended actions or credential misuse.
---
name: pingcode-timelogger
description: Automate PingCode timesheet filling — create sub-tasks and log work hours. Use when asked to fill PingCode timesheets, log work hours, create work items, or auto-generate timesheets from Git commits. Triggers on "fill PingCode", "log hours", "PingCode timesheet", "fill timesheet", "工时填报", "填工时", "PingCode填报", "根据Git提交填工时".
---
# PingCode TimeLogger
The trigger phrases are broad enough to activate on common requests like logging hours or filling timesheets, which can cause the skill to run in situations the user did not clearly intend. Because the skill performs write actions against production systems, over-triggering increases the risk of unintended task creation, timesheet submission, or prompting for sensitive credentials.
The skill instructs the agent to read cookie-based authentication material from local files and use it for authenticated API calls, but it does not require an explicit warning about the sensitivity of those credentials or obtain explicit consent before handling them. Cookie reuse can grant account-level access to PingCode, so mishandling, over-collection, or accidental disclosure could expose or modify production data.
The Git auto-fill flow directs the agent to access external Git APIs and retrieve commit history without an explicit user-facing notice that repository metadata will be transmitted to third-party services and summarized for timesheet generation. This creates privacy and confidentiality risk, especially if private repositories, sensitive commit messages, or enterprise Git instances are involved.
The first-time setup explicitly instructs users to create a persistent local skill directory and export full browser cookies for the PingCode domain into files. Persisting reusable session cookies on disk materially increases the chance of credential theft, lateral access by other local processes, or accidental leakage through backups, logs, or misconfigured file permissions.
If config file doesn't exist, walk user through setup:
1. Create config directory: `mkdir -p ~/.openclaw/skills/pingcode-timelogger`
2. Copy template: read `references/config-template.yaml` and save to config dir
3. User fills in PingCode URL
4. Guide user to export cookies (browser DevTools → Application → Cookies → copy all for the PingCode domain, or use a cookie export extension)
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Fetch commits for a date range:
GET https://api.github.com/repos/{owner}/{repo}/commits?author={username}&since={ISO8601}&until={ISO8601}
Authorization: Bearer <token>
The example interaction and generated task titles are entirely in Chinese, which implies the skill behavior is tailored to a specific language/locale. There is no indication that users can opt into another language or that the locale restriction is intentional and justified, which creates a natural-language policy concern.
The instructions refer directly to the PingCode UI label "工作类别" and the table includes Chinese category names, which presumes access to a Chinese-localized interface. The file does not state that this is specific to certain PingCode locales or offer guidance for users in other language settings.
This manifest/config template includes natural-language labels such as "任务" and "已完成" and later a Chinese-only work-category list, which implicitly assumes a Chinese-language PingCode setup. Under the language/locale policy, forcing a specific language without user opt-in or justification is a policy concern.
The comment and default value for work_category are entirely Chinese-language, which may impose a locale-specific workflow on all users. The file does not state that the skill is region-specific or give users an explicit language/locale option.
No suspicious patterns detected.