Re: SRI fail open behaviour

On Mon, Jul 27, 2015 at 5:36 PM, Joel Weinberger <jww@chromium.org> wrote:

>    1) Should crossorigin=anonymous be implicit in all requests (unless
> same-origin or explicitly set by the developer?
>    2) Should it fail closed on bad hash algorithms as well?
>
> To (1), there doesn't appear to be consensus (although notably I believe
> all of the editors agree it should *not* be implicit). I'm not sure how to
> resolve this at this point, so any suggestions would be welcome. My thought
> is that since this would be an additional "feature," we should default to
> not include it if we can't come to consensus, but I'm biased since I don't
> want it anyway :-)
>

I agree with the editors that it shouldn't be implicit. Follow the
principle of least surprise: Why would adding an integrity attribute
automatically change anything about CORS? The default value of the
|crossorigin| security attribute was chosen to be the most secure value.
Adding another security attribute shouldn't automatically reduce the
security of another security attribute.


> To (2), again, Brian doesn't appear to agree with this, but I believe that
> we actually already came to consensus on failing open for an unknown
> algorithm quite some time ago, and I feel strongly that this decision
> should remain: http://www.w3.org/2015/02/23-webappsec-minutes.html#item07
>

I think you and I agree more than we disagree. Web developers have to take
into account that some browsers might not support the SRI digest that they
use. That includes the case where the browser doesn't support SRI at all.
For some reason people argue that developers should only have to properly
deal with the case where the browser doesn't support SRI at all.


> I think Francois's point is correct as well. It is possible to download
> every browser possible to test your page on, but in practice it won't
> happen, and one of the worst things the integrity attribute can do would be
> break otherwise functional pages.
>

[Sorry for the lack of brevity. Note that at the end, I make a proposal
that attempts to find a compromise.]

The whole point of SRI is to break pages when expectations are not met. The
same with TLS and other security features. It isn't reasonable for anybody
to expect their pages to work in older browsers without testing them in
older browsers, *especially* when they are using the security features like
SRI and CSP that this working group creates or even TLS. So the whole
concern of protecting against breaking pages in older browsers is invalid,
IMO.

There are three use cases for SRI that I see:

1. I want to do <script src=
https://social-network.example.com/track-my-users.js> without allowing the
social network's JS to do harmful things in the event that the social
network is hacked. This is actually what <iframe sandbox> is for, but the
companies running the trackers don't want to be put into <iframe sandbox>
yet, so people are trying to use SRI instead.

2. Consider a big company (like Google) that has multiple levels of CDNs.
The lowest-latency "edge" CDNs are machines within data centers of third
parties like ISPs. The next level of CDN is operated from within their own
data centers, but it generally has higher latency because the internal data
centers are further away than the ISPs' points of presence. The main
document gets loaded from the internal CDN. If the browser supports SRI,
then the main document will have <script src> elements pointing at the edge
CDNs, otherwise it will have <script src> pointing at the internal CDN.

3. The website wants to use a third-party CDN like https://code.jquery.com/.
It wants to protect users of modern browsers from being hacked through that
CDN, but it doesn't want to bother to do anything to protect users that
uses browsers that don't implement SRI with secure algorithms.

Now, the problematic scenario we are concerned about requires SHA-2 to be
broken, right? Otherwise, nobody would bother switching to SHA-3 without
also providing SHA-2 digests too. Now, what kind of cryptographic break is
likely to affect SHA-2 in a way that affects any of these scenarios?
Basically, collision attacks are the only ones that are even close to being
feasible, as far as we know (even for MD5).

For scenerio #3, a collision attack require the authors of the JS code
being loaded to carefully construct two versions of their JS code that have
a SHA-2 collision, publish the good version on their CDN, wait for people
to update their links to use it, and then replace it with the bad version,
without anybody noticing in any other way. It doesn't seem like a very
realistic scenerio.

For scenerio #1 and #2, the attacker would have to be part of the internal
organization. In that case, you have much bigger problems.

Keep in mind that we're nowhere close to breaking SHA-2 in any way, so it
is very unlikely that SHA-3 will be needed by anybody for SRI within the
next several years. See, for example,
http://security.stackexchange.com/a/21116.  If browsers that support SRI
simply implement SHA-3 soon, the whole problematic scenario becomes even
more improbable.

So, with all that in mind, it doesn't make sense to me that a simple typo
like "sha256:..." instead of "sha256-..." should be enough to destroy the
security of a page in any of the three scenarios above, to avoid a
problematic case for scenario #3 that is unrealistic. Typos happen every
day. The variety of syntaxes for SRI that this group has already cycled
through ("sha-256:", "ni://...", "sha256-", etc.) is pretty good evidence
of the likelihood of people making such mistakes.

Consequently, I still think the best thing to do is to just make SRI fail
closed if there is any problem (parsing or otherwise) with enforcing SRI.

However, if people are unwilling to do that, how about this compromise: If
the browser encounters an integrity attribute that only contains digests
prefixed with "sha[3-9]-[0-9][0-9][0-9]-", then it should fail open;
otherwise it should fail closed. This will allow, for example, "sha3-256-"
and "sha3-512".

To be clear, I think that's silly, but better than the current fail open
logic.

Cheers,
Brian
-- 
https://briansmith.org/