A request authentication attack takes place when an attacker successfully poses as a legitimate client identity and gains access to the service. This type of attack entails an attacker masquerading as a legitimate identity through theft of a shared secret, username/password pair, PKI certificate, or other identity credential. A simple technique for attacking this way is the dictionary attack where an attacker uses a large number of common words as username/password pairs to gain entry. More generally, brute force attacks can apply not only to username password pairs, but also to any type of credentials.

Conversely, a response authentication attack occurs when a malicious party poses as the service itself, fooling a client into making requests to it directly. One specific type of response authentication attack is known as IP Spoofing.

Authorization attacks are made by someone with valid, authenticated credentials, who somehow gains access to systems that they shouldn't by subverting the access control scheme. Like the two authentication attacks above, authorization attacks typically result in data theft or privacy invasions.

Eavesdropping is one of the simplest techniques for data theft: an unauthorized party listens to conversations between systems and collects their data. Eavesdropping could be done simply to get access to data like credit card account information, or it could be used to hijack identity credentials and start an authentication attack as described above.

Eavesdropping enables both data integrity attacks and replay attacks. Using data obtained by eavesdropping with slight modifications (recall that XML is a text-based, human-readable format) before sending it on its way is known as a data integrity attack. The most basic version is a simple message forgery. Replay attacks occur when a hacker uses stolen messages and continually replays that same message at potentially high rates. Obviously that type of attack could have serious repercussions like server overload.

SQL Injection is the practice of inserting malicious SQL statements into XML in order to disrupt back end systems. New Web services development tools make it very easy for developers, who are generally untrained in security and often enthusiastic over these capabilities, to expose more functionality than is often necessary or prudent. If a Web service that connects to a database doesn't validate SQL, an incoming XML message containing rogue SQL statements could be used to break out of the expected database query and be used to obtain unauthorized information or even destroy data. For example, instead of a legitimate query using an order number to request a shipper's tracking number, the XML message could contain an escape code and a malicious SQL comment to extract all information from the database. An enterprise might think they've got a safe order tracking system, when it's really an invitation to disaster.

But the risks aren't limited to SQL statements and databases: SQL Injection is an example of a broader class of attacks known as Command Injection Attacks. Like using malicious SQL to attack databases, hackers might try to tunnel UNIX commands inside XML in order to exploit other vulnerable systems - any system that has a command-oriented interface.

Buffer overflow attacks have received a great deal of attention outside of XML and Web services (e.g. the Microsoft Office exploit detailed at http://news.com.com/2100-1009-5070929.html). Like SQL injection and command injection, a buffer overflow attack is aimed at the service endpoint and preys on vulnerabilities there - like not setting aside enough memory to deal with a large variety of inputs. Consider a Web service that's designed to take in a list of phone numbers - one way to test the security of the system would be to send in an XML message with a list of a thousand phone numbers - or just one phone number that's a million digits long. Services that aren't designed defensively enough may have problems with this type of input.

The best known example of this class of attack is the Denial of Service Attack. At the most basic level, denial of service means doing something to consume available resources (e.g. memory, network connections, disk space, CPU cycles, etc.) without doing useful work. The result is that a system spends time doing work on a few useless messages and is unable to service legitimate requests.

Denials of Service have been very difficult to combat at every level of the network stack: they're hard to distinguish from legitimate traffic, and it's tricky to selectively service only legitimate requests. XML Denial of Service (XDoS) attacks have similarly thorny issues. Simple tracking of basic metrics will miss real attacks and potentially block legitimate traffic. The art of defending against XDoS is to detect an attack based on the combinations of metrics that signify an attack - not any one metric looked at in isolation.

One of the first XDoS attacks was the so-called entity expansion attack, in which unprivileged local or remote users could use completely "correct" entity declarations in an XML message to wreak havoc upon unprotected XML 1.0 standard compliant parsers. When a vulnerable parser encountered such a message, recursive entity declarations caused the parser to shut down with an out-of-memory error, or use an inordinate amount of processor cycles. Within the past two years, many XML parser implementations have been modified to address these specific security concerns, but as the Code Red epidemic demonstrated so clearly, systems often remain susceptible long after the availability of patches.

Because Web services are used in conjunction with one another and are often developed by different people, teams or even companies, there is an interesting new type of attack: inadvertent denial of service. All it could take to bring your service down is a programmer on the other end mistakenly sending 100 requests per second instead of 10. Or doing something as simple as inadvertently coding an infinite loop.

Transport encryption provides confidentiality and integrity for messages while they're traveling over the network (but not when they're static at their source or destination).

Strong authentication via bilateral certificate exchange (i.e. 2-way SSL) provides a cryptographically secure way to verify sender and recipient identity.

The use of unique identifiers in SSL provides a built-in mechanism to guard against replay attacks by only allowing a message to be sent once.

XML-Encryption provides persistent, full or partial message encryption, and insures confidentiality both when messages are in transport as well as when they're static and not moving at all.

XML-Digital Signatures are a mechanism that allows a sender to cryptographically sign messages or parts of messages. Those signatures can then be used as authentication credentials or as checks on data integrity.

XML-Schema is a way to describe what the contents of an XML message should be and a way to guard against some content-borne attacks like buffer overflow attempts.

WS-Security is a broad umbrella of standards designed to combine several new standards in an interoperable way to secure SOAP messages. WS-Security includes both those above and others such as WS-Trust, a specification for sharing identity and trust information between organizations. Most of these specifications are relatively early, and are just now beginning to gain broad industry support.

Brute force authentication attack detection. As mentioned above, repeated failures in authentication attempts can indicate that a dictionary attack or more general brute force attack is underway. Being able to detect simple dictionary attacks as well as the more complex general case is critical; that is, based on classes of credentials, including SAML assertions, XML signature, LDAP queries, and SSL certificates.

Content filters. As mentioned above, XML-Schema provides a variety of useful content-oriented function to help insure that the content of the data is really what you're expecting. Unfortunately, it's often impractical to define an XML-Schema so completely that it will guard against all content attacks and XML Viruses. For example, while it's possible to specify that no SQL should be allowed inside any message, it's not reasonable to guarantee that all the schemas in your organization do that. A much easier way is to use content filters: ways of describing content that should never be allowed to tunnel through. One typical way to implement a content filter is to use regular expressions specified across all messages, and to define these regular expressions against all known content-borne attacks.

Advanced XDoS Defense. As mentioned above, Denial of Service attacks are attacks designed to consume inordinate amounts of system resources such as memory, network connections, disk space, or CPU cycles. With Denial of Service, the trick is detection: seeing patterns and determining if it's really an attack or if the system is experiencing legitimate load conditions. In order to do that detection, a number XDoS metrics come into play: the overall message request rate, the number of authentication failures in a given time period, instantaneous and average CPU usage, and the amount of memory that all messages currently in transit are consuming. For each of these factors, good metrics and configurable thresholds are essential. Often a single factor (such as high message rate) might indicate a threat; other times it might be the combination of two or more factors that indicates real issues.

Deny by default. The first and most important action isn't a positive action, but more of an attitude. With Web services, since they're exposing your business' most sensitive assets, you want to apply the tightest security filters possible. So if your systems ever see a message where something doesn't look right - the authentication, the body, the timing, anything - the first reaction should be to deny that message and raise an alert.

Human and automated alerting. Ideally when something out of the ordinary is happening to your Web services, you'd like an automated way of knowing whether it's an attack or not. In practice, the only real way to monitor is through a combination of automated and human monitoring. So any countermeasure solution should enable human alerting via e-mail and paging as well as automated alerting using technologies like SNMP, syslog, and integration with Intrusion Detection Systems.

Identity blocking. Once you've identified that an attack is happening and alerted either human or automated systems, the first line of defense is to block that identity from doing any harm. An identity may be something as complex as a specific certificate holder, or as simple as an IP address (or range of addresses). Automatically blocking offending identities for some period of time (and possibly indefinitely) is a key defense mechanism.

Server load management and request throttling. Understanding both front-end (Internet facing) and back-end (server facing) issues is important, and protecting the Web services server is just as critical as detecting malicious attacks. Since real world message traffic is stochastic in nature, simply limiting the size and rate of messages to the back end server is insufficient. Good security systems throttle combine factors of message sizes, back-end server latency, and transport-level error codes to maintain a model of back-end server load, which provides a means of predicting message load a back-end server is capable of handling.

Always log. It's a trite thing to say, but one of the most important pieces of a defense framework is to always collect the information that you need: about normal traffic patterns, about failed attacks, and about successful attacks. You certainly won't need everything you collect all the time, but the existence of the data when you need it, along with tools that enable both you and your partners to collaboratively diagnose issues, is critical.