SOAP: The future or a security nightmare

At JavaOne, there was a speaker who pointed out that "security admins don't really care what goes through the firewall, as long as it goes through port 80". Lots of laughter in the audience...

It's one of the main reasons I've turned into a Java advocate. I'm totally dumbfounded by the fact that, after all these years and all the Internet issues, it is still the only language/runtime with a security model built in. Granted, lots of people don't care and think it's sitting in the way (like firewalls), but at least there's a model to work with, and to think about.

If you've spent some time thinking about security for distributed systems, read up on Java's security model, fiddled a bit with Jini, then you almost certainly have come to the conclusion that security-at-the-firewall is a braindead idea. With SOAP and C#, it seems that that message hasn't registered yet with Microsoft.

Both of those frameworks had similar issues. I previously worked for IONA, who produced the Orbix CORBA implementation, and while there designed and implemented Wonderwall. (didn't come up with the name though ;)

This was an application proxy for IIOP (CORBA's on-the-wire protocol) so that CORBA services could be shared over the internet and a rough equivalent of tcp_wrappers security could be applied; ACLs could be used to govern access to specific objects, sets of objects, and methods.

Basically CORBA and now SOAP are all doing the same sort of thing; and this problem has been solved before. In fact a pal recently told me about some Intel (!!) code which dealt with stripping XML in a firewall proxy which would be including similar concepts to what would be required.

Unfortunately the incompatibilities between IBM and MS' implementations make me a little worried -- could be that SOAP will gradually drift down the path of i14y nightmares that CORBA had for a while...

BTW I strongly disagree with cdegroot's assertion that "security at the firewall is a braindead idea". On the contrary; it's the only way to provide a basic perimeter around an organisation's network which has a chance of maintaining its integrity over time.

The alternative is to leave a more open firewall and hope that you can keep every network device secure. Good luck with that strategy, your security guy's workload just went up 1000% ;). And how exactly can you guarantee that every proprietary network service on the new W2K machine (or whatever) can successfully block attackers from outside your network? Don't have the source? Don't have a decent log system logging connection attempts? Ah well, then you're SOL. And even if W2KSP1 will block those connections -- what about W2KSP2? Desktop software as it stands is just too much of a moving target for network security.

I do agree that sandboxes like Java's are a good idea and are great for security, although Java seems to be gradually working on eroding the sandbox through signed applets and the new Marimba-Castanet-reinvented "Web Start" system. But they are far from making firewalls obsolete.

--j.

Though the uses may at times seem like an apples vs oranges case, SOAP is high redundant. If people want to have a protocol for securely sharing XML data, it likely would best be done through DSML and authenticating against its backend LDAP server. Its funny how everyone wants to build yet another database, yet another http, and yet another directory. I agree that its a security nightmare since they'll have to re-invent or bolt on the same thing... and it will have to be auditing again.

Perl's original security model, "tainting", was designed to make setuid execution safer. It turns out to be useful for any case where the program is executing with different credentials from the entity that invoked it.

I recommend that as much code as possible that runs on web servers, especially CGIs, be written in Perl and run with taint mode enabled.

Now how much would you pay? But wait, there's more!

For running untrusted code, the opcode and Safe modules provide various degrees of protection from mischief.

In fairness, I have to say that Java's concept of allowing e.g. network connections but only to the original server is quite good, and I don't think Perl has that. Yet.

Rubbish.

Anytime you complicate security, you weaken it. In fact, this is one of the problems I have with Java's security model -- it is large and unwieldy. Jonathan Shapiro, the principal author of the EROS kernel, has written:

Java solves this problem [of security] by ad-hoc restrictions. You may have noticed that people keep finding new security problems with Java. This is because ad-hoc security mechanisms don't work. It is better to have done the job right in the first place. Capabilities have a formal, mathematically sound model that can (and has) be used to prove their security.

Don't get me wrong: Java's security model isn't awful. A decent amount of thought has been put into it. I happen to think it's superior most other languaged-based security models (though you might want to take a look at E). But security, as Shapiro says, is too important to be dealt with in ad-hoc ways. EROS's capability model is very interesting, as is proof-carrying code and proof-carrying authentication. I'd give links, but I'm in a hurry right now, and you can find any of this stuff via web search anyway.

...but as one of the early implementors (and adopters) of XML-RPC and SOAP, I have a hard time understand much of the security criticism.

in practice, SOAP is nothing more than an embellished CGI request. you send the server some XML, it parses it, does something in response, and returns some XML.

that's no different from a CGI form -- or any HTTP request, for that matter (remember the $DATA glitch on NT servers?). if there's a hole in the *underlying* software, someone will come up with a way to use that. nothing new here.

or is it? what am I missing?

Granted, if you have a load of Win2K machines behind them, it's not a very wise idea to remove the firewall. But in principle, firewalls do a lot of damage to the organization's flexibility to respond to the environment, cooperate with other organizations, etcetera. The goal should be to make devices secure a priori, rather than leave them open and try to make them secure by putting them behind a thick steel door with arbitrary holes in it.

Java solves this problem [of security] by ad-hoc restrictions. You may have noticed that people keep finding new security problems with Java. This is because ad-hoc security mechanisms don't work.

As one of the principal Java security designers, Li Gong, maintains: the vast majority of the Java security-related flaws where implementation-related, not model related. The model seems to be very sound, and I don't see anything "ad-hoc" in it - maybe in a mathematical sense, but somehow I'd think that we wouldn't have had so much functionality in such a short time if that route wouldn't be taken. The usual security-vs-usability debate, probably, where I think Java takes a very sound position of combining usability with security. But thanks for the pointer to EROS - never heard of the stuff, I'm reading up now...

...but as one of the early implementors (and adopters) of XML-RPC and SOAP, I have a hard time understand much of the security criticism.

in practice, SOAP is nothing more than an embellished CGI request. you send the server some XML, it parses it, does something in response, and returns some XML.

Why not go all the way? There's GNU httptunnel, which will give you a bidirectional stream even through http proxies. That's just embellished CGI too, right?

What's the point of having an outbound firewall when a growing number of apps like AIM have a "configure network" dialog that really means "portscan my firewall looking for outbound vulnerabilities"?

(btw, I'm not suspicious of inbound port blocking, because even on my home lan I have a few boxes that can't defend themselves.)

sorry, but I completely fail to see in what way SOAP is related to data tunneling. can you elaborate?

As one of the principal Java security designers, Li Gong, maintains: the vast majority of the Java security-related flaws where implementation-related, not model related.

This is a good argument when applied to just about anything except security. A "sound" security model which is difficult to implement correctly is a flawed one -- because security has to work perfectly for it to be useful, unlike features.

There is an excellent discussion of this (with reference to Java) here. Note that the article is principally about proof carrying code, which one can find out more about here.

I'll send Li Gong a mail about it :-).

In a perfect world, we'd be using stuff like EROS (I'm dying to take a look at it - time doesn't permit me, alas) and E. In the imperfect world, we compare SOAP's security model against Java/RMI's security model. I hope you'll at least concur with me that the Java community seems a lot more serious about getting security right from the bottom up.

(thanks again for the pointers, I had a lot of interesting reading material last weekend).

cdegroot , yes I do agree Javasoft has taken security very seriously; even if they don't quite get it perfectly right, they certainly do a better job than most. But back to SOAP...

Section eight of the SOAP specification is titled "Security Considerations." It basically says, "We'll deal with that later." Ah-ha.

I understand the gist of effbot's argument: SOAP is just sophisticated CGI. You send your HTTP request; you get your HTTP response. If SOAP is insecure, then so is everything else on the web. In some sense this is true, but I think it's highly misleading:

Normal HTTP traffic, as everyone knows, consists of simple, stateless conversations between a web browser and an HTTP server. Despite the fact that both the server and the borswer speak HTTP, they are very dissimilar programs. This encourages a model of "cautious interaction," in which the browser only trusts the server to such-and-such an extent (it will not, for instance, under normal circumstances, allow the server to wite to the local filesystem without user interaction). The server is likewise "suspicious" of the browser. The simplicity of the interaction between the two programs allows a fairly simple security model.

SOAP is an RPC mechanism, and not just an RPC mechanism, but a distributed object framework -- and that encourages an entirely different model of interaction. Rather than a client-server model, SOAP is designed for communication "between peers in a decentralized, distributed environment" [from the introduction to the specification]. To put it more clearly: whereas the normal use of HTTP is geared toward passing information between two mutually distrusting applications, one of which is the client and one the server, the point of SOAP is to use HTTP (and the nice hole in the corporate firewall at port 80) to distribute one application across a network.

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. I think that is what Schneier is reacting to: letting distributed objects play in the security space that we normally reserve for simple document retrieval and catalog sales is not smart.

jaz wrote: "the point of SOAP is to use HTTP (and the nice hole in the corporate firewall at port 80) to distribute one application across a network. "

I don't really think that's true; the SOAP model seems to be more like "Let's provide a SOAP interface into some system or application -- Fedex package tracking, a search engine, spell-checking, whatever." I don't think SOAP qualifies as a full-blown distributed object system since I don't think there's a way to return other objects from a SOAP method call, only simple data types like numbers and arrays. SOAP just provides more basic features than bare HTTP does, where you only get a status code and a response body, and therefore makes the interface a bit richer and maybe more natural.

SOAP for me at least is simply a more capable XML-RPC - allowing me to access Zope remotely in an easier fashion. And Zope has the same security model for any form of access, so SOAP on Zope (:-) is no less secure than accessing Zope via a web-browser.

SOAP has the same security problems as HTTP. If a trojan uses port 80 to send back commands, it can use plain CGI just as well as SOAP. SOAP does not add a security risk to you unless you run a SOAP server.

The problem is what you SOAP servers you are running, and if they are vulnerable. And that's the same problem we've always had.

Can you give one concrete example in which SOAP would make your network less secure, and explain why SOAP specifically causes this?