Re: [integrity]: Origin confusion attacks.

On Thu, Jan 9, 2014 at 3:14 AM, Mike West <mkwst@google.com> wrote:

> Ben pointed out that caching might cause problems for CSP, given that the
> origin of a resource is important when determining whether it ought be
> allowed access. More generally, this sort of attack is pointed out in
> section 6.2 of the spec. I've expanded that text in [1] to make the attack
> he outlines more clear.
>
> I don't have a good mitigation idea off the top of my head, but I agree
> it's something we should worry about.
>

I think the document/server needs a way to either opt-out of (if enabled by
default) or opt-in to unknown-origin sub resource integrity caching.

I can think of a few ways of implementing this:

1) bank.com could specify a HTTP response header to whitelist integrity
cache origins:

CH-Integrity-Allow-Origin: 'self' (allow only same-origin, perhaps the
default)
CH-Integrity-Allow-Origin: * (allow cached sub resources from any domain,
risky, best performance)
CH-Integrity-Allow-Origin: ajax.googleapis.com cdnjs.cloudflare.com
code.jquery.com (good performance, low risk)

2) Another option would be a simple boolean header:

CH-Integrity-Unknown-Origin: 0/1

Which when 0 would tell the client to only serve the resource from the URI
specified in the document with matching hash or if an integrity hash
matches from the same origin, or an origin that has been whitelisted by CSP
for the given resource type.

3) If a Content-Security-Policy is specified only allow cached resources
from origins that have been whitelisted

The bank.com server returns:

Content-Security-Policy: script-src 'self' ajax.googleapis.com
cdnjs.cloudflare.com code.jquery.com;

And has:

<script src="https://code.jquery.com/jquery-1.10.2.min.js"
integrity="ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=text/javascript">

But the client has cached:
https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js it could
use it.

I like this approach but I think it will end up decreasing security because
people will whitelist domains they don't use for performance. In other
words it weakens CSP.

4) Let the developer specify in the markup:

<script src="https://code.jquery.com/jquery-1.10.2.min.js"
integrity="ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=text/javascript
*&o=**">

<script src="https://code.jquery.com/jquery-1.10.2.min.js"
integrity="ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=text/javascript*&o=ajax.googleapis.com
<http://ajax.googleapis.com>+cdnjs.cloudflare.com
<http://cdnjs.cloudflare.com>+code.jquery.com <http://code.jquery.com>*">

Each approach has pros and cons, but however it works I think it is
essential that the server can control what origins the documents it serves
will trust.

Great work getting the initial spec out Mike, et. al.!

--
Pete Freitag
http://content-security-policy.com/ - CSP Reference