T05 · Unauthorized Access and Privilege Escalation
Error
- Location
references/permission_gate_full.py:39- Finding
Caller-Controlled Permission Level Allows Authorization Bypass
- Content
View full analysis
bool: """判断是否允许执行。未显式注册的工具默认拒绝。""" if tool_name in self._readonly_tools: return True if tool_name not in self._permissions: return False # 未注册工具默认拒绝 required = self._permissions[tool_name] return level >= required def request_approval(self, tool_name: str, reason: str = "") -> str: """生成授权请求（由调用方展示给用户）""" return ( f"⚠️ 需要授权执行 {tool_name}\n" f" 原因: {reason or '未指定'}\n" f" 确认吗？(y/n)" ) ``` ### Technical Analysis The authorization decision accepts `level` directly from the caller and compares it with the configured requirement. The gate does not derive the caller's effective permission from an authenticated user, trusted session, capability, or approval record. Consequently, any caller able to invoke: ```python gate.can_execute("sensitive_tool", PermissionLevel.ADMIN) ``` can satisfy the check for every registered tool, including tools configured as `WRITE` or `ADMIN`. The `_permissions` mapping therefore behaves as a table of required levels, not as a record of permissions actually possessed by a principal. The approval mechanism is also disconnected from enforcement. `request_approval()` only formats a string; it does not create a pending approval, verify a user response, issue a single-use authorization token, or alter the result of `can_execute()`. An integration that treats a successful call to `can_execute()` as sufficient authorization can therefore bypass the advertised confirmation requirement. The included examples reinforce the ambiguity by calling `can_execute()` without supplying an effective authorization level while asserting that `WRITE` and ...[truncated 1398 chars]- Remediation
View remediation
bool: required = self._requirements.get(tool_name) if required is None: return False effective = self._resolve_permission(principal) return effective >= required ``` - Keep tool requirements and principal grants in separate mappings with unambiguous names such as `_tool_requirements` and `_principal_permissions`. - Do not automatically authorize a tool merely because it was labeled read-only. Validate the tool's implementation and bind the classification to a trusted registration record. - Implement approvals as verified state transitions. A successful approval should produce a short-lived, scoped, single-use token bound to the authenticated user, tool name, normalized arguments, and expiration time. - Consume and invalidate approval tokens atomically when the protected operation starts. - Add tests for `NONE`, `READ`, `WRITE`, and `ADMIN` principals against every requirement level, including attempts to forge a higher level. - Correct the examples so their expected results match the implementation and demonstrate a complete authenticated approval flow. ]]>