GHSA-2p8c-gr87-2676: CSRF
Impact
Pages opened into a new window from a link were loaded as if the app itself had navigated there rather than the page that contained the link, so the request was treated as same-site: SameSite=Strict cookies were sent and Sec-Fetch-Site did not identify the initiating page. Content shown in the app could use this to make a credentialed top-level request to another site that relies on SameSite cookies as a CSRF defence.
Apps are only affected if they load untrusted content and allow it to open new windows. Apps that deny new windows from untrusted content with setWindowOpenHandler are not affected.
Workarounds
Return { action: 'deny' } from setWindowOpenHandler for windows opened by untrusted content.
Fixed Versions
45.0.0-alpha.6 44.3.0 43.7.0 42.11.3
For more information
If you have any questions or comments about this advisory, email us at security@electronjs.org
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/electronto a version that resolves this vulnerability.Fixed in 42.11.3 - Upgrade
Upgrade
npm/electronto a version that resolves this vulnerability.Fixed in 43.7.0 - Upgrade
Upgrade
npm/electronto a version that resolves this vulnerability.Fixed in 44.3.0 - Upgrade
Upgrade
npm/electronto a version that resolves this vulnerability.Fixed in 45.0.0-alpha.6 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 42.11.3 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 43.7.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 44.3.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 45.0.0-alpha.6 - Configuration
Return { action: 'deny' } for windows opened by untrusted content.
setWindowOpenHandler return action = deny
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications are affected only if they load untrusted content and allow that content to open new windows. Applications that deny new windows from untrusted content with setWindowOpenHandler are not affected.
What does exploitation require?
An attacker needs untrusted content displayed by the application to open a page in a new window. That new window can then make a credentialed top-level request to another site that relies on SameSite cookies as a CSRF defense.
What can be done if upgrading is not immediately possible?
Configure setWindowOpenHandler to return { action: 'deny' } for windows opened by untrusted content. This prevents the new-window behavior required for exposure.
Which releases contain the fix?
The issue is fixed in 45.0.0-alpha.6, 44.3.0, 43.7.0, and 42.11.3.