fix(security): authenticate session-recorder relay postMessage (RQ-3095, RQ-3096) - #18
Open
dinex-dev wants to merge 1 commit into
Open
fix(security): authenticate session-recorder relay postMessage (RQ-3095, RQ-3096)#18dinex-dev wants to merge 1 commit into
dinex-dev wants to merge 1 commit into
Conversation
…95, RQ-3096) Send side: post relayed events to trustedOrigin (falls back to '*') and attach a relayToken, instead of an unconditional wildcard target (RQ-3096). Receive side: validate relayToken and guard eventType before buffering, instead of trusting the attacker-controlled message.data.source (RQ-3095). Both options are opt-in and backward compatible. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
What & why
Hardens the
SessionRecordercross-frame relay against two postMessage weaknesses (RQ-3095, RQ-3096):window.topwith a wildcard'*'target origin, so any embedding or co-resident frame could receive them. Now posts to an explicittrustedOriginwhen provided (falls back to'*'only when it is unset), and attaches a per-recordingrelayToken.messagelistener only checked the attacker-controllablemessage.data.source. It now validates the sharedrelayTokenand guardseventTypeagainstRQSessionEventTypebefore buffering. Origin is intentionally not checked on the receive side — relayed events legitimately arrive from cross-origin child frames, so the origin restriction is enforced on the send side instead.Both new options (
trustedOrigin,relayToken) are opt-in and backward compatible — behavior is unchanged when they are not passed.Testing
Two-origin browser harness (top ⇄ cross-origin iframe):
trustedOrigin→ iframe network + console events still relay into the session (no regression).trustedOrigin→ nothing is delivered (leak closed).relayToken→ injected events are rejected.Notes
Consumers must pass the new options to benefit; see the paired change in
requestly/interceptor.🤖 Generated with Claude Code