Same-origin run preview sandbox lets untrusted preview JS use the viewer session #93

Summary

Run frontend preview is served on the studio origin at /preview/{sessionToken}/ and embedded in an iframe with sandbox tokens that include allow-scripts and allow-same-origin. Preview HTML/JS therefore shares the LoopForge origin with the logged-in studio. A viewer who opens Run → 前端预览 can have their authenticated session used for studio API actions via the parent window (and, when a preview backend is configured, via direct same-origin fetch because CSP connect-src then includes 'self').

HttpOnly on agentflow_user blocks document.cookie reads; it does not block credentialed same-origin requests initiated by script that shares the app origin.

Affected code (head c7114fca)

Conditions (threat model — not anonymous Internet)

This is not “any anonymous visitor gets a session.” Entry requires content control plus a logged-in viewer opening the in-app preview.

1. Content producer (attacker capability): someone who can cause a Run preview archive to contain attacker-influenced HTML/JS. Typical paths on this product:
   • Project member who can enable preview on an SOP (workflowSnapshot.preview.enabled / sourcePath such as dist) and run it so the agent (or build step) writes static files that are later archived (archive_preview / ArchiveDir).
   • Anyone who can otherwise influence agent-built static output under the configured preview sourcePath before finalization.
2. Victim: a signed-in studio user (cookie agentflow_user) who opens Run → 前端预览 so previewPaneHTML embeds /preview/{token}/ in the same-origin iframe with allow-scripts + allow-same-origin.
3. Out of band for the parent-access path: “独立窗口” uses window.open(url,'_blank','noopener') (runs.js ~826) and is outside the parent access path. Direct fetch('/api/…') from the preview document still depends on CSP connect-src when a backend is set.

Anonymous users without a session token cannot mint preview sessions through /api/… under normal auth-required deployments; possessing a leaked opaque preview URL loads preview content, but session-riding against studio APIs as described here targets a logged-in viewer of the in-app iframe.

Call chain (analytical — not executed in this audit)

1. SOP with preview enabled completes; runner/engine archives sourcePath into a tar.zst preview bundle (HTML/JS as produced in the workspace).
2. Viewer calls POST /api/runs/:id/preview/session; server returns url = same-host /preview/{token}/ via PublicURL.
3. Studio embeds that URL in an iframe with allow-scripts + allow-same-origin (runs.js:738).
4. Preview document origin equals the LoopForge app origin (sandbox is not opaque).
5. Parent path (always available for same-origin nested browsing with these sandbox flags): preview script can reach window.parent and invoke studio APIs with the viewer’s cookies, e.g. conceptually parent.fetch('/api/…', {credentials:'include', …}). CSP on the preview response does not constrain the parent document’s network access.
6. Direct path (when preview backend URL is set): previewCSP sets connect-src 'self' <backend>, so the preview document itself may fetch('/api/…') with same-site cookies. When backend is empty, connect-src is 'none' (direct connect blocked); the parent path remains.

Not claimed here: a live browser capture, a successful token mint, or any packet capture. The above is inferred from static source and the project’s own design note at §13.3.

Impact

• Session-equivalent actions as the viewing user (create personal API tokens, read/modify data that user can access through studio APIs), without reading document.cookie.
• Cross-user impact inside a shared installation/project: one member’s crafted or agent-produced preview can target another member who only opens the preview tab.
• Design trade-off is acknowledged upstream (Vite ESM vs opaque origin); space-artifact CSP shows a stricter pattern already used elsewhere in-tree.

Suggested fix

1. Prefer a dedicated preview origin (separate host) so allow-same-origin cannot equal the app origin.
2. Until then: never put the app API origin in preview connect-src as 'self'; keep API on a different origin than preview files.
3. Treat framebust / parent nullification as defense-in-depth only (bypassable); not the primary control.
4. Revisit whether Vite ESM can be served without same-origin sandbox (blob workers, opaque origin + absolute module map, or separate origin).
5. Add a regression test that documents/fails closed on parent/API access attempts from preview active content.

Acceptance criteria

• Preview active content cannot perform credentialed calls to the studio API as the viewing user (separate origin and/or CSP that never allows app 'self' API connect from preview).
• In-app iframe embedding cannot reach window.parent app privileges from preview script (separate origin, or equivalent isolation).
• Threat model for agent-built preview bundles updated; automated regression covers the isolation property.
• Issue text and tests do not claim a browser PoC unless one is separately recorded.