|
You are allowing people in the internet at large to invoke code on a server behind your firewall.
A naive programmer is still a threat, regardless of the port number you expose the functionality on. Moreover, someone's got to route that port to the "dangerous individuals" server from your firewall; you can restrict who can post updates, and you should.
You should have a change control policy as well.
What's important to understand about SOAP is that the transport isn't the point; yes, HTTP is easy to circumvent. What if you want to use SFTP to send the request? There, most likely, you'll use a directory exchange mechanism... or send the request via SMTP?
Is your firewall going to monitor/block all of this? What if I, on my PC, write a SOAP-via-SMTP bridge for MAPI? I'm able to connect to e-mail, perhaps even periodically, and to service SOAP requests... What if I accept the requests "backwards" over a bridge, etc.
The firewall cannot enforce this security; your best bet is to only redirect ports to trusted and secure internal PCs, and to use a form of change control to control what gets posted.
Securing per-object or interface on the firewall is certainly possible, but it's more efficient on the server doing the work. You really want a separate object (or interface) for each category of security.
Of course, this means having a security review after your code review and before deployment. That should include whoever is responsible for your system's security.
Anyway, it's the same issue as with CGI, ISAPI, ASP, JSP, etc. you have code running on your server in response to requests from outside your arena. Security risks are exactly the same as for these other technologies, and you need to take it exactly as seriously.
You can always use HTTPS transport and have your web server authenticate the user. The spec doesn't mention this, but the most commmon implementations allow it.
|
Previous Message
