- From: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>
- Date: Thu, 23 May 2013 12:10:51 +0200
- To: ๏̯͡๏ Jasvir Nagra <jasvir@google.com>
- Cc: "Mark S. Miller" <erights@google.com>, "Charles McCathie Nevile" <chaals@yandex-team.ru>, public-webapps <public-webapps@w3.org>, "Jonas Sicking" <jonas@sicking.cc>, "Tyler Close" <tyler.close@gmail.com>, mjs <mjs@apple.com>, "Dirk Pranke" <dpranke@chromium.org>, ojan <ojan@chromium.org>, w3c <w3c@adambarth.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "Ian Hickson" <ian@hixie.ch>, "Devdatta Akhawe" <dev.akhawe@gmail.com>, "art.barstow" <art.barstow@nokia.com>, nathan <nathan@webr3.org>, "John Kemp" <john@jkemp.net>, "Jungkee Song" <jungkees@gmail.com>, "Julian Aubourg" <j@ubourg.net>, "Anne van Kesteren" <annevk@annevk.nl>
On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen < hallvord@opera.com> wrote:
> Given that many services do (mistakenly or not) use Origin and/or Referer to make
> security choices, all these headers along with the cookie header ought to be
> considered "credentials".
Can you give any specific examples of services that use *and* rely on Origin and/or Referer to make security choices? For example if there is some backend code hosted on GitHub that I could consider to understand this issue better?
It might also help if you're able to point me to some documentation on how AppScript and Sites work exactly. My understanding is that you run untrusted scripts inside a trusted context (sandboxed), and need to make sure these scripts can not
1) load sensitive data from the origin server
2) cause side effects on the origin server
Your origin server obviously needs to verify incoming requests, using any or all of
* Cookies ("ambient")
* Tokens
* Origin: / Referer: headers ("ambient")
and that you make sure untrusted scripts that want to make same-origin requests use a cross-origin proxy to omit cookies and make sure these requests are thus not verified as trusted. Is this accurate?
Now, if you have any service that's *only* verifying requests by Origin: / Referer: I'm pretty sure your service has a glaring security hole..? If suppressing Origin/Referer is a requirement for Caja, can you sketch some realistic demo where an otherwise safe service becomes unsafe when this feature is missing?
> I do not have a strong opinion on what the API ought to be -- just that
> the feature is a necessary one.
And I fully accept that for Cookie/HTTP auth/SSL session credentials, but I would like to see some real code evidence that omitting Origin: and Referer: is necessary too. In theory sites might use them as "credentials" as you say, but in practise I don't see how that can work and be safe on the web.
If we ship XHR with an "anonymous" flag removing Origin: and Referer: and call it a security feature, wouldn't that *encourage* sites to validate requests by Origin: and Referer:? Aren't we basically pushing snake oil security measures if we do so?
> That said using two boolean flags (withCredentials and anon) to
> represent what is at least currently a tri-state value does (as you
> point out) run the risk of confusing developers who set the flags
> to conflicting values.
To be fair: as the spec is written, it's not supposed to be possible to set them to conflicting values. Implementations may of course be buggy..
I hope you don't mind me going on and on about this.. I think we may still have time to improve the spec here and make implementations support Caja's use cases better, so your input is very useful.
--
Hallvord R. M. Steen
Core tester, Opera Software
Received on Thursday, 23 May 2013 10:11:52 UTC