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, MaciejReceived on Thursday, 5 November 2009 05:16:17 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:22 GMT