fix(security): widget consents and shared files cleared on logout; forged shares refused (#266, #267)
CI / Build & Quality Checks (pull_request) Successful in 1m53s
CI / Trigger Desktop Build (pull_request) Skipped
CI / Docker image build & smoke test (pull_request) Skipped
CI / Secret scan (gitleaks) (pull_request) Successful in 7s
CI / Playwright smoke (e2e) (pull_request) Successful in 12m51s
CI / Build & Quality Checks (pull_request) Successful in 1m53s
CI / Trigger Desktop Build (pull_request) Skipped
CI / Docker image build & smoke test (pull_request) Skipped
CI / Secret scan (gitleaks) (pull_request) Successful in 7s
CI / Playwright smoke (e2e) (pull_request) Successful in 12m51s
#266: remembered widget approvals (lotus.widgetConsent.*) survived logout, so they applied silently to the next account on the device and listed the previous account's rooms; clearPlaintextCaches now sweeps them. Space structure, call membership and Lotus room-policy state join PROTECTED_STATE_TYPES, so no widget can be granted them. #267: any website could auto-submit a form to /share-target and land the user in the share picker with attacker-chosen text and files. The worker now refuses a share whose Origin is another site. (Sec-Fetch-Site, as the issue suggested, never reaches a service worker: checked in Chromium.) Origin null/absent, as the OS share sheet sends, stays accepted, and /share now says the content came from another app or website. Both logout paths await clearSharedPayload(); the server-forced one also clears the soundboard clip cache, as #57 intended. Fixes #266 Fixes #267 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
This commit is contained in:
co-authored by
Claude Opus 5.5
parent
a5471a0576
commit
14f05a3d5c
@@ -20,6 +20,27 @@ export type SharePayload = {
|
||||
receivedAt: number;
|
||||
};
|
||||
|
||||
/**
|
||||
* [Gitea #267] Refuse a share that another website submitted: any site could
|
||||
* otherwise auto-submit a cross-site form here and drop attacker-chosen text
|
||||
* and files into the "Share to…" picker as if the user had shared them.
|
||||
*
|
||||
* The worker can't use `Sec-Fetch-Site`: fetch-metadata headers are added
|
||||
* after the service worker and never appear on `event.request` (checked in
|
||||
* Chromium). `Origin` does: a cross-site form carries the site's origin. The
|
||||
* OS share sheet's POST has no web initiator, so its Origin is `null` or
|
||||
* absent, and both stay accepted. A page can also produce `Origin: null`
|
||||
* (sandboxed frame, no-referrer), which is why /share also says the content
|
||||
* came from elsewhere.
|
||||
*/
|
||||
export const isTrustedShareRequest = (
|
||||
headers: Pick<Headers, 'get'>,
|
||||
selfOrigin: string,
|
||||
): boolean => {
|
||||
const origin = headers.get('Origin');
|
||||
return origin === null || origin === 'null' || origin === selfOrigin;
|
||||
};
|
||||
|
||||
/** Worker side: stash the POSTed form and answer with a redirect to /share. */
|
||||
export async function stashSharedForm(request: Request, base: string): Promise<Response> {
|
||||
const form = await request.formData();
|
||||
|
||||
Reference in New Issue
Block a user