oVice Picket static object — high-level

Archived report on oVice-style workspace static objects, specifically a Picket object with an HTML-capable editor. Attack payloads and token-theft procedures are omitted.

Theme

Users with permission to create or edit static objects can open an editor (Quill-based in the report) for Picket content. Object add/click/update APIs persist and serve that content to other workspace visitors.

Root-cause concepts

• Stored XSS via rich text / HTML that is not strictly sanitized on write or safely encoded on read
• Editor allowlists that still permit dangerous markup patterns (including issues associated with older Quill lines called out in the source)
• CSP gaps: frame-ancestors alone is not enough when script-src / object-src are unset, so injected script can load further code
• Privilege model: anyone who can edit a visible object can plant content for higher-privileged viewers

Impact (abstract)

Script in a victim’s browser session can bypass client-side checks and, depending on how tokens are stored, lead to session abuse or privilege misuse inside the workspace.

Mitigations / lessons (aligned with the source’s countermeasure section)

• Sanitize on input and encode on output; keep a tight HTML allowlist for editor embeds
• Upgrade and harden the rich-text stack; disable raw HTML where product allows
• Ship a real CSP: restrict script-src / default-src to the app origin; prefer nonces or hashes for first-party scripts
• Treat static-object HTML as untrusted even when authored by “admins”
• Prefer HttpOnly, secure, SameSite cookies and avoid exposing bearer tokens to page script

Solve steps and PoC omitted.