- From: John Kemp <john@jkemp.net>
- Date: Tue, 29 Dec 2009 21:04:16 -0500
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: Tyler Close <tyler.close@gmail.com>, www-tag@w3.org, "Mark S. Miller" <erights@google.com>
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