I'm sure Paul Kulchenko will soon fix the SOAP::Lite vulnerability that was just noticed . This episode got me to wondering, though, about the original rationale for the SOAPaction HTTP header, and what can or should be done to make filtering SOAP traffic workable. Several years ago, one of the original SOAP FAQs , from DevelopMentor, said:
Since SOAP packets declare their "intent" by publishing interface and method names in the HTTP header, it is possible for firewalls to perform filtering based on this information (the SOAP spec states that implementations must verify that this information must match the corresponding headers and tags in the SOAP payload, otherwise the call should be rejected).Here's what the SOAP spec itself has to say on the matter:
The presence and content of the SOAPAction header field can be used by servers such as firewalls to appropriately filter SOAP request messages in HTTP.
Things didn't turn out quite that way, though. No consensus as to the security role of the SOAPaction header is evident among firewall experts [ 1 , 2 , 3 ], nor among XML protocol experts [ 1 , 2 , ].
Did the notion advanced in DevelopMentor's FAQ -- that SOAP packets would declare intent by publishing interface and method names in the HTTP header -- make sense? At the time it seemed reasonable to me. But now, I wonder if a SOAPaction policy isn't rather like the scene in Bananas where the newly-installed dictator declares that "everybody must wear their underwear on the outside, so we can check." The interfaces that a company chooses to expose to the world are, in the end, a policy that will or won't be enforced, regardless of the SOAP toolkits in use or the translations performed in a request pipeline. Enforcement will always require more than checking for underwear on the outside.
Sure, opening and inspecting packets will slow things down. And then XML accelerators will be invented to speed things back up again.
Solving this kind of problem is much, much harder than anybody wants to admit. It means you have to inventory your software assets, manage change, and be able to clearly describe the interfaces between your network and the global network. The same was always true for CGI, though; it's no different for SOAP.
Standardizing one HTTP header may not really help much. What will is to enumerate all the RPCs that you support, and as we move to a more document-oriented style of SOAP messaging, to provide the schemas that describe those documents. There's no free lunch. But here's an encouraging thought. The uniformity of XML, and the declarative style of XML processing, may help us to define policies and create tools to enforce them.
Former URL: http://weblog.infoworld.com/udell/2002/04/09.html#a184