SOAP stands for Simple Object Access Protocol and “is a protocol for exchanging XML-based messages over a computer network, normally using HTTP. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework that more abstract layers can build on” [1]. It works by sending a request message by the client (network node) to the server node and in return gets a response message from the server and this pattern is usually called RPC (Remote Procedure Call) which is the most common pattern used in SOAP [1].
Soap can also be defined as a format for sending messages via Internet. Since it is XML based, it offers platform and language indepencence.
Companies including big players such as Microsoft, HP, IBM and many others came together and proposed SOAP to W3C in may 2000 hoping that SOAP would revolutionize application development by connecting GUI desktop applications to powerful Internet servers using HTTP and XML [2]. What that means for developers is; with help of SOAP, application can now be converted into web applications.
Below is a skeleton of a SOAP message [3]:
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
...
...
...
...
...
...
Security implications and weaknesses:
One of the advertised advantages of SOAP is that it was designed to slip through firewalls as HTTP using port 80.
However you will probably be raising this question: Is this an advantage or a weakness? Well, although many people including myself would like to see this as an advantage, on the other hand Tim Bray (an editor of the XML specification), expressed this as “SOAP goes through firewalls like a knife through butter.” [4]. Therefore, I see this is a weakness for mission critical environments and advantage for other applications and implementations.
Since SOAP uses the same protocol as HTTP, it is very difficult to differentiate SOAP messages from HTTP messages. For instance, Paul Prescod points out an important point saying: “You can only recognize SOAP by doing XML parsing in the firewall. Okay, so now you know it is SOAP. You want to decide whether it is supposed to be allowed in the firewall. How do you decide that? SOAP has no uniform addressing model or reliable internal structure. Sometimes there is a header, sometimes there is not. Sometimes the body is RPC-encoded sometimes it is not. Sometimes there is a method name, sometimes there is not”. [4].
There are however security extensions available for SOAP to add features for sending secure SOAP messages including authorization, compliance with the XML Digital Signature specification for message authentication, and element-wise encryption for confidentiality [5]. Alongside with security, there are other weaknesses of SOAP such as performance. Since it is based on XML format, SOAP is slower than other middleware technologies such as CORBA.
Finally, with regards to security, I must agree with Jon Zeppieri who noted that: “The problem isn’t that SOAP somehow magically makes HTTP (the actual protocol) less secure than it has always been, but that it is a considerably more sophisticated use of HTTP and therefore requires a more sophisticated security model than the one we normally apply to HTTP traffic” [6].
Tayfun Bilsel
-
References:
[1] http://en.wikipedia.org/wiki/SOAP
[2] http://www.w3schools.com/soap/soap_intro.asp
[3] http://www.w3schools.com/soap/soap_syntax.asp
[4] http://www.prescod.net/rest/security.html
[5] http://www.xml.com/pub/r/973
[6] http://www.xmlhack.com/read.php?item=630
