Types of Security Attacks and Threats

In this section we briefly look at the types of security attacks and threats that are possible within a Web services environment. Since Web services leverage much of the infrastructure developed for Web sites, it is understandable that the types of security breaches that are common for Web sites will also be common for Web services. However, since Web services provide an application programming interface (API) for external agents to interact with it and also provides a description of this API (in the form of WSDL files), Web service environments facilitate and in fact attract attacks. These environments also make it more difficult to detect attacks from legitimate interactions.

Malicious Attacks

As we have discussed, Web service traffic shares a lot in common with Web site traffic. Both types of traffic usually flow through the same ports and while many firewalls can recognize SOAP traffic, they usually treat them as standard HTTP traffic.

Although Web site and Web service traffic may be treated in a similar fashion, the potential for security lapses is much greater with Web services. Web services expose critical application interfaces and operations and make them accessible through HTTP traffic. Each of these hundreds and thousands of operations represents a potential security problem.

Instead of hiding information about how to access and use each of these operations, Web services publish this information via WSDL files. Moreover, since the messaging format used by Web services is XML, each of the data fields are self-describing and highlight to hackers the means by which to interact with each service. One technique to lessen the security risks that may stem from exploiting the information on WSDL files is to simply not make WSDL files publically available. Instead of registering a Web service (and its WSDL description) with a public registry such as the Universal Business Registry (UBR) or having your SOAP server automatically generate WSDL descriptions for all (e.g., unauthenticated and unauthorized) users, for some Web services it may make sense to control the distribution of their WSDL descriptions.

Many malicious attacks are software-specific and the potential for attacks can be greatly reduced by simply eliminating any hints as to the type of software infrastructure that is used by a Web service. For instance, since an attack exploits a weakness or a "hole" in a particular piece of software, if an attacker knows that a Web service is run on a certain vendor's SOAP server, potential attacks may be facilitated. It is advisable to eliminate (or even disguise) information that identifies any part of the system infrastructure through headers, fault codes, and stack traces that are returned to client applications. It is also important to rename or even eliminate demo applications and other well-known locations within an infrastructure that may be exploited by attackers.

Although we have discussed security attacks within the context of malicious attacks, Web services also pave the path for accidental attacks. With accidental attacks, legitimate client applications access and interact with Web services, but do so in such a way as to cause harm. This may be a result of not fully understanding a Web service's API, or it may simply be a matter of negligence.

Whether the attack is malicious or accidental, they must be detected, contained, and prevented. Although Web service environments make a lot of information available for potential hackers, they also make a lot of information available for security systems. The interface information available as WSDL files together with SOAP message content and access patterns can be used to build more sophisticated firewalls that block and potentially deter would-be attackers.

Denial of Service Attacks

A denial-of-service (DoS) attack is an attack in which a user is deprived of a service that it normally expects to have available to it. A DoS attack can be as simple as maliciously disconnecting the power or network connection of a server, or it can involve more complex means such as overloading a service by repeatedly sending messages to it.

The most common type of DoS attack is a buffer overflow attack. In a buffer overflow attack, a client application sends data to a service that is longer than it can handle causing the service to go down or causing the service to execute code supplied by the client. Web services are particularly susceptible to buffer overflow attacks as they expose their APIs and a large amount of data is exchanged between them.

Today, many Web services are being created by simply wrapping legacy systems. Many of these systems were designed to be used within tightly controlled, closed environments and are not prepared for ill-formed or unusual requests or messages. Oftentimes, these vulnerabilities are exploited by hackers to transmit quotes, parentheses, and wildcard asterisks that confuse Web services. The lack of error checking and unpreparedness for uncontrolled environments make Web services-wrapped legacy systems ripe for buffer overflow attacks. The key here is to validate all data and ignore any requests containing data that do not pass the validation checks.

Sending extremely large XML documents to a Web service can also be considered a type of DoS attack. The parsing of either a very long or a very deep XML document by DOM-style XML parsers can result in an enormous memory footprint and significantly reduce the computational resources available to service requests. Designing your Web service to not accept arbitrary XML documents (as attachments) or placing size restrictions is one way to avoid incurring these XML-based DoS attacks.

Another common type of DoS attack is a replay attack. With these attacks, a valid message is repeatedly sent to a service. Since the service can only handle a set number of requests per unit time, the service's ability to handle legitimate requests is severely limited or stopped all together. Web services that are CPU-intensive to service a request are especially vulnerable to replay attacks. In these cases, it is critical to authenticate the requester before starting to process the request.

Web services provide more opportunities for replay attacks, and their heterogeneous functionalities and interfaces make it more difficult to distinguish a replay attack from legitimate interaction. On the other hand, Web service (SOAP) messages provide easier visibility into payloads and facilitate the development of monitoring and pattern detection tools that can prevent replay attack messages from reaching the actual service target.

Dictionary Attacks

A dictionary attack is an action in which a client takes advantage of weak passwords or other authentication mechanisms to gain access to a service. Web services use a variety of authentication schemes, including passwords to prevent unauthorized access. Unfortunately, just like personal passwords, many Web service passwords are weak and can easily be cracked. Hackers leverage these vulnerabilities to either programmatically or manually attempt common passwords to gain access.

Today, Web services employ a variety of different means for authentication. In some ways, this heterogeneous nature of Web service authentication presents obstacles for widespread automated dictionary attacks. On the other hand, as Web service security and authentication frameworks mature and standard mechanisms are used across different Web services, this difficulty will be lessened. Password hardening and strengthening rules must be employed to prevent dictionary attacks.

Internal Threats

Security threats and attacks are usually thought of as acts perpetrated by those outside of an organization. However, Web services expose a variety of information and functionality to large numbers of people, including those within the host organization. Moreover, Web service interfaces are well documented and the data is transmitted using XML, which is self-describing and human readable.

Employees or former employees with access to networks behind the enterprise firewall, to administrator passwords or with knowledge of system vulnerabilities can easily acquire confidential information or critical data. A particularly common example of internal attacks on Web services deals with Web service providers that use security but terminate the secure messaging channel at the entry-point of the organization. Once the secure channel is terminated, all data travels in the clear and is accessible by anyone on the local network. Credit card numbers, social security numbers, and maiden names are all available to employees with access to the local network. Since internal employees are most familiar with the systems and environment of their organization and because firewalls do nothing to protect attacks that originate from within the organization, internal threats are usually difficult to detect.

These are just a few of the most common threats and attacks on Web services environments. As Web service technologies mature and their use increases, hackers will come up with new and more innovative ways of comprising and attacking these environments.

Quickly detecting attacks within Web service environments also poses considerable challenges. Since Web service environments are heterogeneous and have decentralized administration, getting good administrative and log information is difficult. Properly cross-referencing the information that can be gathered from different systems also presents difficulties. For instance, each Web service system may follow different log formats, collect different types of data, and even present different timestamp information based on each system's clock settings. Clearly, bringing together the different pieces of the puzzle to recognize and identify an attack is difficult within Web services environments.

In this section, we have explored the various security issues and potential threats that can emerge within a Web services environment. We have also looked at how technologies such as SSL, XML Encryption, and XML Signatures can be used to address some of these issues. In the next section, we look at an extensible framework that builds on these and other security technologies and presents a coherent security model for Web service environments.