fix(cdp): gate DOM.setFileInputFiles behind --allow-file-access - #586
Open
mnaza wants to merge 1 commit into
Open
fix(cdp): gate DOM.setFileInputFiles behind --allow-file-access#586mnaza wants to merge 1 commit into
mnaza wants to merge 1 commit into
Conversation
markjacksoncerberus
added a commit
to markjacksoncerberus/obscura
that referenced
this pull request
Aug 14, 2026
… COULD NOT NAVIGATE TO A FRAGMENT (location.hash had only a getter, pushState was a stub, window.open returned null, a dispatched click on <a href> navigated NOTHING, fonts.load resolved before the font arrived, and blur/focus fired UNTRUSTED) — Quests h4ckf0r0day#580–h4ckf0r0day#589 (ten quests, focus realm 208 -> 267/275, 0 regressions over 331 ritual rows) h4ckf0r0day#583 Same-document navigation exists: location.hash (+ the writable Location partials), fragment navigation with :target sync (a[name] included in the Rust selector), hashchange/popstate on a task, viewport-fallback unfocus for a real target only; history.pushState/replaceState with clone and same-origin checks; Node.moveBefore; a dispatched trusted click follows hyperlinks through the shared _followHyperlink. h4ckf0r0day#584 The sequential focus navigation starting point is a POSITION: flat-tree anchor chains captured at focus time survive removals, moved parents, slots and shadow hosts; clicks/blur/fixup/fragment set it; it outranks the focused element; backward navigation never lands ON a container it sits inside. sequential-focus-navigation-starting-point 0/20 -> 20/20. h4ckf0r0day#585 Autofocus is a QUEUE in temporal insertion order with a fragment-target gate and per-top-context settling; frame documents focus their host iframe chain (frame nodes' ownerDocument lies — routing walks the tree). h4ckf0r0day#586 The focus fixup rule, fully: fieldset-disabled with the first-legend escape, visibility from live inline declarations, style-write and insertion triggers, end-of-update-the-rendering timing. 1/8 -> 8/8. h4ckf0r0day#587 blur/focus/focusin/focusout dispatch TRUSTED as real FocusEvents with relatedTarget; focus({focusVisible}) overrides the modality heuristic; hasFocus() is false without a browsing context. h4ckf0r0day#588 window.open opens a WINDOW: a popup is a second top-level browsing context built from the frame machinery without a host element; its scripts run, load fires there, and focus never climbs into the opener. h4ckf0r0day#582 document.fonts.load()/.ready actually wait: a render-side resource pump op folds landed bytes and reports in-flight fetches; geometry re-ships once settled. h4ckf0r0day#580/h4ckf0r0day#581/h4ckf0r0day#589 (fork) empty <li> gets its marker's line box; marker layouts rebuild when a webfont arrives; ::before{display:list-item} generates a marker. marker-hit-testing 1/20 -> 7/20, marker-computed-size 3/8 -> 4/8. The region diff caught two real regressions and both were closed in-session: sandboxed and cross-origin frames' autofocus focused the iframe — the old code had no frame autofocus at all, so nothing had ever needed the gates. A new capability inherits every restriction the old incapacity was accidentally enforcing. Zero regressions: 331-row ritual pre/post diff (wpt_batch_par.sh, 4 shards); the one flagged row is the documented flaky img file, re-proven 201/167/210 on the same binary. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DOM.setFileInputFiles read client-supplied local file paths from disk and handed their bytes to page JS with no access control. Any client that can reach the CDP port (default localhost, but Docker images bind 0.0.0.0) could thus read any file the process can read — e.g. setFileInputFiles with files=["/etc/passwd"]. Page.navigate to file:// already guards this exact threat behind context.allow_file_access (off by default; opt in with `obscura serve --allow-file-access`). Apply the same gate here, refusing with a matching error before any std::fs::read when the flag is off. Adds a test proving the handler refuses to read an existing file when allow_file_access is off. Closes h4ckf0r0day#579
mnaza
force-pushed
the
fix/cdp-setfileinputfiles-allow-file-access-579
branch
from
August 15, 2026 16:35
4c0f2c3 to
c6d9645
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DOM.setFileInputFilesread client-supplied local file paths and handed the bytes to page JS with no access control — an arbitrary file-read primitive for anyone who can reach the CDP port (Docker images bind 0.0.0.0).Page.navigatetofile://already guards this behindcontext.allow_file_access(off by default); this applies the same gate, refusing before anystd::fs::readwhen the flag is off.TDD: a test proves the handler refuses to read an existing file when
allow_file_accessis off (RED returned the file bytes; GREEN errors). All 116 obscura-cdp tests pass.Closes #579