Prevent CDN Exploitation

[MikeBishop]

The current model contains no proof for the CDN that the origin actually referred it. 7.2 defines using the encryption/integrity keys as proof to the client that the origin actually can decrypt the content. An attacker who wished to spoof the origin could not only retrieve and rehost the content, but even use the same CDN address and key to steal the CDN's hosting services for its attack.

It seems like there needs to be something to demonstrate to the CDN that the requestor has (recently?) spoken to the origin server.

[gaperik]

Yes. And since the interaction CDN - Origin is not described, such a signal would have to come via the client.

If implemented in SW, CORS c/would be part of solving this (I must admit to be a CSP and CORS fan).

If all in browser, some other signal perhaps.

Do You see other alternatives You prefer?

2016-04-01 22:47 GMT+02:00 MikeBishop notifications@github.com:

The current model contains no proof for the CDN that the origin actually referred it. 7.2 defines using the encryption/integrity keys as proof to the client that the origin actually can decrypt the content. An attacker who wished to spoof the origin could not only retrieve and rehost the content, but even use the same CDN address and key to steal the CDN's hosting services for its attack.

It seems like there needs to be something to demonstrate to the CDN that the requestor has (recently?) spoken to the origin server.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/EricssonResearch/Blind-Cache-Drafts/issues/3

[MikeBishop]

CORS works because the browser is more privileged than the content running in it, and so can mark up the requests / enforce the responses. The browser is getting information from the origins to enforce security policy locally. That may not be sufficient here, where the CDN wants to know which customer to bill for serving the content. (And conversely, the customer will want proof that the traffic it pays for was actually for its site.) Of course, I’m not certain this problem is necessarily any worse than what exists today. Topic for discussion.

You may need to embed some kind of short-lived token in the server’s response which the client presents to the CDN. The result of that would effectively be that the encrypted form of the resource is always cacheable (though doing so won’t always be beneficial), and the decrypted form might be depending on headers, but the out-of-band encoding form has a very short lifetime. Should probably add a section explicitly discussing how this scheme affects cacheability in general.

From: Göran AP [mailto:notifications@github.com] Sent: Friday, April 1, 2016 2:24 PM To: EricssonResearch/Blind-Cache-Drafts Blind-Cache-Drafts@noreply.github.com Cc: Mike Bishop Michael.Bishop@microsoft.com Subject: Re: [EricssonResearch/Blind-Cache-Drafts] Prevent CDN Exploitation (#3)

Yes. And since the interaction CDN - Origin is not described, such a signal would have to come via the client.

If implemented in SW, CORS c/would be part of solving this (I must admit to be a CSP and CORS fan).

If all in browser, some other signal perhaps.

Do You see other alternatives You prefer?

2016-04-01 22:47 GMT+02:00 MikeBishop notifications@github.com:

The current model contains no proof for the CDN that the origin actually referred it. 7.2 defines using the encryption/integrity keys as proof to the client that the origin actually can decrypt the content. An attacker who wished to spoof the origin could not only retrieve and rehost the content, but even use the same CDN address and key to steal the CDN's hosting services for its attack.

It seems like there needs to be something to demonstrate to the CDN that the requestor has (recently?) spoken to the origin server.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/EricssonResearch/Blind-Cache-Drafts/issues/3

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHubhttps://github.com/EricssonResearch/Blind-Cache-Drafts/issues/3#issuecomment-204569768

[gaperik]

The latest oob draft add an "Origin" header to the request to the secondary server. That seem to satisfy some of the needs here. Do you see more issues such separating different clients requests for the same oob resource?

[MikeBishop]

That's probably sufficient -- if the client is well-behaved, the Origin header will be accurate. If the client is poorly behaved, it could attack the CDN regardless. However, this may be an area to poke for other ways to exploit someone else's resources.

[martinthomson]

The main risk here is that a browser client uses ambient authority to access a resource and then unwittingly passes that content to an origin that wouldn't otherwise be able to access the content. That is, the user has a cookie that the attacking origin does not, but this would allow the attacking origin to get that content. In this case, the client is acting in good faith and can be assumed to use Origin. Otherwise, the attacker has complete control over the request, but they also need to find the cookie.

We have several protections working here: Origin (which requires that the cache check it, so it's weak), that the attacker doesn't know the cookies, and that the primary resource has to "prove" that it knows what the cache holds.

[reschke]

FWIW, the short-lived token could be part of the URI (that would just need to be arranged between origin and secondary).

[gaperik]

The URI parameter approach for tokens from primary to secondary via the client for the purposes such as access control or delivery accounting... Hm. Security and size considerations for URI parameters?

[MikeBishop]

URI parameters might also mess with the cacheability (or rather, the cache hit success rate) of the encrypted response, no? I believe we explicitly want the encrypted payload to be available to caches, and not just for the lifetime of the token....

[reschke]

Is cacheability of the encypted payload actually an issue? Won't it be served over https most of the time?

[gaperik]

I guess Mike was commenting on the cache hit rate in the secondary server, not http client cache...

@MikeBishop: if not URI parameter, what then? Header...? I would like that for varying reasons but X-headers triggers CORS (still) right?

[reschke]

It would only affect the cache hit rate in the secondary server if it would consider resources that only differ in access token as separate entities. Why would it do that?

[reschke]

Summary: there's a new possibility to essentially steal bandwidth, in hosting a copy of other people's content, but then using OOB to actual include the payload from the victim. (right, @MikeBishop ?)

The mitigations that we have are:

• can not include arbitrary content anyway, as we check for a special media type
• secondary server will check Origin header field

That said, is there something we need to document?