Re: ACTION-278 Hiding metadata for security reasons

On Dec 29, 2009, at 8:14 PM, Jonathan Rees wrote:

> One thing puzzled me: The only really secure solution (against DNS
> attacks, MITM, and so on) is to put the unguessable part in the
> fragid. This would point directly at the webkeys approach. The google
> calendar case is something like
> 
> http://www.google.com/calendar/hosted/creativecommons.org/embed?src=jonathan.rees%40gmail.com&ctz=America/New_York&pvttk=ebbb36156aaf108300c96ad196573f5d
> 
> (The bits have been changed to protect the innocent.) Note (1) http
> not https, (2) unguessable portion before #, not after #.

I would note that Craigslist generates capability URIs that look like this (example modified from a real Craigslist posting edit/delete capability URI):

https://post.craigslist.org/manage/3269573419/3hxp7

> 
> Do we endorse this kind of thing, tolerate it, or advise against it?

> Are any private URIs other than web-keys OK?

I think it depends on the context. I believe that the idea with putting the secret part after the fragment ID is that this part MUST NOT (according to RFC2616) be included in the HTTP Referer header of a subsequent request to another site (which would thus reveal the "secret" to a third-party). 

In the Craiglist example, my capability URI came in an email from Craiglist, and when I clicked on it, there were no links in that page to any other site on the page, thus I would not expect there to be 'Referer leakage'. However, if the capability URI pointed to a resource which gave an HTML representation containing links (or requests for images, CSS et al) to other sites, there would be a higher probability of Referer leakage.   

In order to prevent Referer leakage, I think you need to put the secret portion after the fragid. Referer leakage may or may not, however, be a threat in any specific case.

Regards,

- johnk

Received on Wednesday, 30 December 2009 02:04:47 UTC