- From: Malcolm Rowe <malcolm-what@farside.org.uk>
- Date: Sun, 25 Jul 2004 23:36:36 +0100
Hi Jim, [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 unanswered.] 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. Regards, Malcolm
Received on Sunday, 25 July 2004 15:36:36 UTC