CSP block-all-mixed-content blocks mailto and tel links in subframes
Reported by
s.mats...@gmail.com,
Mar 16 2018
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 OPR/51.0.2830.55 Steps to reproduce the problem: 1. Have a page loaded in an iframe where the page in the iframe specifies a CSP with upgrade-insecure-requests, block-all-mixed-content and a frame-src 2. Try to click a mailto:// or tel:// link in the iframe 3. What is the expected behavior? The default mail or tel app to open or a list of apps to be displayed by Windows. This is what happens in e.g. Firefox. What went wrong? The mailto/tel link is not honored and the message "Requests to the server have been blocked by an extension." is shown (no extensions are activated in the browser). In the console there is an error message stating: "Refused to frame '' because it violates the following Content Security Policy directive: "frame-src 'self'" Did this work before? N/A Chrome version: 64.0.3282.186 Channel: n/a OS Version: 10.0 Flash Version:
,
Mar 16 2018
,
Mar 18 2018
For mailto links, the error in the console is: "Mixed Content: The page at 'https://…' was loaded over HTTPS, but requested an insecure resource 'mailto:<email redacted>'. This request has been blocked; the content must be served over HTTPS."
,
Mar 19 2018
Hello, Could you provide a simple PoC for this, it's not really clear to me how the frame becomes blocked after loading when clicking on the mailto: or tel: link inside it (or maybe I'm misunderstanding). mailto: and tel: links can't be upgraded since they open the mail/tel handler which could then choose to send the data however they please. This means that with block-all-mixed-content they will get blocked. The part about the error message is indeed misleading, I suspect it's just a default error message from the time were extensions where the only possible mechanism that could block a request.
,
Mar 19 2018
Hi! I have created a small POC site at: https://smatsson.azurewebsites.net/csp/frame-src-tel.html In Chrome and Opera both the mailto and tel links are blocked. Edge allows the mailto link but blocks the tel link and Firefox allows the mailto link and does nothing to the tel link (probably since I don't have an app installed to handle the link). I get what you are saying regarding that mailto and tel cannot be upgraded and that block-all-mixed-content should prevent this. It seems a bit off though as IMO block-all-mixed-content should only prevent http connections from being executed (see e.g. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content). It's fully possible that MDN is wrong in this regard though.
,
Mar 22 2018
Here is another POC on the same issue (somewhat). The parent page contains a CSP with block-all-mixed-content but the links on the parent page are *not* blocked. The links in the iframe are. https://smatsson.azurewebsites.net/mailto-and-tel-link-block-all-mixed-content/
,
Mar 27 2018
The behavior in comment #8 is weird. We shouldn't distinguish between top-level and nested contexts, whatever behavior we land on. I think this is worth fixing at some point.
,
Jan 11
Re #8 and #9, I think this is an outcome of a more general issue whereby mixed content fires for navigations to out-of-browser handlers (e.g. "alert:", "mailto:" etc) only in subframes. Mixed Content is not triggered when the target is _top; see https://bayden.com/test/mixedcontent/. |
|||
►
Sign in to add a comment |
|||
Comment 1 by elawrence@chromium.org
, Mar 16 2018Components: Blink>SecurityFeature>ContentSecurityPolicy
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac Type-Bug