fix(js): cap op_fetch_url response body to prevent OOM DoS - #588
Open
mnaza wants to merge 1 commit into
Open
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>
op_fetch_url read the entire JS fetch/XHR response body with response.bytes().await and no size bound, then made a UTF-8 copy and a base64 copy of it. A malicious or misbehaving server returning a multi-GB body — optionally without a Content-Length — OOMed the process. The existing response_body_byte_limit only gates whether a body is cached for Network.getResponseBody, not the initial allocation. Read the body via streaming (response.chunk()) through a new read_body_capped helper that refuses bodies over a cap both when the advertised Content-Length is too large and when the streamed bytes exceed it, so an oversized response is never fully allocated. The cap is configurable via OBSCURA_FETCH_MAX_BODY_BYTES (default 100 MiB, well above any realistic page fetch). Adds tests driving a local server that streams an oversized body with no Content-Length (rejected) and a small body (read in full). Closes h4ckf0r0day#581
mnaza
force-pushed
the
fix/js-fetch-cap-body-size-581
branch
from
August 15, 2026 16:35
429292d to
e60c79c
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.
op_fetch_url(JSfetch()/XHR) read the entire response body withresponse.bytes().awaitand no bound, then made UTF-8 and base64 copies — a multi-GB response (optionally without Content-Length) OOMed the process. The existingresponse_body_byte_limitonly gates caching, not the initial allocation. This streams the body viaresponse.chunk()through a newread_body_cappedhelper that refuses oversized bodies both by advertised Content-Length and by streamed bytes. Cap is configurable viaOBSCURA_FETCH_MAX_BODY_BYTES(default 100 MiB).TDD: a local server streams an oversized body with no Content-Length (rejected) and a small body (read in full). RED buffered all 4 MiB; GREEN rejects mid-stream.
Closes #581