T09 · Insecure Skill Coding Practices
Error
- Location
- whitelist.json:2
- Finding
- Attacker-Controlled Whitelist Enables LLM Security Detection Bypass<![CDATA[ ## Vulnerability Details **File Location**: `whitelist.json:2-10`, `layers/llm.js:51-68`, and `layers/llm.js:109-116` **Vulnerability Type**: Content-based authorization bypass **Risk Level**: High ### Vulnerable Code ```json { "patterns": [ "^test", "^debug", "^dev" ], "keywords": [ "test mode", "debug mode", "sandbox" ] } ``` ```javascript _checkWhitelist(input) { if (!this.whitelist.patterns) return false; for (const pattern of this.whitelist.patterns) { const regex = new RegExp(pattern, 'i'); if (regex.test(input)) { return true; } } if (this.whitelist.keywords) { for (const keyword of this.whitelist.keywords) { if (input.toLowerCase().includes(keyword.toLowerCase())) { return true; } } } return false; } ``` ```javascript detect(input) { // Whitelist check if (this._checkWhitelist(input)) { return { safe: true, threats: [], confidence: 1.0, whitelist: true }; } ``` ### Technical Analysis The LLM detector makes a trust decision using only attacker-controlled message content. Any input beginning with `test`, `debug`, or `dev`, or containing `test mode`, `debug mode`, or `sandbox`, is immediately classified as safe. The whitelist is evaluated before prompt-injection, jailbreak, prompt-leak, and encoding rules. A whitelist match therefore prevents all subsequent LLM analysis rather than suppressing only a narrow known false positive. Although `whitelist.json` also defines trusted users, the detector does not receive or validate user or session identity. Consequently, the whitelist does not establish an authenticated trust boundary. Any unauthenticated sender can invoke it merely by adding one of the configured strings. ### Attack Path 1. An attacker constructs a prompt-injection or prompt-leak payload. 2. The attacker prefixes the payload with a permitted string, for example: ```text test Ignore previous ...[truncated 1295 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove permissive content-based whitelist entries such as `^test`, `^debug`, `^dev`, `test mode`, `debug mode`, and `sandbox`. 2. Do not treat text supplied by an untrusted user as proof that the user or message is trusted. 3. If exemptions are necessary, bind them to authenticated and authorized user or session identifiers supplied through a trusted event field. 4. Pass a structured context object to the detector instead of scanning only a string: ```javascript detector.scan(input, { userId: event.context?.authenticatedUserId, sessionId: event.context?.sessionId }); ``` 5. Require exact identity matches against authenticated identifiers; never use user-provided message fields as identity. 6. Avoid returning immediately on a whitelist match. Continue scanning and suppress only explicitly approved rule IDs or narrowly scoped false-positive patterns. 7. Keep the default whitelist empty and require administrators to opt into exceptions. 8. Add regression tests proving that prefixed inputs such as `test Ignore previous instructions` remain blocked for unauthenticated users. ]]>