Re: Re: Re: [XHR] anonymous flag
On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen wrote: > So creating a new tri-state property in the XHR spec should also simplify > integration with the Fetch spec. Agreed. The question is, if we take it as a given that we're going to get a new API (that uses futures, deals with tainted requests, etc.) is it worth expanding the older API too? -- http://annevankesteren.nl/
Re: Re: Re: [XHR] anonymous flag
> > OK then - Anne and others, what do you think about creating a new tri-state > > xhr.credentialsPolicy property and discouraging usage of > > xhr.withCredentials ? > > I think I'd prefer removing the constructor flag and leaving new > features to the API for Fetch. Sorry, I don't understand what you meant by this sentence. Fetch already has the required "underpinnings" for this tri-state flag: http://fetch.spec.whatwg.org/#concept-request-omit-credentials-mode "A request has an associated omit credentials mode, which is one of always, CORS, and never." which maps exactly to credentialsPolicy: "omit credentials mode": always == credentialsPolicy: never (naming can be discussed, withCredentials='never' would be more intuitive but as we're not redefining withCredentials.. Maybe credentialsPolicy = 'nocredentials' ?) "omit credentials mode": CORS == credentialsPolicy: 'samedomain' "omit credentials mode": never == credentialsPolicy: 'always' So creating a new tri-state property in the XHR spec should also simplify integration with the Fetch spec. > Also, we still need to nail down the > details of withCredentials. Questions raised in > http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0499.html > have gone without conclusive answers. I'm afraid I have no idea what the answers are.. -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: [XHR] anonymous flag
On Thu, May 30, 2013 at 12:16 PM, Hallvord Reiar Michaelsen Steen wrote: > OK then - Anne and others, what do you think about creating a new tri-state > xhr.credentialsPolicy property and discouraging usage of xhr.withCredentials ? I think I'd prefer removing the constructor flag and leaving new features to the API for Fetch. Also, we still need to nail down the details of withCredentials. Questions raised in http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0499.html have gone without conclusive answers. -- http://annevankesteren.nl/
Re: Re: [XHR] anonymous flag
> > Now, if you are still not convinced this is a good change my plan B is to > > suggest a "credentialsPolicy" property so we'll find an agreement anyway. > > :-) But maybe explaining that no quirky getter magic is required helps you > > see the proposal in a new light? > > Whatever we're doing here is going to result in a lot of confusion. > There's already lots of existing code, tutorials and documentation > that treats this property as a boolean property. At best we'd not > break existing code, but cause a mix of code/documentation which some > treats it as a boolean and others as a string. > > Hence my statement that there's no way that we can create a clean > solution while reusing the existing property. > > So my objection still stands. Creating a new property seems to have > much fewer downsides. OK then - Anne and others, what do you think about creating a new tri-state xhr.credentialsPolicy property and discouraging usage of xhr.withCredentials ? -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: Re: Re: Re: [XHR] anonymous flag
On Tue, May 28, 2013 at 7:07 AM, Hallvord Reiar Michaelsen Steen
wrote:
> I wrote:
>
>> 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?
>
>
>
> I hereby propose that we drop the {anonymous:true} constructor argument and
> the "anonymous flag", and instead modify withCredentials to take three
> values: "samedomain" (default), "always" and "never". For backwards
> compatibility with earlier versions of the spec, setting withCredentials=true
> maps to "always" and withCredentials=false maps to "samedomain".
>
>
> This seems easier to understand, easier to implement, and handles all use
> cases of practical significance.
I'm opposed to this change. Trying to modify a boolean value into a
tristate can't be done fully backwards compatibly. Specifically, I
don't see a way to define this new behavior in such a way that reading
from withCredentials behaves in a backwards compatible way. At least
not while keeping the API sane.
I'd instead prefer to define a new property.
/ Jonas
Re: Re: Re: Re: Re: [XHR] anonymous flag
I wrote:
> 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?
I hereby propose that we drop the {anonymous:true} constructor argument and the
"anonymous flag", and instead modify withCredentials to take three values:
"samedomain" (default), "always" and "never". For backwards compatibility with
earlier versions of the spec, setting withCredentials=true maps to "always" and
withCredentials=false maps to "samedomain".
This seems easier to understand, easier to implement, and handles all use cases
of practical significance.
Anne: if you want rewrite proposals as pull requests, let me know ;-)
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: Re: Re: Re: [XHR] anonymous flag
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
Re: Re: Re: [XHR] anonymous flag
On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen < hallv...@opera.com> wrote: > > [Minor edit: fixed your true/false typo] > > > * If we had a better way of controlling the option to deny sending > credentials > > in a way that kept compatibility with legacy webpages (eg. a tristate > flag like > > you suggest in [6]), I agree it would be better than to have two > different flags > > which may be confusing to developers and which may disagree with each > other. > > I agree (naturally) - now, just to be very clear: your needs are met if > the API lets you control *credentials* - right? Does Caja currently attempt > to suppress Referer: and/or Origin: headers? Do you consider it a > requirement to be able to do so? > 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". Caja itself is a pure html, css and js rewriter and isn't always in a position to suppress headers without either awesome browser APIs like the one under discussion or with the help of a header stripping proxy. > * In Google AppScript and on Google Sites, we execute a code on the same > domain > > sandboxed using Caja. In this case, Caja relies on withCredentials > defaulting to > > false and prevents sandboxed guest code from setting it to true. In > this way, > > we're able to work around the difficulties posed by the API that you > point out. > > We are nevertheless forced to either proxy or deny requests to the same > origin since > > the CORS anon flag appears not be reliably supported on all browsers (and > > withCredentials does not apply to same-origin). > > > It sounds like making withCredentials a tri-state thing (i.e. with values > 'samedomain', 'always', 'never') would work better for you :) - depending > of course on how you respond to the above question, that is.. > +1. I do not have a strong opinion on what the API ought to be -- just that the feature is a necessary one. 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. > > -- > Hallvord R. M. Steen > Core tester, Opera Software > > > > > >
Re: Re: Re: [XHR] anonymous flag
[Minor edit: fixed your true/false typo] > * If we had a better way of controlling the option to deny sending credentials > in a way that kept compatibility with legacy webpages (eg. a tristate flag > like > you suggest in [6]), I agree it would be better than to have two different > flags > which may be confusing to developers and which may disagree with each other. I agree (naturally) - now, just to be very clear: your needs are met if the API lets you control *credentials* - right? Does Caja currently attempt to suppress Referer: and/or Origin: headers? Do you consider it a requirement to be able to do so? > * In Google AppScript and on Google Sites, we execute a code on the same > domain > sandboxed using Caja. In this case, Caja relies on withCredentials > defaulting to > false and prevents sandboxed guest code from setting it to true. In this way, > we're able to work around the difficulties posed by the API that you point > out. > We are nevertheless forced to either proxy or deny requests to the same > origin since > the CORS anon flag appears not be reliably supported on all browsers (and > withCredentials does not apply to same-origin). It sounds like making withCredentials a tri-state thing (i.e. with values 'samedomain', 'always', 'never') would work better for you :) - depending of course on how you respond to the above question, that is.. -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: [XHR] anonymous flag
On Wed, May 22, 2013 at 7:27 AM, ๏̯͡๏ Jasvir Nagra wrote: > * If we had a better way of controlling the option to deny sending > credentials in a way that kept compatibility with legacy webpages (eg. a > tristate flag like you suggest in [6]), I agree it would be better than to > have two different flags which may be confusing to developers and which may > disagree with each other. > > * In Google AppScript and on Google Sites, we execute a code on the same > domain sandboxed using Caja. In this case, Caja relies on withCredentials > Typo: Caja relies on withCredentials defaulting to false. > defaulting to true and prevents sandboxed guest code from setting it to > true. In this way, we're able to work around the difficulties posed by the > API that you point out. We are nevertheless forced to either proxy or deny > requests to the same origin since the CORS anon flag appears not be > reliably supported on all browsers (and withCredentials does not apply to > same-origin). The test for same origin is an error prone blacklisting > test. We look forward to all browsers providing the anon feature reliably > to avoid expensive proxying. > > * Irrespective of the difficulty of using the API correctly, we do need to > have the option to deny credentials to the same-origin. > > jas > > > On Tue, May 21, 2013 at 6:30 PM, Mark S. Miller wrote: > >> Let's please find some time to discuss this *today* if at all possible. >> I'm sure there will be several agenda items I don't need to be at, and >> there's always lunch. I would like us to be able to say that Caja, Sites, >> and Google AppScript use and need to use the UMP-enabling features of CORS. >> Is that true? If not, I'd like to see how close to that we can come. >> >> >> -- Forwarded message -- >> From: Hallvord Reiar Michaelsen Steen >> Date: Tue, May 21, 2013 at 1:41 PM >> Subject: Re: Re: [XHR] anonymous flag >> To: Charles McCathie Nevile , public-webapps < >> public-webapps@w3.org>, Jonas Sicking , >> tyler.cl...@gmail.com, m...@apple.com, dpra...@chromium.org, >> o...@chromium.org, erig...@google.com, w...@adambarth.com, >> jackalm...@gmail.com, i...@hixie.ch, dev.akh...@gmail.com, >> art.bars...@nokia.com, nat...@webr3.org, j...@jkemp.net >> Cc: Anne van Kesteren , Jungkee Song < >> jungk...@gmail.com>, Julian Aubourg >> >> >> Anne wrote: >> >> > I don't really feel it's responsible to remove this feature at this >> > point without anyone involved in the original discussion speaking up. >> >> Hi all, >> you were involved in a discussion [1] regarding UMP and CORS back in >> 2010. I know, it's a while ago, and apparently you had already been >> discussing this for *quite* a while. However, as the saying goes: no good >> deed goes unpunished, and I'd like wider feedback on an issue I've been >> discussing with Anne - so here's another chance to exercise those >> arguments. My apologies :-o.. >> >> I've been working on the XHR test suite, and thus been looking at the >> spec from a JS developer's perspective. From this perspective, I found that >> the withCredentials / anonymous flag features were somewhat confusing, to >> be more specific it was hard to figure out what the point of the anonymous >> flag really was. Some very close reading of the spec helped me figure out >> that the anonymous flag would: >> >> * Disable Origin: and Referer: headers >> >> * Send same-origin requests as if they were cross-origin: require >> preflights where CORS requests require preflights, and the same-origin >> server must opt-in with Access-Control-Allow-Origin and such. >> >> Now, I read through the old thread [1] - all of it, the UMP spec and some >> other related stuff, but still couldn't quite figure out what use cases >> this was meant to solve - so I questioned why we should have the anonymous >> flag at all in [2], [3] and [4]. (Sorry for referencing only my arguments, >> the interleaved E-mails are easy to find from there). >> >> So far in the discussion, I still think we should drop the "anonymous >> flag" feature from the spec. Some more thoughts beyond the arguments in the >> referenced E-mails: >> >> * On the web, the most widely used authorization models are cookies and >> SSL sessions. Authority is rarely if ever defined by Origin and/or Referer >> - and rightly so, since they can easily be faked in server-to-server >> requests. Some sites have traditionally whitelisted certain sites based on
Re: Re: [XHR] anonymous flag
* If we had a better way of controlling the option to deny sending credentials in a way that kept compatibility with legacy webpages (eg. a tristate flag like you suggest in [6]), I agree it would be better than to have two different flags which may be confusing to developers and which may disagree with each other. * In Google AppScript and on Google Sites, we execute a code on the same domain sandboxed using Caja. In this case, Caja relies on withCredentials defaulting to true and prevents sandboxed guest code from setting it to true. In this way, we're able to work around the difficulties posed by the API that you point out. We are nevertheless forced to either proxy or deny requests to the same origin since the CORS anon flag appears not be reliably supported on all browsers (and withCredentials does not apply to same-origin). The test for same origin is an error prone blacklisting test. We look forward to all browsers providing the anon feature reliably to avoid expensive proxying. * Irrespective of the difficulty of using the API correctly, we do need to have the option to deny credentials to the same-origin. jas On Tue, May 21, 2013 at 6:30 PM, Mark S. Miller wrote: > Let's please find some time to discuss this *today* if at all possible. > I'm sure there will be several agenda items I don't need to be at, and > there's always lunch. I would like us to be able to say that Caja, Sites, > and Google AppScript use and need to use the UMP-enabling features of CORS. > Is that true? If not, I'd like to see how close to that we can come. > > > -- Forwarded message -- > From: Hallvord Reiar Michaelsen Steen > Date: Tue, May 21, 2013 at 1:41 PM > Subject: Re: Re: [XHR] anonymous flag > To: Charles McCathie Nevile , public-webapps < > public-webapps@w3.org>, Jonas Sicking , > tyler.cl...@gmail.com, m...@apple.com, dpra...@chromium.org, > o...@chromium.org, erig...@google.com, w...@adambarth.com, > jackalm...@gmail.com, i...@hixie.ch, dev.akh...@gmail.com, > art.bars...@nokia.com, nat...@webr3.org, j...@jkemp.net > Cc: Anne van Kesteren , Jungkee Song , > Julian Aubourg > > > Anne wrote: > > > I don't really feel it's responsible to remove this feature at this > > point without anyone involved in the original discussion speaking up. > > Hi all, > you were involved in a discussion [1] regarding UMP and CORS back in 2010. > I know, it's a while ago, and apparently you had already been discussing > this for *quite* a while. However, as the saying goes: no good deed goes > unpunished, and I'd like wider feedback on an issue I've been discussing > with Anne - so here's another chance to exercise those arguments. My > apologies :-o.. > > I've been working on the XHR test suite, and thus been looking at the spec > from a JS developer's perspective. From this perspective, I found that the > withCredentials / anonymous flag features were somewhat confusing, to be > more specific it was hard to figure out what the point of the anonymous > flag really was. Some very close reading of the spec helped me figure out > that the anonymous flag would: > > * Disable Origin: and Referer: headers > > * Send same-origin requests as if they were cross-origin: require > preflights where CORS requests require preflights, and the same-origin > server must opt-in with Access-Control-Allow-Origin and such. > > Now, I read through the old thread [1] - all of it, the UMP spec and some > other related stuff, but still couldn't quite figure out what use cases > this was meant to solve - so I questioned why we should have the anonymous > flag at all in [2], [3] and [4]. (Sorry for referencing only my arguments, > the interleaved E-mails are easy to find from there). > > So far in the discussion, I still think we should drop the "anonymous > flag" feature from the spec. Some more thoughts beyond the arguments in the > referenced E-mails: > > * On the web, the most widely used authorization models are cookies and > SSL sessions. Authority is rarely if ever defined by Origin and/or Referer > - and rightly so, since they can easily be faked in server-to-server > requests. Some sites have traditionally whitelisted certain sites based on > Referer to avoid "hotlinking" of images, but hacking around such measures > is hardly a use case we should try to cater for. > > Hence, I don't even see much of a theoretical benefit to suppressing > Origin. > > * On the web, we usually value security-in-depth, i.e. several layers of > security checks. The UMP model seemed to argue strongly in favour of a > single point of failure - a token in the URL or in the body of a POST > request. It seems to me that most ser
Re: Re: [XHR] anonymous flag
Anne wrote: > I don't really feel it's responsible to remove this feature at this > point without anyone involved in the original discussion speaking up. Hi all, you were involved in a discussion [1] regarding UMP and CORS back in 2010. I know, it's a while ago, and apparently you had already been discussing this for *quite* a while. However, as the saying goes: no good deed goes unpunished, and I'd like wider feedback on an issue I've been discussing with Anne - so here's another chance to exercise those arguments. My apologies :-o.. I've been working on the XHR test suite, and thus been looking at the spec from a JS developer's perspective. From this perspective, I found that the withCredentials / anonymous flag features were somewhat confusing, to be more specific it was hard to figure out what the point of the anonymous flag really was. Some very close reading of the spec helped me figure out that the anonymous flag would: * Disable Origin: and Referer: headers * Send same-origin requests as if they were cross-origin: require preflights where CORS requests require preflights, and the same-origin server must opt-in with Access-Control-Allow-Origin and such. Now, I read through the old thread [1] - all of it, the UMP spec and some other related stuff, but still couldn't quite figure out what use cases this was meant to solve - so I questioned why we should have the anonymous flag at all in [2], [3] and [4]. (Sorry for referencing only my arguments, the interleaved E-mails are easy to find from there). So far in the discussion, I still think we should drop the "anonymous flag" feature from the spec. Some more thoughts beyond the arguments in the referenced E-mails: * On the web, the most widely used authorization models are cookies and SSL sessions. Authority is rarely if ever defined by Origin and/or Referer - and rightly so, since they can easily be faked in server-to-server requests. Some sites have traditionally whitelisted certain sites based on Referer to avoid "hotlinking" of images, but hacking around such measures is hardly a use case we should try to cater for. Hence, I don't even see much of a theoretical benefit to suppressing Origin. * On the web, we usually value security-in-depth, i.e. several layers of security checks. The UMP model seemed to argue strongly in favour of a single point of failure - a token in the URL or in the body of a POST request. It seems to me that most services that need securing would want to also check Origin, check cookies and/or SSL data. On the surface this is an argument *for* the anonymous flag: given the assumption that valuable services do layered security, having credentials dropped in requests that may be risky is a Good Thing (TM). However, the problem is we put the burden on developers to *set* the anonymous flag, to foresee what requests might be risky and take precautions, to opt-in to a mode where even same-origin requests become much more cumbersome to complete and where their *own* layered security measures will fail. This feature is IMHO very hard to use correctly, and can easily cause unexpected and hard to understand failure modes if used incorrectly. * If we can't easily explain to authors what a feature is for, it won't get used. * Having both withCredentials and anonymous flag is confusing and can give a false sense of security as explained in [6]. My preferred solution (which may be a little too "magic") is to turn withCredentials into a sort of tri-state flag, where setting withCredentials=false disables using cookies/HTTP Auth/existing SSL sessions on both same-origin and cross-origin requests, setting withCredentials=true enables it for both, and not setting it will leave the default behaviour to use authentication on same-origin and omit it for cross-origin requests. (Then drop the "anonymous" flag and ignore any requests for being able to suppress Referer: and Origin: (unless documented by use cases we want to support).) Another option might be to drop anonymous flag, "deprecate" withCredentials and define a new property called sendCredentials, taking values "sameorigin", "always" and "never", with "sameorigin" being the default value. Too bad I'm 2-3 years late with that suggestion, I think it would have been clearer. (Obviously, if we think existing content using withCredentials is written in a way that would let us get away with redefining it to being a string, use values "sameorigin", "always" and "never" and throw in a small hack translating true when set to "always", that would be totally sweet :-D.) Further, I think that as an extra security precaution, the spec should make it absolutely clear that if a CORS-request where withCredentials is *not* set to true/always gets redirected to a same-origin URL, credentials must *not* be sent while requesting the redirect target. This should close one of the existing potential holes and make XHR and CORS a tad more safe b
Re: Re: Re: [XHR] anonymous flag
> >> Making a boolean a tri-state with a > >> default depending on an external variable is also super confusing. > > > > To whom? > It seems confusing to anyone who reads the value. Good point. > What would it return > in the various situations? I.e. before and after .open() has been > called, and if .open() was called with a cross-origin URL or not. Simplest possibility seems to be "undefined" if not set, true or false respectively if it was set. Of course this doesn't reflect whether credentials will be sent in the request or not - but that doesn't really happen today either, we don't automagically make it return "true" for same-origin and "false" for cross-origin requests, so it's not much of a change. Most capability detection I've seen uses the sensible "'withCredentials' in xhr" form which will still work. -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: [XHR] anonymous flag
On Sat, May 18, 2013 at 1:43 PM, Hallvord Reiar Michaelsen Steen wrote: > >> > BTW - have you considered allowing setting withCredentials to "false" for >> > same-origin resources? >> > >> I suspect that would break sites. > > > Possibly, but I find it unlikely - if it's set, it's most likely usually set > to "true", not "false", and it's also most likely rarely set for same-origin > requests. Wonder how hard it would be to ship a test in some beta- or preview > build of some browser..? 8-) > > >> Making a boolean a tri-state with a >> default depending on an external variable is also super confusing. > > > To whom? "Defaults to true for same-origin, false for cross-origin, can be > set to override" seems to give authors a behaviour that's relatively > intuitive. (Authors would not really have to consider the odd tri-state > underpinnings, it still looks like a boolean except with a variable default > behaviour). It seems confusing to anyone who reads the value. What would it return in the various situations? I.e. before and after .open() has been called, and if .open() was called with a cross-origin URL or not. / Jonas
Re: Re: [XHR] anonymous flag
> > BTW - have you considered allowing setting withCredentials to "false" for > > same-origin resources? > > I suspect that would break sites. Possibly, but I find it unlikely - if it's set, it's most likely usually set to "true", not "false", and it's also most likely rarely set for same-origin requests. Wonder how hard it would be to ship a test in some beta- or preview build of some browser..? 8-) > Making a boolean a tri-state with a > default depending on an external variable is also super confusing. To whom? "Defaults to true for same-origin, false for cross-origin, can be set to override" seems to give authors a behaviour that's relatively intuitive. (Authors would not really have to consider the odd tri-state underpinnings, it still looks like a boolean except with a variable default behaviour). It might be weird and confusing to implement though.. -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: [XHR] anonymous flag
On Tue, May 14, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen
wrote:
> Say, for example, OpenID is a setup where the user might provide an
> "untrusted" URL to a third-party web site ("Here's the service that can
> authenticate me"), and XHR might be involved - but the Open ID *provider*
> would of course want to know what site it is interacting with, to present
> some information about what authenticating means to the user..
Why? That information could be in the resource. Or if you e.g.
implement your own browser-like thing that accepts arbitrary URLs you
would want something similar.
You might also want to do same-origin requests that do not include the
overhead of Cookie / Origin / Referrer headers. HTML already has
rel=noreferrer for that. We should expose functionality like that in
the low-level API.
--
http://annevankesteren.nl/
Re: Re: [XHR] anonymous flag
>>> Does anyone have real, non-contrived use cases for the anonymous flag?
>> The basic idea was preventing confused deputy attacks by not exposing
>> any information that could be used as such. So no credentials and no
>> data about where the request originated from, forcing the architecture
>> to be token-based effectively.
> I think the strongest use-case that I've been able to think of is to
> enable a website to take a URL from an untrusted source and then
> interact with that URL over HTTP.
I can see this as a conceptual or theoretical use case, but I'm not sure I can
come up with a real-life scenario where one might want to do this. I can see
some non-XHR use cases for expecting users to supply an un-trusted URL ("Over
there is the custom style sheet or background image I want on my blog"), but I
can't see any realistic XHR-based use case.
Say, for example, OpenID is a setup where the user might provide an "untrusted"
URL to a third-party web site ("Here's the service that can authenticate me"),
and XHR might be involved - but the Open ID *provider* would of course want to
know what site it is interacting with, to present some information about what
authenticating means to the user..
> By removing both user credentials and website credentials the website
> doesn't have to worry about confused-deputy problems. I.e. if website
> A gets a URL from untrusted source B, A can then interact with that
> URL without having to worry about that the server that it's
> interacting with will think "oh, this request is coming from A, it's
> fine to trust it then". I.e. it doesn't have to worry about B tricking
> it into taking actions which A has access to, but that B doesn't.
Let's call the third party site C, to go with the alphabet. C serves resources
with Access-Control-Allow-Origin: A.
B wants to either carry out an action or get content which B is not
authenticated to do, but C might be set up to allow for requests originating
from A. A already knows that B's cookies/HTTP auth/SSL credentials won't be
sent by default with the XHR request to the foreign URL. However, we expect A
to figure out and implement that it should also add an anonymous flag to its
XHR requests, to preemptively avoid attacks against C. How do you even start
explaining to authors when to use anonymous mode? Why doesn't the attacker B
simply type or paste a bookmarklet that triggers a non-anonymous XHR (or trick
the authenticated user of A into pasting one and sending the results)? Why
doesn't B just write a PHP script that fakes the Referer and Origin headers in
a request to C without involving A at all?
> This doesn't need to be obviously harmful "permanently delete files"
> types of actions. For those A would likely need to include some form
> of credentials anyway since any server-to-server communication can
> claim to be from A using origin/referer headers.
Indeed.
> It can also be simpler things like throttling bandwidth if it's
> getting too many requests from a particular source.
AFAIK here your assumption is that
- C is getting too many requests from B, starts blocking/throttling
- C still accepts requests from A (but not anonymous requests)
- A lets some user input a URL that it will *hammer* with XHR requests
- The developer working on A realises there is an exploit potential and
preemptively adds an anonymous flag
- C no longer accepts the requests B makes A make
Yay, all problems are resolved!? Hm.. My assumptions:
- Quite likely some or all of the resources A want to fetch are now unable to
detect that requests come from A, and hence stop serving them (or don't know
what value to put in the Allow-Origin header, amounting to the same thing),
- A's service becomes crippled.
- A developer gets support requests, regrets, and removes the anonymous flag
If C accepts anonymous requests in the first place, B can do anonymous requests
from its own site when C starts throttling based on origin. Or indeed do
backend requests with fake headers.
As far as I can tell, the problem we're trying to solve with the anonymous flag
is for all practical scenarios already solved by withCredentials. Any service
that's only "protected" by checking Referer and/or Origin header is already
really flawed and vulnerable to server-to-server attacks. These are much easier
to carry out than a "try to find a web site that accepts third-party URLs for
XHR requests and has access to the 'protected' resources" scheme.
Server-to-server attacks would not care about Access-Control-Allow-Origin
limitations either (indeed might just use the value as a source of information
when implementing the attack).
An {anonymous:true} flag in A's JS code is simply the wrong place to attempt to
fix any such vulnerabilities. We pay implementation complexity and gain, IMHO,
no protection.
Finally, I believe it's going to be virtually impossible to teach developers
how to use the anonymous flag, if our
