Why are prefetch links optionally blockable instead of blockable? #70
Comments
|
I assume they are optionally blockable like images because the risk is info leaking over an insecure channel (cookies, urls, etc) and not compromising the integrity of the context like scripts. Unless we don't get a second chance at upgrading a prefetched script to block it later? |
|
I suppose, but at least Gecko treats lots of stuff as "blockable" that is a smaller attack vector than scripts (e.g. so it's not just the severity of not blocking that's relevant but also the risk/benefit ratio of not blocking in general... |
|
The text was added in #29. If
memory serves, the _optionally_ part was simply documenting what was
already implemented in browsers. That said, I also think it's reasonable to
treat them as "blockable"; I'm open to suggestions for how to word this to
allow both.
…On Tue, Jan 24, 2017 at 9:49 AM, Boris Zbarsky ***@***.***> wrote:
I suppose, but at least Gecko treats lots of stuff as "blockable" that is
a smaller attack vector than scripts (e.g. <a ping>). The comment above
the list of "blockable" things there says:
// Active content (or content with a low value/risk-of-blocking ratio)
so it's not just the severity of not blocking that's relevant but also the
risk/benefit ratio of not blocking in general...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#70 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAApnIzI8THDivs6y3meo9ccl0IGieDdks5rVjm2gaJpZM4LsUr6>
.
|
|
Hmm. Which browsers? Certainly Gecko treats prefetch as non-optionally blockable.... |
|
As for language, you could just say that the loads should be considered either blockable or optionally blockable. That seems pretty straightforward. I guess one can even write tests for that by including the |
|
@bzbarsky: Do you see security issues with allowing prefetch requests to be optionally blockable? |
|
I'm not the right person to ask. You should probably talk to the Gecko security folks, who currently have them blockable. But really, it's a question of what your threat model is. |
|
It seems like the behavior should fall out of the way y'all call into Fetch (see step 4ish of https://w3c.github.io/webappsec-mixed-content/#should-block-fetch). https://w3c.github.io/resource-hints/#fetching-the-resource-hint-link doesn't really make that relationship clear, however. Do you set the initiator/type/destination in some other document? Regardless, I'm happy to change Blink's behavior to match Firefox's. If it's getting away with tighter restrictions than Blink is, then Blink should match. |
Pretty sure this text far postdates anything Gecko has implemented in this area, so it's not really relevant to what we do in practice. But even if we follow this algorithm... requests "destination" is not "document" for prefetches, right? So we go on past step 1. Step 2 is not relevant in the no-CSP case. Step 3, let's say none of the conditions match. Step 4 it looks to me like none of the conditions would match, at first glance.... So step 5 would return blocked. |
It's relevant insofar as I hope it ends up describing what we'd like to be doing in practice.
It's pretty unclear to me how prefetches are fetched. I agree that they're unlikely to be fetched as "document", though. :)
Step 4 is the question, I think. Are prefetched resources using In general, though, I'm perfectly happy just blocking all non-secure prefetch requests. If y'all can explain to me how they're represented to Fetch, I'm happy to rewrite that section of MIX accordingly. |
We're talking about the non-"as" case here (not least because this is the first I've heard of "as"!). I agree that for the "as" case applying the policy we'd normally use for the type it's being prefetched "as" makes sense. I have at this point more or less lost track of the rats' nest of information Fetch takes as input, so I'm afraid I can't tell you anything useful about how prefetches should be represented there... :( |
|
Oh, and the one thing that I would like to see here is some clarification around what "optionally-blockable" means. Because it does NOT mean "not blocked by default", really. And the fact that its definition doesn't match the conditions in https://w3c.github.io/webappsec-mixed-content/#should-block-fetch step 4 just confuses everything.... It would probably be better in terms of spec clarity to drop the concept of "optionally-blockable" altogether, replace step 3 substep 1 with "The user agent is configured to block all mixed content" or something (and similar for https://w3c.github.io/webappsec-mixed-content/#should-block-response step 2 substep 1), and have things that want to not be blocked by default be explicitly added to step 4 of https://w3c.github.io/webappsec-mixed-content/#should-block-fetch and step 3 of https://w3c.github.io/webappsec-mixed-content/#should-block-response (or better yet some algorithm both of those call into, if their behavior is meant to be identical). |
|
We discussed this in the WebAppSec group at TPAC, and agreed there that we'd prefer to align on Firefox's behavior with regard to prefetch. (The minutes aren't great, but they capture the conclusion, at least!) I believe that falls out of the mixed content spec's current language in https://w3c.github.io/webappsec-mixed-content/#should-block-fetch (though I'll reiterate that it would be helpful if the resource hints spec actually described the fetching in terms of Fetch so that the integration was clearer). :) Thanks! |
|
This is in the HTML spec now and fully specified. |
And specifically, why are UAs prevented from treating them as blockable? What is the benefit of making them optionally blockable that outweighs the problems with it?
The text was updated successfully, but these errors were encountered: