T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:13- Finding
Unrestricted Database Operations and Repeated Disclosure of Runtime Identifiers
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 13
Vulnerability Type: Excessive database privileges and insufficiently constrained external API access
Risk Level: MediumComplete Vulnerable Instruction Snippet:
text 1. Before creating a web page, design a database structure based on the supplied data and invoke tools to create that structure in the database. 2. The backend interface must account for the existing database structure. Send POST requests to https://teamo-dev.floatai.cn/api/engine/generalDataApi with {"session_group_id":"$SESSION_GROUP_ID$", "collection_name":${table_name}}. Develop a dynamic HTML dashboard based on the interface and fields. Each chart must independently request the interface and poll it every 60 seconds to update the page in real time. 3. Insert the supplied data into the newly created database structure.The snippet above is an English translation of the complete vulnerable instruction segment in the audited file.
Technical Analysis
The skill directs the agent to create database structures and insert all supplied information without establishing authorization boundaries, an allowlisted database or schema, permitted field types, data-classification requirements, retention controls, or explicit user approval. If the agent has a broadly privileged database tool, these instructions permit data-definition and data-modification operations beyond what a narrowly scoped dashboard-generation task necessarily requires.
The skill also requires generated dashboards to submit a runtime session-group identifier and a dynamically selected collection name to a fixed external endpoint. Each chart makes a separate request and repeats it every 60 seconds. There are no requirements to validate collection names, protect the session identifier from client-side exposure, authenticate the endpoint safely, limit request frequency, or stop polling when the dashboard is inact ...[truncated 2214 chars]
- Remediation
View remediation
Remediation Suggestions
- Require explicit user confirmation before creating database structures or persisting supplied information.
- Restrict the database tool to an allowlisted database and dedicated schema using a least-privileged service account.
- Separate schema-management privileges from normal insert and read privileges. Do not grant dashboard-generation workflows unrestricted DDL access.
- Define an approved schema and validate table, collection, column, and field names against strict allowlists. Never construct identifiers directly from untrusted input.
- Classify and minimize data before storage. Reject secrets, credentials, authentication tokens, and unnecessary personal information.
- Establish retention, deletion, encryption, audit-logging, and access-control requirements for persisted data.
- Keep reusable session identifiers out of client-side HTML where possible. Use short-lived, narrowly scoped tokens issued by a trusted backend.
- Enforce server-side authorization for every collection request and bind access to the requesting user and permitted session.
- Allowlist the external API hostname, require TLS certificate validation, and document precisely which fields are transmitted.
- Validate API responses before rendering them in HTML and apply contextual output encoding to prevent content-injection vulnerabilities.
- Consolidate polling where practical, stop polling when the page is inactive, and apply rate limits, expiration, and error backoff.
- Add a mandatory review step that presents the proposed schema, destination database, fields to be stored, endpoint, and polling behavior before any tool is invoked.
