- From: Malcolm Rowe <malcolm-what@farside.org.uk>
- Date: Sun, 25 Jul 2004 22:48:38 +0100
Jim Ley writes: > Aswell as Malcolm's concerns with practicality of this, I have pretty > significant concerns about the security of it - as it takes the > security completely out of the hands of the user. Just to clarify: I don't have any significant concerns about the implementation /per se/; I merely thought it would be relevant to point out that the implementation is another instance of a general 'problem' that the W3C TAG is currently looking at. As it happens, I note that this particular implementation *does* allow delegation, since the spec makes specific provision of it, so one of my 'objections' is actually partially handled (although it still requires support from the server owner; not ideal). It still pollutes the URI namespace though. > I'm really quite alarmed by this approach in fact, [...] Also can you > please put a great big security warning on the "What's new" that > clarifies and explains exactly what these new "security models" are Note that Doron started out by saying "Back at Netscape". Far from being recent, that document was written in April 2003. It also looks like it's been implemented in the Mozilla SOAP code since about then - see bugzilla bugs 183824 and 203371. The latter bug extends the model to allow a site to indicate that a service is accessible from script loaded from *any* URL (i.e., that it is a public service). Additionally, a list of 'public' services can be specified by a preference (xml.webservice.security.masterservices) - but don't worry, it's blank by default. Finally, note that signed scripts with sufficient privileges (and 'trusted' unsigned scripts?) bypass this restriction entirely. >[moved] > If my bank makes a mistake and provides its web-service available to > random domains there's nothing I can do to, to either be aware of it, > or presumably disable it on an individual basis. 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. 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), particularly ones that are accessible from your *internal* network. 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". Regards, Malcolm
Received on Sunday, 25 July 2004 14:48:38 UTC