fix: override csp for frame-src #50
Conversation
|
👍 |
# Conflicts: # package.json
hugomano
changed the title
src/browser/engine/protocol.ts
Outdated
| // Regex to capture the src attribute value for scrips, stylesheets... | ||
| const resourceLinkRegex = /src\s*=\s*['"](.+?)['"]/g; | ||
|
|
||
| const captureWhitelistableResourcesFromProtocolServedFile = (pathname: string) => |
There was a problem hiding this comment.
Woo this is quite complex, but I think I did understand it. Few questions:
Allowed HTML pages can include extension assets that don't need to be whitelisted.
Are you sure it is necessary to do that? I see no reference of such practice in the documentation?
How does Chromium handle that?
Since we didn't know the origin of the requests
Just in Electron, or even Chromium does not know?
There was a problem hiding this comment.
Are you sure it is necessary to do that? I see no reference of such practice in the documentation?
"A navigation from a web origin to an extension resource will be blocked unless the resource is listed as web accessible". So background page, popups and iFrames with chrome-extension:// protocol bypass check.
How does Chromium handle that?
Just in Electron, or even Chromium does not know?
We don't know the origin of the requests only in Electron: referrer is always blank (issue: electron/electron#14747). Chromium knows the request context.
--
I added all answers in comments belong to the code.
There was a problem hiding this comment.
But as discussed yesterday, we should drop the check for now.
There is 3 reasons: we whitelist installable extensions so we can trust them, we resolve protocol request in the extension folder only at the user filesystem level and this code block may not cover all cases.
There was a problem hiding this comment.
Detail: I don't think electron/electron#14747 is the right issue for this. referrer is an HTTP header that can be overridden in some situation and is the frame URL's domain in another situation. We are rather looking for a strong reference to the frame / webContents from which the request came.
What is this PR
chrome-extension://is not bypassed in CSP check at the iframe document level, so we add it to theframe-srcto the directive in the Content Security Policy headerMore here
Revamped the protocol handler and added verification for web accessible resourcesHow to test
CSP
before this PR: log in Gmail with a
@gmail.comaccount, onboarding iframe is not displayed.after this PR: log in Gmail with a
@gmail.comaccount, onboarding iframe is displayedProtocol Handler
In the Gmail dev tool with the Mixmax contex console:
fetch('chrome-extension://ocpljaamllnldhepankaeljmeeeghnid/manifest.json', { mode: 'no-cors' }).then(console.log)response isnet::FAILEDfetch('chrome-extension://ocpljaamllnldhepankaeljmeeeghnid/src/iframeProxy/proxy.html', { mode: 'no-cors' }).then(console.log)response isHTTP 200fetch('chrome-extension://ocpljaamllnldhepankaeljmeeeghnid/src/iframeProxy/proxy.js', { mode: 'no-cors' }).then(console.log)response isHTTP 200