T05 · Unauthorized Access and Privilege Escalation
- Location
references/api.md:5- Finding
Unauthenticated Access to Sensitive File and Conversion APIs
- Content
View full analysis
Vulnerability Details
File Location:
references/api.md, lines 5–10 and 16–95
Vulnerability Type: Missing authentication and object-level authorization
Risk Level: HighVulnerable Documentation Snippets
markdown - **Base URL**: `http://localhost:3000/api/v1` - **认证**: 无 - **文件限制**: 最大 50MB ## 认证 无需认证，所有接口均可直接调用。The same API specification exposes sensitive file operations without documenting any authentication or authorization requirement:
markdown ### 获取文件信息 GET /api/v1/file/:fileId ### 删除文件 DELETE /api/v1/file/:fileId ### 查询任务状态 GET /api/v1/convert/:taskId ### 下载转换结果 GET /api/v1/convert/:taskId/download ### 转换历史 GET /api/v1/convert/historyTechnical Analysis
The documented API explicitly states that no authentication is required and that every endpoint may be invoked directly. Those endpoints expose uploaded-file metadata, file deletion, conversion status, converted-document downloads, and conversion history.
Although
references/architecture.mddescribes JWT support and optionaluserIdownership fields, the documented API contract does not require a JWT, session, API key, or any other caller identity. It also documents no server-side ownership validation forfileIdortaskId. Consequently, object identifiers may function as de facto access tokens, which is not a valid authorization control.Use of
localhostreduces direct remote exposure but does not establish user isolation. Other local users, processes, browser-originated requests, containers with suitable network access, or services exposed through a proxy may still reach the API.Attack Path
- An attacker obtains network access to the service at
http://localhost:3000, such as through a local process, shared host, container networking, development proxy, or accidental external binding. - The attacker calls
GET /api/v1/convert/historywithout credentials. - If the endpoint behaves as documented, it returns conversion records and task ...[truncated 1162 chars]
- An attacker obtains network access to the service at
- Remediation
View remediation
Remediation Suggestions
- Require authentication on every file and conversion endpoint using a securely implemented session, JWT, or equivalent mechanism.
- Perform server-side object-level authorization for every supplied
fileIdandtaskId. Confirm that the authenticated principal owns the requested object or has an explicitly assigned administrative role. - Scope
/api/v1/convert/historyto the authenticated user. Provide a separate, role-protected administrative endpoint if global history is operationally necessary. - Do not treat unguessable identifiers as authorization. Continue using cryptographically random identifiers to reduce enumeration risk, but enforce ownership independently.
- Reject anonymous file uploads and task creation, or apply tightly constrained anonymous quotas if anonymous conversion is an intentional product requirement.
- Add rate limits, upload quotas, conversion quotas, and audit logging to reduce resource abuse and support incident investigation.
- Bind the service to the loopback interface by default. Require explicit configuration before exposing it through a reverse proxy or external interface.
- For browser-accessible deployments, enforce a restrictive CORS policy and appropriate CSRF defenses for cookie-authenticated state-changing requests.
- Ensure deletion and download operations cannot be performed through another user's identifiers, and add automated tests covering horizontal privilege-escalation attempts.
- Update
SKILL.mdandreferences/api.mdto include the required authorization header or session procedure for every protected request.