|
|
SOAP is a messaging format that can ride on top of other transport protocols, such as SMTP, but is primarily used with HTTP. One of the design goals for SOAP was that it should easily pass through firewalls (this is good and bad). This creates a problem, because many firewalls cannot adequately filter a SOAP message, which uses the same approach as a standard HTTP POST method. The early version of SOAP had a SOAPAction header that any firewall could inspect, but this is now deprecated.
For a firewall to adequately secure SOAP traffic, it must also perform XML parsing. The real problem comes in trying to figure out what to look for. Throughout this book we have seen SOAP with and without headers, at times using RPC encoding and method names, and sometimes not. This makes determining the security of a SOAP message difficult at best from the perspective of your firewall administrator.
The typical firewall administrator's reaction to coming under attack is to shut down specific firewall ports. Because SOAP may travel over port 80 (HTTP) or 443 (HTTPS), the administrator will shut down not only SOAP traffic but all Web-related traffic. Many organizations have used URL filtering approaching to enhance security. HTTP-based services typically support GET, PUT, POST, and DELETE. Security administrators can automatically look for PUT and DELETE requests and not allow them to traverse the network. The problem with SOAP is that it does not use these directives.
Our recommendation in this regard is to make sure that your security and firewall personnel spend the time to understand Web services security and that this is not left in the hands of developers alone. All players within a Web services architecture including developers, security administrators, project managers, and architects should purchase books on Web services that provide additional information on topics presented in this chapter.
|
|