T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- SKILL.md:11
- Finding
- Optional Owner Validation Permits Unauthorized Access to Private Notes## Vulnerability Details **File Location**: `SKILL.md`, lines 11 and 43–45 **Vulnerability Type**: Missing mandatory requester authorization **Risk Level**: High **Complete vulnerable configuration and instruction snippets**: ```markdown metadata: {"openclaw": {"requires": {}, "optionalEnv": ["GETNOTE_API_KEY", "GETNOTE_CLIENT_ID", "GETNOTE_OWNER_ID"], "baseUrl": "https://openapi.biji.com", "homepage": "https://biji.com"}} ``` ```markdown ### 🔒 安全规则 - 笔记数据属于用户隐私，不在群聊中主动展示笔记内容 - 若配置了 `GETNOTE_OWNER_ID`，检查 sender_id 是否匹配；不匹配时回复「抱歉，笔记是私密的，我无法操作」 - API 返回 `error.reason: "not_member"` 或错误码 `10201` 时，引导开通会员：https://www.biji.com/checkout?product_alias=6AydVpYeKl ``` ### Technical Analysis The Skill treats `GETNOTE_OWNER_ID` as optional and requires sender identity validation only if that variable is configured. Consequently, when Getnote API credentials are present but the owner identifier is absent, the instructions do not require any authorization check before executing operations on private notes. Authentication to `openapi.biji.com` establishes the API credential holder's authority but does not establish that the person sending a chat request is the credential owner. In a shared Agent or group-chat deployment, this creates a confused-deputy condition: another participant can ask the Agent to use the owner's stored credentials. The instruction not to proactively display notes in group chats is not an effective authorization control. It does not prohibit responding to explicit requests to list, search, read, share, modify, tag, or delete notes. ### Attack Path 1. The account owner configures `GETNOTE_API_KEY` and `GETNOTE_CLIENT_ID` without configuring the optional `GETNOTE_OWNER_ID`. 2. The Agent is exposed to a group chat, shared workspace, or another environment containing an untrusted requester. 3. The requester issues a supported command such as `/note search`, `/note list`, a request to view a note, or an ins ...[truncated 1014 chars]
- Remediation
- ## Remediation Suggestions 1. Move `GETNOTE_OWNER_ID` from optional configuration to mandatory configuration for every deployment that can receive requests from more than one identity. 2. Fail closed before every Getnote operation if the Agent cannot obtain both a trusted sender identity and the configured owner identity. 3. Compare a platform-authenticated, canonical sender identifier against `GETNOTE_OWNER_ID`; never rely on a display name or user-supplied identifier. 4. Deny all note operations in group contexts unless the authenticated sender exactly matches the configured owner. 5. Perform the authorization check centrally before routing to save, search, list, knowledge-base, tag, configuration, sharing, update, or delete functionality. 6. Require explicit owner confirmation immediately before high-impact operations such as public sharing, destructive deletion, or bulk modification. 7. Request the minimum API scopes needed for enabled features and separate read-only credentials from write or deletion capabilities where supported. 8. Add tests covering missing owner configuration, mismatched senders, group-chat requests, malformed sender identifiers, and destructive operations. 9. Avoid logging API credentials, private note content, temporary media URLs, or other sensitive response data during authorization failures.