ovice.in — XSS and unsafe token handling (high-level)

What this is

High-level rewrite of a 2022 vulnerability report against the ovice web app (login/lobby flows). The original discussed XSS, weak token storage, and privilege impact. Actionable payloads and exploit reproduction are omitted.

Vulnerability class (concept)

• Cross-site scripting (XSS) in an authenticated web surface.
• Secrets in JavaScript reachable state (e.g., apiToken hung off a global window object) so script execution can read session material.
• Authorization that is effectively “whoever holds the token” for sensitive workspace APIs (role changes), without stronger step-up or binding checks.
• Predictable or enumerable identifiers in API bodies (sequential user/workspace ids), which eases abuse after session theft.

Impact (abstract)

XSS in this design can escalate from “script in a page” to session theft and privilege escalation inside workspaces (including admin-capable actions if APIs accept the stolen token). That risks account takeover and workplace data exposure.

Mitigations / what to check

• Store session material in HttpOnly, Secure, Host-only cookies (or equivalent), not window globals.
• Enforce CSP, output encoding, and strict sanitization on any user-influenced HTML/SVG/object/embed paths.
• Bind sensitive actions to CSRF protections, re-auth, and server-side authorization independent of a single long-lived bearer copied from JS.
• Prefer workspace-scoped, rotatable tokens; avoid one token reusable across all workspaces.
• Make internal ids non-inferable; always authorize on server-side membership, not client-supplied ids alone.

Solve steps and PoC omitted.