- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 04 Nov 2009 21:15:42 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Tyler Close <tyler.close@gmail.com>, WebApps WG <public-webapps@w3.org>
On Nov 4, 2009, at 9:05 PM, Jonas Sicking wrote: > On Wed, Nov 4, 2009 at 6:04 PM, Maciej Stachowiak <mjs@apple.com> > wrote: >> >> I forgot to mention another shared secret management risk with the >> proposed >> GuestXHR-based protocol. The protocol involves passing the shared >> secret in >> URLs, including URLs that will appear in the browser's URL field. >> URLs >> should not be considered confidential - there have a high tendency >> to get >> inadvertently exposed to third parties. Some of the ways this happens >> include caching layers, the browser history (particularly shared >> sync of the >> browser history), and users copying URLs out of the URL field without >> considering whether this particular URL contains a secret. >> >> I believe this can be fixed by always transmitting the shared >> secret in the >> body of an https POST rather than as part of the URL, so this risk >> is not >> intrinsic to this style of protocol. > > What about headers? We could allocate a specific header which is > allowed to be set for cross site requests. Sending headers in cross-site requests would not help in the case where the proposed protocol sends the secret in the URI of a GET request. It's sending that as a redirect from an ordinary page load, and the page targeted by the redirect has no access to its own headers. Regards, Maciej
Received on Thursday, 5 November 2009 05:16:17 UTC