Consider integrity enforcement of iframe

shekyan commented 8 years ago

I can see enforcing integrity of iframe source can be useful when dealing with non-trusted origins.

annevk commented 8 years ago

How would this work with navigation of the contents? Or even the initial creation of <iframe> which will always load about:blank.

shekyan commented 8 years ago

It shouldn't. The way I see it is that integrity is checked for primary resource loaded with response code 2xx. (browsers can be helpful there and show supported digests of the content in "view source" tab). Once navigated away - let it load whatever. Integrity can also be checked if initial load is from data:, file:, filesystem:.

adon-at-work commented 7 years ago

👍 for supporting iframe integrity enforcement

as long as multiple integrity values are supported as documented in the spec, hash values of empty page (be it about:blank) and any allowed page navigations can be put all there as a whitelist.

dlongley commented 7 years ago

This would be tremendously useful for "mediator" polyfills that need to run on third party websites. For example, for the Payment Request and Payment Handler APIs.

annevk commented 7 years ago

This also fails badly for cross-origin <iframe> as integrity requires CORS, whereas navigation (which is what <iframe> uses) never uses CORS. I don't think this feature is really doable.

mikewest commented 7 years ago

@annevk: Never uses CORS, you say? I actually do want to change that for unrelated reasons in https://wicg.github.io/cors-rfc1918/, at least for preflights. If it's something you have fundamental objections to, we should talk. :)

annevk commented 7 years ago

I think the main problem is that CORS is about sharing content, but that's not really applicable in the <iframe> scenario. We would never want to grant cross-origin access to node trees. Using just CORS preflights seems somewhat reasonable, but a bit hackish as well. A dedicated signal might be more appropriate (especially if such servers could expect actual CORS traffic as well).

annevk commented 7 years ago

On closer inspection it seems you're already using new headers so it's likely fine. So then it's not really CORS.

mikewest commented 7 years ago

I think the main problem is that CORS is about sharing content, but that's not really applicable in the scenario. We would never want to grant cross-origin access to node trees. Using just CORS preflights seems somewhat reasonable, but a bit hackish as well. A dedicated signal might be more appropriate (especially if such servers could expect actual CORS traffic as well).</p> </blockquote> <p>I'd appreciate feedback on the high-level design in that spec, as I'm hopeful we'll actually be able to start implementing it in late Q4.</p> <p>For this bug, though, I would like to find a way to ask for integrity guarantees on frames. In particular, I'd like Doubleclick to be able to ensure that advertisers load a specific, audited HTML page when framed. That seems valuable. We ask for CORS on subresources because we'd otherwise expose content cross-origin: I'm not sure the same is true for frames, as I don't think we expose an error event on <code><iframe></code>. We're left with leakage issues like <code>window.length</code>, I suppose... but that seems like something we need to break regardless.</p> <blockquote> <p>On closer inspection it seems you're already using new headers so it's likely fine. So then it's not really CORS.</p> </blockquote> <p>It's like CORS++.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/annevk"><img src="https://avatars.githubusercontent.com/u/1544111?v=4" />annevk</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>(You frame CORS as if it's a prevention mechanism. It's not, it enables things that are otherwise forbidden.)</p> <p>A worry with CORS for <code><iframe></code> is that there is a mismatch in expectations. Once you enable CORS for such content, but the node tree still cannot be accessed, folks might incorrectly assume they're safe somehow. Another worry is that an <code><iframe></code> holds a browsing context which can be navigated from all over the place. That makes it hard to defend with CORS and integrity unless we also prevent further navigation somehow. And a final worry is that navigation is already extremely complex and very poorly defined. Each time we add more complexity to it we get further from truly understanding it and ensuring it's not actually broken.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mikewest"><img src="https://avatars.githubusercontent.com/u/1497?v=4" />mikewest</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>(You frame CORS as if it's a prevention mechanism. It's not, it enables things that are otherwise forbidden.)</p> </blockquote> <p>SRI's reliance on CORS is as a prevention against unintentional leakage. If you'd prefer to frame that as enabling integrity checks on cross-origin resources that would otherwise be opaque bags of bits, I'm fine with that. :)</p> <blockquote> <p>A worry with CORS for <iframe> is that there is a mismatch in expectations.</p> </blockquote> <p>I get that, and I understand your concerns. What I'm saying is that I would like to figure out how to apply SRI to iframed content. Perhaps doing that via CORS makes sense despite the risks you suggest. Perhaps we'll need to find some way to do it that doesn't require CORS (some other explicit opt-in). Either way, it's functionality that I'd like to be able to somehow support.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/annevk"><img src="https://avatars.githubusercontent.com/u/1544111?v=4" />annevk</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>That is how I'd like to frame it, because folks often end up blaming CORS when they're actually upset with the same-origin policy.</p> <p>If you're going to do SRI for <code><iframe></code> I think CORS is still the best way, but I also think that we need to carefully consider further restrictions, given the nature of <code><iframe></code>. (And also somehow convey that this actually means sharing your content. It seems that often folks think that giving away a hash isn't a big deal.)</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/EGreg"><img src="https://avatars.githubusercontent.com/u/352191?v=4" />EGreg</a> commented <strong> 6 years ago</strong> </div> <div class="markdown-body"> <p>With subresource integrity for iframes, we can for the first time have a mainstream feature to let users have peace of mind the html document being loaded in the iframe has not been tampered with.</p> <p>For now, a workaround is subresource integrity for Javascript which then goes to populate iframes. However, in that case the iframes must be on the same domain, which is a problem. There is currently no way to audit documents being loaded from a third party domain.</p> <p>Ideally, browsers should introduce a schemes, httpc:// and httpsc:// which would show an error or warning if the content changed. The browser instances on people's computers could get a hash of this resource and flag it if it ever changes on someone else's machine. Then others could reference this url and make various claims about it, including making audits etc.</p> <p>In fact ipfs://content-addressable-hash-here is somewhat similar.</p> <p>Browsers can also cache commonly used resources by their SRI hash.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/BigBlueHat"><img src="https://avatars.githubusercontent.com/u/43209?v=4" />BigBlueHat</a> commented <strong> 6 years ago</strong> </div> <div class="markdown-body"> <p>FWIW an earlier draft of this specification provided the <code>integrity</code> attribute on <code><iframe></code> (as well as anchors and many others): <a href="https://www.w3.org/TR/2014/WD-SRI-20140318/">https://www.w3.org/TR/2014/WD-SRI-20140318/</a></p> <p>Having integrity expression in a standard format (<a href="https://tools.ietf.org/html/rfc6920">RFC6920</a>) across all hypermedia affording elements would provide a layer of verification for responses which is current inexpressible.</p> <p>Having this expressiveness (and ideally browser-implemented verification as for scripts/styles) would provide great value to our work on Web Publications: <a href="https://github.com/w3c/wpub/issues/125">https://github.com/w3c/wpub/issues/125</a></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/murbard"><img src="https://avatars.githubusercontent.com/u/1591742?v=4" />murbard</a> commented <strong> 5 years ago</strong> </div> <div class="markdown-body"> <p>This would be particularly helpful for safely mediating access to localStorage. Is there any known trick to achieves this with SRI?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/amark"><img src="https://avatars.githubusercontent.com/u/433412?v=4" />amark</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>I need this as well. Applications using my tech may want to embed an iframe that displays some instructions/information, and those teams want to make sure I can't swap out the iframe with something else (like an ad). The integrity attribute would give the confidence they correct instructions will always be displayed.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/nathanfranke"><img src="https://avatars.githubusercontent.com/u/14253836?v=4" />nathanfranke</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>I apologize if this is a bump, but I want to share my findings here in the hope that it will be useful to someone (or myself in the future)</p> <p>I want to make a website that can guarantee some content, and be "tamper-proof" even with access to a server. The simplest form of this would be sending someone a data url with all the html already embedded:</p> <pre><code>data:text/html,<h1>This is a basic data html website, if you bookmark this it will exist forever basically.</h1></code></pre> <p>This won't work too well for big websites though, so the second idea I had was:</p> <pre><code>data:text/html,<script src="https://example.com/script_that_loads_everything.js" integrity="sha256-0123456789abcdef"></script></code></pre> <p>As long as the user has the correct URL, they can be confident that the content of the webpage was not tampered with, otherwise the page will fail to load (will probably be a blank screen) (note: I am assuming the javascript doesn't have any XSS vulnerabilities, but I am assuming that will be a priority for anyone making this type of website).</p> <p>Finally, I discovered this GitHub issue, and it made me think of an even simpler URL:</p> <pre><code>data:text/html,<iframe src="https://example.com" integrity="sha256-0123456789abcdef"></iframe></code></pre> <p>Again, this could guarantee a website's content integrity, with the added bonus of being mostly human readable.</p> <hr /> <p>When it comes to CORS, I do think there could be a vulnerability of some sorts.</p> <pre><code class="language-html"><iframe src="https://api.example.com/myaccount/getsecretcode" integrity="sha256-0123456789abcdef"  >   <input placeholder="CAPTCHA: Please enter the code above"></code></pre> <p>So maybe this checksum feature should only be possible if <code>api.example.com</code> explicitly allows CORS.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jayaddison"><img src="https://avatars.githubusercontent.com/u/55152140?v=4" />jayaddison</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>This is a feature that I'd use to provide stronger content integrity guarantees to site visitors, if and when available.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jayaddison"><img src="https://avatars.githubusercontent.com/u/55152140?v=4" />jayaddison</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Although I suppose waiting for a specification and browser implementation(s) <em>before</em> adding a feature is the usual approach, in this case I think RecipeRadar may add <code>iframe</code> content-integrity and then hope that this feature is implemented in future (and will adapt if necessary depending on the resulting spec/implementation details).</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/dveditz"><img src="https://avatars.githubusercontent.com/u/1290788?v=4" />dveditz</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>I'm against this feature as described because web developers will assume this protects them when it does no such thing. In addition to the lack of control over navigation described before, the integrity check could at best ensure the HTML of the loaded page. Any sub-resource the page loads could change at a whim and the integrity check would still pass.</p> <p>In a very narrow case you might be able to rely on framed content (initially, at least) IF</p> <ul> <li>you inspect the framed page and make sure all of its resource loads have SRI checks</li> <li>the above includes checking all the scripts (transitively, all the way down) to make sure any and all fetch requests specify integrity</li> <li>none of its scripts use <code>import</code> (which we haven't figured out how to specify SRI for)</li> <li>that a dynamically generated page doesn't radically change when any of its loaded resources are self-sabotaged and don't load</li> </ul> <p>If you don't do all those things—and realistically, who will?—then the integrity attribute on a frame offers as much security as a "Please don't rob us" sticker on a bank door. But most developers won't know that. They will think the picture of the smiling security guard on the sticker is a real security guard.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jayaddison"><img src="https://avatars.githubusercontent.com/u/55152140?v=4" />jayaddison</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>I don't know - it seems to me like a case where integrity hashes can usefully be added to provide the "verify" aspect of "trust but verify" in various HTTP retrieval contexts (whether that's scripts, hyperlinks, iframes, or various other situations).</p> <p>True, dynamic content may cause unexpected changes after it is loaded -- but you would know whether you retrieved the expected content (and adjust your sense of trust accordingly).</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/tdelmas"><img src="https://avatars.githubusercontent.com/u/1955774?v=4" />tdelmas</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Any sub-resource the page loads could change at a whim and the integrity check would still pass.</p> </blockquote> <p>The same argument could be made for the integrity of js scripts that trigger the loading of other resources (js, css, links & page navigation...). Nevertheless, that integrity check is considered important.</p> <p>So for iframe, I think it may still add a useful layer of security.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jayaddison"><img src="https://avatars.githubusercontent.com/u/55152140?v=4" />jayaddison</a> commented <strong> 11 months ago</strong> </div> <div class="markdown-body"> <blockquote> <p>none of its scripts use import (which we haven't figured out how to specify SRI for)</p> </blockquote> <p>Would this be addressed by the <a href="https://github.com/wicg/import-maps/">WICG <code>import-maps</code> spec</a>? My understanding is that those do support the <code>integrity</code> attribute for cases where content is <code>fetch</code>'d by <code>src</code> (<a href="https://github.com/WICG/import-maps/issues/223#issuecomment-704443308">ref</a>).</p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>

w3c / webappsec-subresource-integrity

Consider integrity enforcement of iframe #21