How to Secure Web Services

The next new (vulnerable) thing

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 longersay, 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 networkor by programming in Java, a language that doesn't have buffer overflows. Talking PointsSQL-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.