T09 · Insecure Skill Coding Practices
- Location
SKILL.md:120- Finding
Unsanitized Email Content Inserted into Authenticated Webmail Pages as HTML
- Content
View full analysis
{ const bodyField = document.querySelector('[role="textbox"][contenteditable="true"]'); if (bodyField) { bodyField.focus(); bodyField.innerHTML = body.replace(/\n/g, '
'); } }, emailBody) ``` The same unsafe sink is used throughout the other composition and reply procedures: ```javascript // Outlook composition bodyField.innerHTML = body.replace(/\n/g, '
'); // QQ Mail composition bodyField.contentDocument.body.innerHTML = body.replace(/\n/g, '
'); bodyField.innerHTML = body.replace(/\n/g, '
'); // 163 Mail composition bodyField.contentDocument.body.innerHTML = body.replace(/\n/g, '
'); bodyField.innerHTML = body.replace(/\n/g, '
'); // Gmail and Outlook replies if (bodyField) bodyField.innerHTML = body.replace(/\n/g, '
'); // QQ Mail and 163 Mail replies if (iframe) iframe.contentDocument.body.innerHTML = body.replace(/\n/g, '
'); ``` ### Technical Analysis The Skill directly assigns generated or user-controlled email content to the DOM `innerHTML` property. Replacing newline characters with `
` does not sanitize the remaining input. Consequently, HTML tags, attributes, remote resources, deceptive formatting, and potentially active browser content are interpreted as markup rather than inserted as plain text. This occurs inside an authenticated webmail page. Depending on the provider's DOM handling, browser security policy, and subsequent provider-side sanitization, crafted input can: - Insert arbitrary HTML into the message composer. - Load attacker-controlled remote resources, such as tracking images. - Create misleading links or visually deceptive me ...[truncated 2156 chars]- Remediation
View remediation
{ const bodyField = document.querySelector( '[role="textbox"][contenteditable="true"]' ); if (bodyField) { bodyField.focus(); bodyField.textContent = body; bodyField.dispatchEvent(new InputEvent('input', { bubbles: true, inputType: 'insertText', data: body })); } }, emailBody); ``` 2. Prefer provider-native typing or input APIs where available so content is entered through the same path as normal user text. 3. If rich HTML email is an explicit requirement, sanitize content using a maintained, strict allowlist before inserting it. At minimum, reject or remove: - `script`, `iframe`, `object`, `embed`, `form`, `style`, and `svg` elements. - All event-handler attributes such as `onclick` and `onerror`. - `javascript:`, `data:`, and other unsafe URL schemes. - Remote images and other externally loaded resources unless separately approved. - CSS capable of hiding, overlaying, or materially misrepresenting content. 4. Do not implement escaping by newline replacement alone. Build line breaks using text nodes and DOM elements, or rely on the editor's normal plain-text input behavior. 5. Present a final rendered preview and require explicit user confirmation immediately before sending. 6. Add tests using payloads such as HTML tags, image resources, event attributes, malformed markup, unsafe links, and bidirectional or hidden text to verify that they are rendered as harmless text. ]]>
