Subject: [CDNi] Insecure URI signing

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 26 Mar 2015 22:07:05 -0700

Hi everyone,

I’ve meant to comment on this for a while:

> Note that any parameters appended to the query string after the URI Signing Package Attribute are not validated and hence do not affect URI Signing.

I understand the use case, but it seems like an incredibly high cost to pay. In some applications the URI signing is to protect a resource behind the CDN cache/proxy, and unless the CDN strips these extra attributes (which I don’t think I saw recommended) then it’s certainly going to be a consistent source of bugs in applications relying on CDNI URI signing.

Most APIs for getting query parameters don’t have a concept of positioning like this, so unless extreme care is taken the arguments after the signature are not going to be ignored.

I understand that those applications will be wrong and not implementing the standard; but if the standard makes it easy to produce buggy implementations then the standard is usually just as much at fault.

Has this been discussed on the list before?

Ask

-- 
http://www.askask.com/

---

From: Kevin Ma J <[email-masked]>
Date: Fri, 27 Mar 2015 05:59:51 +0000

Hi Ask,

  If the URL is signed by the CSP/uCDN and that URL is to be validated by the dCDN, what is the use case where the dCDN is going to need to evaluate the query string parameters (post-pended by the client to the signed URL generated by the CSP/uCDN?) in order to deliver the content?  If the client is post-pending additional query string parameters after the CSP/uCDN has already signed the URL, how would you envision the subsequent resigning of those additional parameters occur (given that allowing the client to sign has obvious key management issues, and if the CSP wanted to mandate that the client send those parameters initially, to be included in the original signed URL, it could)?

  Within the context of CDNI, it's not clear to me what role the additional query string parameters play?  You mentioned "protect[ing] a resource behind the CDN?"  Are we talking about client appended parameters required for content acquisition by the dCDN?  If that was the case, I would think the CSP/client need to figure out how to get the client a signed URL with all the necessary parameters in it?  I think the same would go for application servers in the dCDN (as opposed to simple file delivery), or even additional parameters simply for logging purposes?

  You also mentioned having the "CDN strip[] these extra attributes?"  Is your concern that a MitM is going to insert rogue attributes?  Removing attributes could prevent debugging, cache busting, or other legitimate uses of additional query string parameters by the client?  HTTPS might be a better option?

  What types of bugs, specifically, do you foresee?

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of Ask Bjørn Hansen
> Sent: Friday, March 27, 2015 1:07 AM
> To: [email-masked]
> Subject: [CDNi] Insecure URI signing
> 
> Hi everyone,
> 
> > Note that any parameters appended to the query string after the URI
> Signing Package Attribute are not validated and hence do not affect URI
> Signing.
> 
> I understand the use case, but it seems like an incredibly high cost to pay.
> In some applications the URI signing is to protect a resource behind the CDN
> cache/proxy, and unless the CDN strips these extra attributes (which I don’t
> think I saw recommended) then it’s certainly going to be a consistent source
> of bugs in applications relying on CDNI URI signing.
> 
> Most APIs for getting query parameters don’t have a concept of positioning
> like this, so unless extreme care is taken the arguments after the signature
> are not going to be ignored.
> 
> I understand that those applications will be wrong and not implementing the
> standard; but if the standard makes it easy to produce buggy implementations
> then the standard is usually just as much at fault.
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni