Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Aren't Web services limited to executing services through the server interface?

The ZapThink article, The new class of XML-aware intermediary, by Ronald Schmelzer and Jason Bloomberg, ZapThink, contains the quote, "The big problem with this all-or-nothing proposition is that XML/Web services traffic might be undesirable at the content-level, unlike standard HTTP traffic, because Web service traffic could theoretically execute any instruction on any computer on a company's internal network." My question is, how can this be? I would think Web services are limited to executing whatever services the server provides through its interface?
The point that the ZapThink article was bringing to the fore is that traditional firewalls do not give you the protection you might expect from a firewall when the message is a Web services message. The traditional firewall is usually configured to let traffic on port 80 and 443 through. The difference in the Web services case is that the message can be directed to applications, which are internal to your corporate network and may cause undesirable results.

Relative to your question, SOAP messages may contain RPC calls, which can activate processes in your internal applications. While you are correct in saying that the RPC is limited to the services that are provided by the application, this is not the whole story. For example, the service could have an RPC that withdraws money from your bank account or as a result of processing an incoming SOAP document may reveal sensitive information. If there are no further security measures, i.e. you are relying only on a traditional firewall, which is too often the case, then a requestor may send a SOAP message to withdraw your funds or read sensitive information that they should not be allowed.

This raises the broader subject that I have discussed in some of my previous answers and in my recent book, namely, that it is important to have security in depth. Many companies are still just relying on protection at the perimeter of their company using traditional security measures. This is not enough. Your need authentication and, too often lacking, access control in depth.

The job at the perimeter is to perform coarse-grained authentication and maybe some coarse-grained authorization. The reason I say coarse-grained is that you will have many spurious requests at the perimeter of which many can be rejected without expensive processing. Remember all the external requests are hitting your perimeter so it is undesirable to do expensive processing at the perimeter. When you move to your mid-tier the requests are directed to a number of applications thus reducing the density of requests at any application. Further, since you have more directed requests for a particular application you can make fine-grained access decisions related to that application. Further still, the Web services security specification work and security products based on these specs gives you the capability to make these fine-grained decisions for Web services requests at the application level.

Popping the stack, the Zapthink article did make a broad statement, but they did say "theoretically" :-). However, the point that they were making is important. One other point relative to the article is that they recommended using proxies to perform SOAP security at the perimeter. I agree with this. (In fair disclosure, I designed a SOAP proxy, which is on the market today.) However, even a Web services proxy, while it is better than the traditional firewalls, is not sufficient. You can only do so much at the perimeter.

Corporate security people need to educate themselves about the security products that support security in depth to deal with the more sophisticated attacks using Web services. Too many corporations are still willing to put all their protection at the perimeter and feel they are safe. They are not. The bad guys are getting smarter, so we, who are defending our corporation, must also become smarter and understand and use advanced methods and products.

Dig Deeper on Topics Archive

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.