Slashdot Mirror
XML Web Services & Security
Handy writes "Web Services (SOAP, .net, WSDL ? , UDDI ? ) create an even greater need for robust security. Exposed interfaces and fragmented administration coupled with a need for app-level security points to a greater need for a centralized managed security services model."
Here is my take. And here is Bruce Schneier's..
A whois search also reveals that xwss.org and westbridgetech.com belong to the same people.
And to top it all off Westbridge sells an XML message server. Just what you need to implement all the good stuff talked about in the article.
This includes a broad patent on form signing which appears to cover most forms of hierarchical documents, such as XML.
You're talking about the wrong kind of security. Think "bugs" instead of "encryption".
The issue is that SOAP exposes backend functionality to the end-user (or end-developer).
As an example, consider the server that offers the web service that lets you look up your bank balance. Compare it to a CGI program that does the same thing. They have almost the exact same security issues: privacy of the data (solved by https) and authentication (making sure you are who you say you are). Both the web service and the CGI are equally dangerous by themselves.
The difference is that SOAP and other web services add the extra abstraction layer that offers one more place for the developer(s) to screw up. And it makes it one step harder for a sysadmin or developer to find problems.
As the recent SOAP::Lite vulnerabilty points out, this is a non-negligible risk.
SSL secures the transmission from prying eyes. It does not prevent someone from using your service in a manner you did not intend.
Security issues with Web services go way beyond the fact that it's transmitted in the clear.
All of the issues that have been dealt with in Web forms will reappear. Field type/length validation needs to occur, authentication, etc...
You can't just turn on SSL and expect it to solve all your security problems. Utilizing SSL brings up yet another problem - it disrupts security processes in place. IDS and anti-virus mechanisms at the edge of the network can't decrypt SSL traffic and therefore ignore it.
Unless you are using client certificates - which may be more possible with B2B as opposed to B2C - SSL isn't going to solve the underlying problems, which is verification and validation of a sometimes complex dynamic document that may contain data that is dangerous.
I don't have a solution, but I certainly admire the problem.
Well, here's the deal. Back in the day we have different types of packets going to different ports. (if you have a *NIX box, type cat /etc/services for a listing) Port N is for function X. Port M is for Y. So if you send packets to my server with a certain port, then I can assume it is for a specific service guard against specific things at the firewall level, not at the (less reliable) application level.
.Net) protecting specific services via the firewall level is moot now. There will be a rich function set all on the same port 80. This means that in order to have the same level of security in the SOAP framework, applications have to have similar security to that of your old webserver/firewall.
.Net server that uses SOAP. This is a very rich function set to check and make secure. And now it is the web applications programmers who do much of the checking, not the web server software/firewall writers.
Consider what requests had to go through before:
Web browser (or some client used by evil folks) ==> Firewall==> Web Server==> Applications (server?)==>data
Webservers operate on port 80 and so port 80 is mostly open thru the firewall. Webservers also typically have quite a limited function set which makes them easier to secure. Most of the information is handled in limited strings and it is mostly locked down these days.
SOAP also uses the same port 80 (to sidestep firewalls) and *all* functions go through that port. With SOAP (and
Now that we skip the firewall and the web server:
Web browser (or some client used by evil folks)==>(SOAP)Applications server==>data
Most of the few functions in a webserver are pretty basic. Most of the functions in a SOAP server will be complex. Imagine all the functions used to manipulate your personal information on a
All this is somewhat simplified but in general, applications are now the "weakest link" on the web. But the same people who write web applications will soon write object interfaces on SOAP servers which are that much closer to the mischevious out there.
I think you can call this 1 degree of seperation. ; )
Cheers,
-b
Things to note (strategic):
None of SOAP, WSDL, UDDI, and now WS Security are "Royalty Free".
SOAP isn't a de jure standard -- it's a W3C "note".
UDDI was supposed to move into an open standards body in 2001 but still hasn't.
By publishing WS Security on their websites and through no open standards body we see Microsoft, IBM and that other company abandoning even attempts to appear open.
On the technical side -- if you want to see a little deeper into the security issues left unsolved by SOAP, I recommend you look at the OASIS technical committee specification, ebXML Message Service Specification version 2.0 rev C.
SOAP also uses the same port 80 (to sidestep firewalls) and *all* functions go through that port.
SOAP is just the transport mechanism. You can assign SOAP servers to any port you want, not just 80. A lot of people focus on port 80 specifically because they're planning on using a web server to also handle their SOAP traffic, and because they want to eliminate firewall issues. This port probably should not be used except for non-secure, non-critical systems.
One thing I haven't seen discussed much in this thread is that SOAP isn't just for "web services". It's also a very good mechanism for general client-server systems. You can use SOAP instead of building your own custom RPC protocol, and you can use the myriad tools available for developing SOAP apps in lots of diffferent languages and operating systems. As to the security, it's no different than when you're setting up any other client-server systems. SOAP is just the transport -- just like if you were setting up a custom client-server solution with your own call and return protocol you'd need to decide how best to set up security, you need to do the same thing with SOAP apps.
As time goes on and the various security pieces made to work with SOAP get further developed, then the job of securing SOAP based client-server systems becomes that much easier.
SOAP also uses the same port 80 (to sidestep firewalls)
Soap can use port 80 if it wants, but there is absolutely nothing stopping you having your SOAP server running on any port you want. There is nothing forcing you to even use http/https for the transport layer.
To quote from section 2.1 of the SOAP standards
A SOAP message such as that in Example 1 may be transferred by different underlying protocols and used in a variety of message exchange patterns. For example, with a Web-based access to a travel service, it could be placed in the body of a HTTP POST request. In another transport binding, it can be sent in an email message (see section 3.2). Section 3 will describe how SOAP messages may be conveyed by a variety of transports.
There are security issues with SOAP, but this whole port 80/firewall thing is a red herring.