OK, OK. So securing Web services isn't that easy—in fact, it's downright difficult. So, in the traditional fashion of software development—where the market demands features now and security later—many businesses are tempted to deploy Web services that aren't tremendously secure (and many probably do).

In one sense, it could be argued that that isn't so terrible. Most of the potential security problems with Web services won't immediately be found by people with automated scanning tools if they're not yet trained to find the problems. But Web services security holes can be easily exploited by knowledgeable insiders—people interested in hacking for revenge or monetary gain. The insider threat is always at least as serious as the anonymous hacker threat. So ultimately, it pays to properly secure these services.

Since Web services is built on top of a Web server, the first step in securing Web services is to secure the server itself. Vulnerabilities have been found during the past year in both Microsoft IIS and the Apache Web server. So no matter which Web server you run, make sure you have installed all of the necessary security updates.

Next, audit your server so there are no unauthorized or legacy CGI, ASP or PHP scripts. Confirm that raw scripts can't be downloaded by people on the Internet. If your Web service is based on a database, make sure that the scripts don't contain user names and passwords. Instead, put that information in a separate file that's read by each script when it starts up. Among other things, that will make changing your passwords on a regular basis easier.


Making Connections
After you secure your Web server, you need to worry about how your Web services clients are going to connect to it. Are you going to be making anonymous Web services available over the Internet, or do you intend to use Web services for high-value transactions with your customers and suppliers? If money or business reputation or potentially confidential information is involved with your Web services, you'll almost certainly want to combine some form of authentication—to validate your incoming connections—with some form of encryption—to prevent unauthorized snooping on the actual transactions.

If you search for "securing Web services" on the Microsoft product support website, you'll get a nice set of articles on how to configure your Web server for the SSL encryption standard and how to install an SSL certificate.

There's also a great article by Matt Powell titled "Defending Your XML Web Service Against Hackers." Key issues that Powell addresses are spoofing, denial-of-service attacks and exploitable bugs.

Powell points to two issues to consider when creating Web services: buffer overflows and SQL-injection attacks. Buffer overflows are, of course, one of the most common security problems on the Internet today. They happen because a programmer has written a piece of code that assumes some piece of data will never be longer than, say, 256 characters.

To exploit the bug, an attacker provides a block of data that's much longer—say, 1,034 characters. Most of the attacker's data is garbage, but at the block is a small program. Because of the way the C programming language is implemented, the attacker's program can end up being executed by the Web server itself, giving the attacker complete control of your system. Avoid the problem by having your programmers assiduously check the length of every string read over the network—or by programming in Java, a language that doesn't have buffer overflows.


Talking Points
SQL-injection attackers are more subtle. Short for structured query language, SQL is the standard language for communicating with structured databases. Most database-driven Web services use information provided by the Web services client to create SQL statements. But if the application developer isn't careful, a malicious client can put actual SQL commands into the data stream. Unless the application developer specifically quotes or otherwise removes special characters from the data stream, those commands can be passed along to the database.

Even if you have a secure Web server and a secure Web services application, it's important to remember that many of these services are nothing more than glorified order-entry systems. Unless you have additional controls on those orders, you can run into more traditional security problems. Guard against them!

For example, many businesses have some kind of fraud-detection system running on their credit card processing engine, which means that suspicious-looking transactions are blocked until they can be manually reviewed. If you are accepting XML-enabled purchase orders through a Web services application, you should have suitable antifraud systems in place on the Web service as well. Simple systems establish a maximum number of dollars and transactions per customer per month, and prohibit certain items to be sent to certain geographical regions (such as Nigeria) without explicit authorization.

Web services are increasingly being used for complicated business negotiations, transactions and even outsourced information processing. Already some Web services provide credit rating, credit scoring and loan application processing. Typically these are business-to-business applications that are used to enable consumer-facing Web servers operated by commercial banks.


Subject to Change
Alas, as companies use Web services for increasingly complex business transactions, they're going to be covered by negotiated legal agreements written in English. And, like all legal agreements, they'll be subject to change. That can mean problems for companies that want to rely on information exchanged over Web services. In other words, a credit score of 580 might mean something different in January than it did last July.

Is the fact that different Web services results can have differing interpretations a security issue? Probably not. But in all likelihood, that issue is going to be solved using the same mechanism as many security issues—that is, through the use of digital signatures.

For example, a Web services request would include the URL of the legal agreement under which the request is made, and perhaps a cryptographic hash or digital signature of that agreement, just so that the client and the server can both be in harmony as to which legal agreement is in force. Such issues will become even more important as companies begin to use the same Web services to offer different services to different partner organizations under different terms and conditions.

Of course, you can deploy completely useful Web services using only basic user name and password authentication, no encryption—and never have a single security problem. But if you are that reckless, be sure to keep it a secret.

Many SOAP (simple object access protocol) and XML security issues are being addressed by the World Wide Web Consortium's XML Signature and XML Encryption projects, and by the Organization for the Advancement of Structured Information Standards SOAP Message Security standard. Essentially, these standards provide for a uniform way of assigning time stamps to messages, to prevent replay attacks; of computing cryptographic hashes of SOAP messages, to protect their integrity; of digitally signing the messages, to establish their authorship; and of encrypting the messages, to prevent eavesdropping as the messages are sent over the Internet.

Observant readers will note that several of the goals of the standard—specifically encryption and digital signatures—are already provided by Web servers that require SSL encrypted client-side certificates. The advantage of creating a new signature standard for Web services is that SSL protects only the transmission—it doesn't actually protect the data. With XML signatures or SOAP Message Security, the digital signature remains as part of the SOAP message and can be verified again. You can find out more information about these standards at www.w3.org and www.oasis-open.org.

Of course, you can deploy completely useful Web services using only basic user name and password authentication, no encryption—and never have a single security problem. But if you are that reckless, be sure to keep it a secret.


Finally, a Plea
When a spate of mass-mailing computer worms and viruses hit this past August, my e-mail inbox was flooded. But my inbox wasn't filled with copies of a virus; it was filled with e-mail messages from antivirus systems all over the world telling me that I had sent them a virus, and that the message had been filtered.

My computer was never infected with a virus. Other people's computers were infected, but they were sending e-mail messages with faked "from" addresses. Years ago it made sense to send e-mail to people who were sending out virus-infected e-mail messages. But those days have long passed. Today the vast majority of worms and viruses fake the return address. Antivirus systems that send out notification e-mail messages merely compound the problem.

On one day I received more than 200 of these notification messages—messages that were supposed to be helpful. And I was one of the lucky ones; someone I know from the MIT Media Lab received more than 2,300 messages in one 24-hour period. If your company's antivirus system is set up to send these notification messages, please change the configuration. Otherwise, your antivirus system is just making the problem worse.


Simson Garfinkel, CISSP, is editor-at-large for CSO. He is the founder of Sandstorm Enterprises, a computer security tools company. Reach him at machineshop@cxo.com.

> Convergence Competition

Probably the worst and most over simplistic article about securing web services I have ever read !

Take a look at owasp.org's web services column.

I seriously think this kind of stuff is irresponsible !

Martin Johnson
Print