[whatwg] Re: Cross Domain Policies
Malcolm Rowe
malcolm-what at farside.org.uk
Tue Jul 27 03:57:14 PDT 2004
Jim Ley writes:
> Most programming toolkits aren't run in a browser! This _DOES_ make
> Mozilla SOAP in secure, I have SOAP services running on this intranet
> which are protected purely by the fact they're behind the firewall,
> any machine here can access them, those outside cannot - However,
> www.anydomain.org can use them easily, if someone happens to drop an
> XML file in the root.
Sorry, but I don't see a problem here.
You have an internal webserver that contains important data, and accepts
SOAP calls; let's call it important.example.com. That server doesn't require
authentication, but that's ok, because you trust all your users.
Your browser is capable of making scripted SOAP calls. It's also capable of
downloading scripts from the internet. You don't want your browser to make
calls on your behalf using 'untrusted' scripts, but it's ok for it to make
calls using 'trusted' scripts.
There's no way to determine 'trusted' from 'untrusted' automatically, for
all organisations, since the degree of 'trust' may be different for each
service and organisation. For example, internal-phonebook.example.com may
trust any scripts downloaded from *.example.com, while important.example.com
may not trust scripts downloaded from anywhere else. Particularly (for this
example), it doesn't trust www.anydomain.com.
Note that this issue of 'trust' is only really relevant in an intranet
scenario, where you can trust your users; in the internet at large, a SOAP
service has to contend with malicious clients, so the server (and not the
client) must handle access control if necessary.
Mozilla's current implementation (ignoring some unimportant details) means
that scripts downloaded from important.example.com are the only ones that
can access SOAP services on that server.
If the server operator then decides that scripts at important-2.example.com
can also be trusted, they can create a file at
http://important.example.com/web-scripts-access.xml that contains a record
for important-2.example.com. The server operator is the one who manages the
data; they also get to set the policy.
When any script attempts to make a SOAP call to important.example.com, the
XML file will be downloaded by the client. If the file doesn't exist, or if
the script's origin does not appear in the file (and the service isn't
marked as public in the file), then the SOAP call is prohibited. [The design
also allows for delegation, but I'm ignoring that for now.]
Incidentally, if (for example) Google decided to allow any script to make
SOAP calls to api.google.com, they could carry out the same procedure and
mark the service as public.
I don't understand what your objection is to this design. It allows the
server operator to decide which scripts can be trusted to make SOAP calls to
their service. The server operator, and not the user, is the one who gets to
set the policy, and is also the person responsible for securing the data.
The only feasible attack that I can see would be if www.anydomain.com could
persuade the server operator to permit access from their domain, either
explicitly, or by marking the service as public. However, the server
operator effectively controls all the data on the server anyway (even in an
ASP scenario), so I don't see that this makes that hole any larger. That
would be like arguing that Apache's httpd.conf file allows the administrator
to disable .htpasswd checks sitewide. Sure, it does, but why does that give
you a realistic attack?
Do you have a better idea that still permits public (or semi-public) SOAP
services? After all, we don't restrict scripts from POSTing to different
domains, which is, essentially, the same thing.
Now, I do have *some* reservations about this design:
* It pollutes the URI space, which should be completely under the control of
the server operator. This is essentially the TAG issue that I originally
mentioned.
* It allows the server operator to permit access to all services held on
their server (with no override possible). This assumes that the server
operator is the stakeholder, which may not be the case. However, as
mentioned above, the server operator *does* have effective control over all
services running on their server, so this should not introduce any *new*
attack vectors.
I also have some issues with the Mozilla implementation:
* It allows a preference to be set that can be used to mark any service as
public. I'm sure that this is significantly faster in an intranet setup with
mass-deployed clients, since it removes the requirement for all users to
check the permissions file on the server. However, as an attacker, I now
only need to control that pref value on one intranet client machine in order
to be able to access any intranet service.
* As you pointed out, it doesn't appear to be possible to disable this model
and revert to just using the same-origin check. I would have thought that it
would be prudent to allow this, if only so that we can switch it off for a
security fire-drill. Fortunately, this doesn't look like it would be too
hard to implement. Doron, what do you think? Would this be worthwhile?
Regards,
Malcolm
More information about the whatwg
mailing list