Posted by
Hemos
on from the programming-with-dial dept.
Irish writes "This IBM developerWorks article discusses the theoretical underpinnings of SOAP's type system. Its a good article for anyone who wants to learn more about SOAP's programmatic support or to simply better understand Apache's SOAP."
Bruce Schneier has said:
by
Gis_Sat_Hack
·
· Score: 5, Interesting
Implementation of Microsoft SOAP, a protocol running over HTTP precisely so it could bypass firewalls, should be withdrawn. According to the Microsoft documentation: "Since SOAP relies on HTTP as the transport mechanism, and most firewalls allow HTTP to pass through, you'll have no problem invoking SOAP endpoints from either side of a firewall." It is exactly this feature-above-security mindset that needs to go. It may be that SOAP offers sufficient security mechanisms, proper separation of code and data. However, Microsoft promotes it for its security avoidance.
Re:Bruce Schneier has said:
by
steve_l
·
· Score: 5, Informative
Bruce hasnt looked at the protocol enough, he is being paranoid.
well, doing SOAP callbacks into the firewall is hard because you have to have an accessible endpoint...for this reason you cant do SOAP callbacks over HTTP. But some of the other transports: SMTP, Jabber, do work and go through firewalls like nobodies business.
Another issue is that you can't tell whether the message is good or bad from the header; it will always be a POST and the same endpoint/URL could be used from everything from a side effect free get to a malicious bufferstomping write.
You need to look inside the XML payload, and, being XML, that means understanding XML...string matching is not enough, not when you can disguise stuff with escaping, UTF or Unicode formats, etc.
Re:SOAP ain't so 'S'imple no mo
by
gnovos
·
· Score: 5, Funny
XML RPC is simple - it has a 4 page specification. SOAP is, well, not so simple. SOAP started out simple, but then committees got a hold of it. Try reading the specification - it's well over 100 pages long - and all legaleeze.
The "Simple" in SOAP is like the Green in Greenland... it's there to keep the non-Vikings out... Look for Complex Hyperbolic Interface Protocol, that'll be the one that M$ ACTUALLY uses...
-- "Your superior intellect is no match for our puny weapons!"
There's one potential problem with SOAP - sending binary objects. You can't insert binary in XML, so the options are: - encode binary to 7-bit (hex, etc.) or - send it "outside" of the XML, as MIME attachment The acticle mentions these.
SOAP's popularity will be its problem
by
conan_albrecht
·
· Score: 5, Insightful
I just wrote an article on this. SOAP gets past firewalls because it *looks* like web traffic (at least, HTTP traffic). That's great because most firewalls let HTTP traffic on port 80 through.
However, once admins realize that we programmers are sending our services (which are inherently a security issue) through port 80, they'll likely start filtering SOAP.
One of the reasons that RMI and CORBA are firewalled is because they provide remote access to *objects* that might be powerful and that can certainly execute behavior within the trusted environment. SOAP does exactly the same thing, only it looks like HTTP traffic.
Yes, SOAP can be detected very easily by firewalls. Therefore, I'm predicting that as it becomes popular, many admins won't let it through as easily as it gets through today.
"XMI (XML Metadata Interchange) is an OMG standard for sharing UML models among applications"
What about the OMFG ROFL standard?
--
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
Re:Bruce Schneier has said:
by
mmusn
·
· Score: 5, Informative
By that argument, let's get rid of HTTP. I mean, HTTP invokes remote procedures on the web server, in the form of servlets and CGI scripts. In different words, SOAP is no less secure than HTTP. If your firewall passes HTTP to the wrong internal servers, you have a security problem, no matter whether you are running SOAP or not.
Hardly ever post here, but I know a thing or two about SOAP and thought you nice folks might find it informative.
I've done three implementations for three different clients in the last two years. The first integrated an existing UNIX front-end with an existing NT back-end (I know... the real world sure is strange), the second enabled a COM+ app server to talk asynchronously to Apache on a Linux, and the third was a port of a windows forms app that used DCOM to SOAP for use in a VPN.
I have to say that I am mostly pleased with SOAP, but that it does have areas that need improving.
Reading this board, I've noted a couple of misconceptions that seem pretty prevalent.
1. SOAP is not Simple. Several posters noted that the spec is over 100 pages long. Most of the specification is about the correct formatting of the description language on the server side. Fortunately, both Microsoft and IBM toolkits provide tools for generating this stuff and the tools cover 99.9% of what you will ever want to do. As a developer you can use SOAP without ever authoring a wsdl file. Reading the file is not very hard, I was able to write my first working SOAP client implementation within a week of starting. All you need is a good understanding of the HTTP protocol, XML, and your client platform.
2. SOAP is bloated. Many people (including me) think this when they first see an example of a web service description language (wsdl) file. The key thing to note is that a decently designed client only needs to read it once (using http GET) to understand the service. The actual requests (using http PUT) and responses don't have too much adornment and are pretty darn simple. The server will use the wsdl to validate incoming requests and if it has a decent design, it too only read it once on the service startup.
3. XML-RPC is better because it is simpler. XML-RPC is actually very, very similar to the rpc aspect of SOAP. But going back to 1. above the spec is so short because XML-RPC lacks an equivalent to wsdl (a runtime readable description of the service). In other words, XML-RPC requires you to understand the interface at design time. Because of this an XML-RPC solution is more tightly coupled and less flexible than an equivalent SOAP implementation. (This might be acceptable depending on the requirements).
4. Running over port 80 is bad. In fact, it can be. However SOAP requests are generally speaking, HTTP POST, so this has less to do with the standard than the reliability and security of the listener. A good listener will act as an application proxy and reject any shenanigans. A good network design that includes a DMZ with another firewall between the private network and the server is also required for it to be secure. Message level security can use SSL or an alternative.
5. It isn't standard between vendors. Some validity to this, but I found the differences between M$ and IBM to be very minor and easy to accommodate.
There are some problems with running over HTTP though. 1. It is never as fast as native rpc solutions in my experience. You can cut down on the size of the response by using gzip or deflate with http 1.1, but there is no facility for compression on the inbound side. The need to minimize round trips is directly at odds with this lack of functionality because:
2. It is stateless so things like transactions are very difficult to do and cause the requests to contain enough info for the server to do something ACID... These accentuates problem number 1.
3. You can't do call backs or event from the server to the client. This is strictly a 'you request and I respond' protocol. You can't push from the server to the client with SOAP.
Slashdot Mirror
Implementation of Microsoft SOAP, a protocol running over HTTP precisely so it could bypass firewalls, should be withdrawn. According to the Microsoft documentation: "Since SOAP relies on HTTP as the transport mechanism, and most firewalls allow HTTP to pass through, you'll have no problem invoking SOAP endpoints from either side of a firewall." It is exactly this feature-above-security mindset that needs to go. It may be that SOAP offers sufficient security mechanisms, proper separation of code and data. However, Microsoft promotes it for its security avoidance.
- 0202.html
source:
http://www.counterpane.com/crypto-gram
Bruce hasnt looked at the protocol enough, he is being paranoid.
well, doing SOAP callbacks into the firewall is hard because you have to have an accessible endpoint...for this reason you cant do SOAP callbacks over HTTP. But some of the other transports: SMTP, Jabber, do work and go through firewalls like nobodies business.
Another issue is that you can't tell whether the message is good or bad from the header; it will always be a POST and the same endpoint/URL could be used from everything from a side effect free get to a malicious bufferstomping write.
You need to look inside the XML payload, and, being XML, that means understanding XML...string matching is not enough, not when you can disguise stuff with escaping, UTF or Unicode formats, etc.
XML RPC is simple - it has a 4 page specification. SOAP is, well, not so simple. SOAP started out simple, but then committees got a hold of it. Try reading the specification - it's well over 100 pages long - and all legaleeze.
The "Simple" in SOAP is like the Green in Greenland... it's there to keep the non-Vikings out... Look for Complex Hyperbolic Interface Protocol, that'll be the one that M$ ACTUALLY uses...
"Your superior intellect is no match for our puny weapons!"
There's one potential problem with SOAP - sending binary objects. You can't insert binary in XML, so the options are:
- encode binary to 7-bit (hex, etc.) or
- send it "outside" of the XML, as MIME attachment
The acticle mentions these.
However, there's one more way to do it - the new DIME protocol. It's explained in this article:
DIME: Sending Binary Data with Your SOAP Messages
I just wrote an article on this. SOAP gets past firewalls because it *looks* like web traffic (at least, HTTP traffic). That's great because most firewalls let HTTP traffic on port 80 through.
However, once admins realize that we programmers are sending our services (which are inherently a security issue) through port 80, they'll likely start filtering SOAP.
One of the reasons that RMI and CORBA are firewalled is because they provide remote access to *objects* that might be powerful and that can certainly execute behavior within the trusted environment. SOAP does exactly the same thing, only it looks like HTTP traffic.
Yes, SOAP can be detected very easily by firewalls. Therefore, I'm predicting that as it becomes popular, many admins won't let it through as easily as it gets through today.
My $0.02.
"XMI (XML Metadata Interchange) is an OMG standard for sharing UML models among applications"
What about the OMFG ROFL standard?
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
By that argument, let's get rid of HTTP. I mean, HTTP invokes remote procedures on the web server, in the form of servlets and CGI scripts. In different words, SOAP is no less secure than HTTP. If your firewall passes HTTP to the wrong internal servers, you have a security problem, no matter whether you are running SOAP or not.
Hardly ever post here, but I know a thing or two about SOAP and thought you nice folks might find it informative.
I've done three implementations for three different clients in the last two years. The first integrated an existing UNIX front-end with an existing NT back-end (I know... the real world sure is strange), the second enabled a COM+ app server to talk asynchronously to Apache on a Linux, and the third was a port of a windows forms app that used DCOM to SOAP for use in a VPN.
I have to say that I am mostly pleased with SOAP, but that it does have areas that need improving.
Reading this board, I've noted a couple of misconceptions that seem pretty prevalent.
1. SOAP is not Simple. Several posters noted that the spec is over 100 pages long. Most of the specification is about the correct formatting of the description language on the server side. Fortunately, both Microsoft and IBM toolkits provide tools for generating this stuff and the tools cover 99.9% of what you will ever want to do. As a developer you can use SOAP without ever authoring a wsdl file. Reading the file is not very hard, I was able to write my first working SOAP client implementation within a week of starting. All you need is a good understanding of the HTTP protocol, XML, and your client platform.
2. SOAP is bloated. Many people (including me) think this when they first see an example of a web service description language (wsdl) file. The key thing to note is that a decently designed client only needs to read it once (using http GET) to understand the service. The actual requests (using http PUT) and responses don't have too much adornment and are pretty darn simple. The server will use the wsdl to validate incoming requests and if it has a decent design, it too only read it once on the service startup.
3. XML-RPC is better because it is simpler. XML-RPC is actually very, very similar to the rpc aspect of SOAP. But going back to 1. above the spec is so short because XML-RPC lacks an equivalent to wsdl (a runtime readable description of the service). In other words, XML-RPC requires you to understand the interface at design time. Because of this an XML-RPC solution is more tightly coupled and less flexible than an equivalent SOAP implementation. (This might be acceptable depending on the requirements).
4. Running over port 80 is bad. In fact, it can be. However SOAP requests are generally speaking, HTTP POST, so this has less to do with the standard than the reliability and security of the listener. A good listener will act as an application proxy and reject any shenanigans. A good network design that includes a DMZ with another firewall between the private network and the server is also required for it to be secure. Message level security can use SSL or an alternative.
5. It isn't standard between vendors. Some validity to this, but I found the differences between M$ and IBM to be very minor and easy to accommodate.
There are some problems with running over HTTP though.
1. It is never as fast as native rpc solutions in my experience. You can cut down on the size of the response by using gzip or deflate with http 1.1, but there is no facility for compression on the inbound side. The need to minimize round trips is directly at odds with this lack of functionality because:
2. It is stateless so things like transactions are very difficult to do and cause the requests to contain enough info for the server to do something ACID... These accentuates problem number 1.
3. You can't do call backs or event from the server to the client. This is strictly a 'you request and I respond' protocol. You can't push from the server to the client with SOAP.
Hope you found this informative.