T09 · Insecure Skill Coding Practices
- Location
scripts/utils.py:20- Finding
Sensitive meeting and calendar data is written to plaintext debug logs
- Content
View full analysis
Vulnerability Details
File Location:
scripts/utils.py, lines 20–31
Vulnerability Type: Plaintext sensitive-data logging
Risk Level: MediumVulnerable Code
python logger.debug(f"执行命令: {' '.join(cmd)}") try: result = subprocess.run( cmd, capture_output=True, text=True, check=True ) response = json.loads(result.stdout) logger.debug(f"API 响应: {response}")Technical Analysis
Every Lark API command is logged after its request parameters and request body have been serialized into the command argument list. The complete parsed API response is then also logged.
Depending on the operation, these log entries can contain:
- Meeting subjects and descriptions.
- Meeting start and end times.
- Room IDs and room names.
- Calendar IDs and event IDs.
- Organizational room hierarchy and availability data.
- Attendee records and calendar metadata.
- Other information returned by the Lark API.
For example,
create_calendar_eventplaces the meeting subject, description, and timestamps in thedataargument._run_lark_cli_apiserializes that object withjson.dumpsand includes the resulting plaintext JSON in the debug log.Multiple methods in
scripts/lark_cli.pyalso log API results, including room-search results, availability responses, and primary-calendar metadata. Authentication tokens are not explicitly passed by this project and were not found in the reviewed code, but the request and response content can still contain confidential business and organizational data.Sending meeting information to Lark is necessary for the declared booking functionality. Writing the complete information to local or orchestrator logs is not necessary and exceeds minimum data exposure.
Attack Path
- A user or automation invokes the booking or initialization workflow.
- Meeting details and identifiers are passed to
lark-cliin the--dataor--paramsarguments. _run_lark_cli_apiwrite ...[truncated 1305 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove logging of complete command arguments and API responses.
- Log only non-sensitive operational metadata, such as:
- HTTP method.
- Static endpoint template.
- Success or failure status.
- Response code.
- Number of records returned.
- Implement a centralized redaction function for fields including
summary,description, timestamps, calendar IDs, event IDs, room IDs, attendees, page tokens, and any future credential fields. - Do not reconstruct the complete command with
' '.join(cmd)for logging. - Use structured logging with an explicit allowlist rather than attempting to denylist sensitive fields.
- Disable debug logging by default in production and ensure retained logs have restrictive permissions and short retention periods.
- Avoid returning complete stderr from
lark-clito higher-level exception messages unless it has been sanitized. - Review and remove the additional full-response logs in
scripts/lark_cli.py, especially room search, availability, and primary-calendar operations. - Add automated tests that submit marker secrets in meeting descriptions and verify that the markers never appear in captured logs.
