-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Security model of message passing #814
Comments
I've been doing some research and had a conversation with Lucas. We think there might be some options for hardening the upstream headers with forMainFrameOnly, but ultimately we need to manufacture an attack repo to validate the current vulnerability and mitigations.
|
Also, there is a similarly themed discussion happening here: webview/webview#413 |
I was looking into webview2, and came across this interesting note: |
This is definitely possible and idiomatic in Rust. There is a FnOnce trait to serve this need. In fact, we actually have to |
This would mean we disable event listener registration from the webview side. It makes things a little more complex for the devs, but it will enhance the security a thousandfold. |
This article goes into more details. |
Is your feature request related to a problem? Please describe.
At this hackernews comment, a very good point was raised about the null origin.
Describe the solution you'd like
The OP wrote:
Describe alternatives you've considered
Instead of allowing the webview to initiate an event, requiring the rust side to do so because we create a randomized handle for each event and can permit it to only be used once. In practice, today, we use the webview to create the event listener, however at build time we can anticipate exactly what listeners are needed - so at runtime we can prepare the proper handle
Additional context
http://archive.is/UXD8j
The text was updated successfully, but these errors were encountered: