Web Services Security: Beauty and the Beast

Lately, corporate interest in Web services has been rising — and justifiably so. The advent of this new way of building applications promises to almost magically allow organizations to exchange information within their own systems with partners and customers.

While the potential benefits are noteworthy, these capabilities raise new security issues for many enterprises. “Web services punch holes in traditional security techniques,” Jason Bloomberg, a senior analyst with market research firm ZapThink, told the E-Commerce Times.

The holes stem from differences in application design. Traditionally, applications were built in a linear fashion, and information moved in a set, sequential manner. Most security products were designed to examine information at various points. For instance, firewalls were stationed at the network outskirts to provide a place to ensure that only authorized individuals entered enterprise networks.

With Web services, data comes from many different entry and exit points. As a result, many applications skirt the different checkpoints. For example, HTTP (Hypertext Transfer Protocol) data is often routed via a network device’s port 80, which bypasses the checks completed by a firewall. As a result, hackers can use that entry point to bypass security measures and gain access to a company’s network.

Girding for New Types of Attacks

Because of the differences in application design, new types of attacks are possible with Web services, for example malicious code injection attacks can occur. There are a variety of these attacks, but they all work with the same principle: A hacker piggybacks malicious code onto good code through an input field in the application.

This hacking option has been popular with database management system applications relying on the Structured Query Language (SQL). In addition, XML (Extensible Markup Language) and LDAP (Lightweight Directory Access Protocol), which are both commonly used with Web services applications, can be susceptible to malicious code injections. For example if an e-commerce XML application fails to validate the destination of information it sends, a hacker could obtain sensitive customer details, such as an account number or credit card information. With an LDAP malicious code injection, an attacker could access a corporate directory and gain access to customer contact information, such as e-mail and personal addresses.

To guard against such attacks, companies have to station their security features within an application itself rather than at the network level, but most security tools were not designed in this manner. In fact, companies often gain a false sense of security and mistakenly think that they are safe from malicious code injection attacks if their applications run Secure Sockets Layer (SSL) encryption. SSL encryption does prevent outsiders from intercepting data as it moves between two points, but it does not look for or offer any protection from malicious code injection attacks.

Preparing the New Suite

As Web services applications began to be developed, vendors tried to outline ways to secure information at the application level. “Vendors have developed a broad suite of standards to protect Web services transactions,” said Randy Heffner, an analyst with Forrester Research.

The suite, dubbed “Web Services Security (WSS) framework,” has been developed in two stages, with the first focused on protecting Simple Object Access Protocol (SOAP) transmissions, the most common type of Web services protocol. These messages are most often transported over HTTP, but can, in principle, be carried over any underlying protocol. In its first iteration, the WSS framework enables companies to encrypt, sign and authenticate SOAP messages.

Many organizations have implemented this level of security. “Just about all application development products and tools that have shipped in the last few years support WSS,” said Anne Thomas Manes, vice president and research director at the Burton Group.

Who’s on the Other End?

Even when a company takes these steps, there is a possible security hole. “The reality is companies need a way to make sure that they know who is on the other side of any Web services transaction,” Heffner told the E-Commerce Times.

A number of initiatives have been undertaken to make that understanding possible. The Liberty Alliance has been working on its federated identity, where trusted peers vouch for the safety of the originating client as long as they have the same type of security token. OASIS (Organization for the Advancement of Structured Information Standards) has been developing WS-Federation, which is geared to supporting transactions based on different types of tokens.

The move to support federated services is in a fledgling stage with standards taking shape and being incorporated into various products. Even though Web services security has that hole, companies have forged ahead with deployments. “About sixty percent of corporations have implemented Web services,” said ZapThink’s Bloomberg.

Weighing Risks vs. Rewards

About one third of these organizations are exchanging information with third parties: customers, partners or suppliers. “Companies have been willing to take on the risk because they feel relatively certain that the other side of the connection has been secured,” noted Heffner.

In addition, hackers probably are not targeting Web services applications at the moment. “Although it has gained significant momentum recently, the volume of Web services applications deployed in corporations is still relatively small,” Manes told the E-Commerce Times. Hackers tend to focus on the biggest bang for the buck, so most are now focused on exploiting holes in popular products, such as Microsoft’s Windows operating system.

While Web service security is not perfect, it has proven to be strong enough so many organizations have felt comfortable enough to deploy these applications.