- From: Brian Smith <brian@briansmith.org>
- Date: Sat, 8 Nov 2014 18:30:02 -0800
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- Cc: Michal Zalewski <lcamtuf@coredump.cx>, Jim Manico <jim.manico@owasp.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Mike West <mkwst@google.com>, "eisinger@google.com" <eisinger@google.com>
Devdatta Akhawe <dev.akhawe@gmail.com> wrote: > For better or worse, we live in a world with ads and analytics > everywhere. You could argue that this should be done at the > server-side but analytics and ad conversion trackers are often purely > client-side and one of the things that is exciting about this group is > how we are trying to improve security with the acknowledgement that > such mashups are the reality. I agree. But, aren't analytics and ad conversion trackers usually third-party services, such that they wouldn't be covered by your proposal, which is restricted to same-origin? > The reality is that origins (for SEO etc) are too coarse grained > (heck, that's why we are working on sub-origins). Even for same-origin > referer flows, it would be nice to be able to control the URL: a user > clicking on a buy link on /some/internal/path/with/mildly/private/data > ends up on /buy; the document.referer value there doesn't need nor > should it have the full referer value. I agree. > Additionally, I just don't think adding a URI value in the policy > directive is that much addition in complexity. It is just adding a > "host-source" in the ABNF for "referer" directive. That syntax is more than you need, and more error-prone than you need. Given a restriction to same origin, specifying the scheme and hostname is redundant at best and a source of security issues at worst. Consider a document at https://example.com/a/b/c/d/?wut. Which of the following are you proposing to be valid values for the Referer from this document under your what you are proposing?: https: https:// https://example.com/ (equivalent to 'origin') https://example.com/a https://example.com/a/ https://example.com/a/b/ https://example.com/a/b/c/ https://example.com/a/b/c/d https://example.com/a/b/c/d/ https://example.com/a/b/c/d/? https://example.com/a/b/c/d/?w https://example.com/a/b/c/d/?wut https://subdomain.example.com/ https://total-lie.example.com/made-up?tricking-you Would the allowed values differ for same-origin navigation vs. non-same-origin navigation? My guess is that you are proposing only these would be valid, and only for same-origin navigation: https://example.com/ (equivalent to 'origin') https://example.com/a/ https://example.com/a/b/ https://example.com/a/b/c/ https://example.com/a/b/c/d/ Cheers, Brian
Received on Sunday, 9 November 2014 02:30:29 UTC