On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen
hallv...@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
