[whatwg] Re: Cross Domain Policies
malcolm-what at farside.org.uk
Sun Jul 25 15:36:36 PDT 2004
[This isn't entirely on-topic anyway, and (more importantly) I don't feel
qualified to answer many of your points, so I've left some of them
Jim Ley writes:
>> Correct, from what I've seen. But if your bank allows damage to be done
>> using untrusted (and almost certainly unauthenticated) SOAP calls, you've
>> got more to worry about.
> I'm sure there's plenty of scenarios where web-services are purely
> controlled by IP address authentication, there are some on the
> corporate LAN I spend all too many days on.
Yup, but the server administrator has to do something to enable scripts
loaded from other domains to be able to issue calls. It's not something that
the user can screw up (I appreciate your point that it doesn't seem to be
something the user can *disable* either...). That was explicitly mentioned
in the document.
>> Bear in mind that the *only* reason that this
>> mechanism exists is to prevent untrusted scripts from probing random SOAP
>> services (and other non-SOAP HTTP services, too, as it happens),
> No, the reason it's there is to allow SOAP calls to other domains
> without needing raised security priviliges, it's introducing laxxer
> security (normally no scripts can make cross-domain requests that get
> data). Please don't pretend it's there to tighten security.
Sorry, I didn't mean to imply that this model was better that the existing
model (same-origin, etc). I meant that it was better than nothing. I should
have said something like:
Some server operators would like to permit untrusted scripts to access their
services (for example: a public service, or a service hosted by a separate
ASP). From the document, it appears that the only reason that this mechanism
exists is [..]. If it wasn't for those reasons, it looks like there might
not have been *any* SOAP security model (i.e., as there isn't any in HTML
forms, for example).
>> As it says in the document: "The proposed declaration file places the
>> server operator, not the client in control of access to his server by
>> untrusted scripts".
> Yep, that's a BAD thing! It's not something to applaud, and it's
> certainly not something to sneak into a . release of a major UA.
It went into Mozilla 1.4 or 1.5, by the looks of things, hardly a 'point
release' - what would you have them do, wait for 2.0?
If you think there's a genuine security risk (and it sounds like you know a
lot more about this kind of thing than I do), I'd recommend you raise a bug
in bugzilla. If there's a problem, as you suggest, we should fix it before
shipping Firefox 1.0.
More information about the whatwg