Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: clean up webFrame implementation to use gin wrappers #28497

Merged
merged 5 commits into from Apr 12, 2021

Conversation

MarshallOfSound
Copy link
Member

The previous implementation of webFrame in the renderer process leaked sub-frame contexts and global objects across the context boundaries thus making it possible for apps to either maliciously or accidentally violate the contextIsolation boundary.

E.g. electron.webFrame.top.context leaked the window object from the other side of the isolated world by accident (not by API, purely by implementation issues)

This re-implementation binds all methods in native code directly to content::RenderFrame instances instead of relying on JS to provide a "window" with every method request. This is much more consistent with the rest of the Electron codebase and is substantially safer.

Notes: no-notes

@electron-cation electron-cation bot added the new-pr 🌱 PR opened in the last 24 hours label Apr 2, 2021
Copy link

@mesca216 mesca216 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deleted

// TODO(MarshallOfSound): Remove once the world-safe-execute-javascript deprecation warning is removed
if (method.startsWith('executeJavaScript')) {
return (webFrame as any)[`_${method}`](...args);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to keep this in for backportability?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing this (the deprecation warning) makes the implementation easier. Need to figure out how best to handle this in older branches you're right

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am removing this in #28456

@electron-cation electron-cation bot removed the new-pr 🌱 PR opened in the last 24 hours label Apr 3, 2021
shell/renderer/api/electron_api_web_frame.cc Show resolved Hide resolved
shell/renderer/api/electron_api_web_frame.cc Show resolved Hide resolved
shell/renderer/api/electron_api_web_frame.cc Show resolved Hide resolved
shell/renderer/api/electron_api_web_frame.cc Outdated Show resolved Hide resolved
shell/renderer/api/electron_api_web_frame.cc Outdated Show resolved Hide resolved
shell/renderer/api/electron_api_web_frame.cc Show resolved Hide resolved
shell/renderer/api/electron_api_web_frame.cc Outdated Show resolved Hide resolved
@miniak
Copy link
Contributor

miniak commented Apr 8, 2021

@MarshallOfSound there are conflicts after my PR #28456 was merged

The previous implementation of webFrame in the renderer process leaked
sub-frame contexts and global objects across the context boundaries thus
making it possible for apps to either maliciously or accidentally
violate the contextIsolation boundary.

This re-implementation binds all methods in native code directly to
content::RenderFrame instances instead of relying on JS to provide a
"window" with every method request.  This is much more consistent with
the rest of the Electron codebase and is substantially safer.
@MarshallOfSound MarshallOfSound merged commit 6df2680 into master Apr 12, 2021
@release-clerk
Copy link

release-clerk bot commented Apr 12, 2021

No Release Notes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants