SOA Security: The Basics

In this article, we examine how security applies to Service Oriented Architecture (SOA). Before we discuss security for SOA, lets take a step back and examine what SOA is. SOA is an architectural approach which involves applications being exposed as "services". Originally, services in SOA were associated with a stack of technologies which included SOAP, WSDL, and UDDI. However, many grassroots developers then showed a preference for lightweight REST (Representational State Transfer) services as opposed to the more heavyweight SOAP messages, with the result that REST is now an accepted part of SOA. The rise of Web 2.0 has cemented RESTss place in the SOA world, since REST is widely used in Web 2.0. More recently, Cloud services such as Amazon's Simple Queuing Service (SQS) may be used alongside local services, to create a "hybrid" SOA environment. The result of all this is that SOA now encompasses the original SOAP/REST/UDDI stack, REST services, and the Cloud. From a security professionals point of view, all of it must be secured.

It is tempting to launch into a description of SOA Security without first asking "Why?" Why apply security to SOA? One obvious answer is to protect the SOA infrastructure against attack. This is a valid reason, but there are also enabling, positive reasons for applying security to SOA, such as the ability to monitor usage of services in a SOA. We begin by examining the attacks against SOA technologies, both SOAP and REST. Then we examine how standards such as WS-Security allow policies to be applied to SOA, thus allowing controlled usage and monitoring and finally examine the security ramifications when an enterprise integrates local on-site applications with cloud computing services.

Countering SOA Threats

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

In this article, we examine how security applies to Service Oriented Architecture (SOA). Before we discuss security for SOA, lets take a step back and examine what SOA is. SOA is an architectural approach which involves applications being exposed as "services". Originally, services in SOA were associated with a stack of technologies which included SOAP, WSDL, and UDDI. However, many grassroots developers then showed a preference for lightweight REST (Representational State Transfer) services as opposed to the more heavyweight SOAP messages, with the result that REST is now an accepted part of SOA. The rise of Web 2.0 has cemented RESTss place in the SOA world, since REST is widely used in Web 2.0. More recently, Cloud services such as Amazon's Simple Queuing Service (SQS) may be used alongside local services, to create a "hybrid" SOA environment. The result of all this is that SOA now encompasses the original SOAP/REST/UDDI stack, REST services, and the Cloud. From a security professionals point of view, all of it must be secured.

It is tempting to launch into a description of SOA Security without first asking "Why?" Why apply security to SOA? One obvious answer is to protect the SOA infrastructure against attack. This is a valid reason, but there are also enabling, positive reasons for applying security to SOA, such as the ability to monitor usage of services in a SOA. We begin by examining the attacks against SOA technologies, both SOAP and REST. Then we examine how standards such as WS-Security allow policies to be applied to SOA, thus allowing controlled usage and monitoring and finally examine the security ramifications when an enterprise integrates local on-site applications with cloud computing services.

Countering SOA Threats

What are the content-based threats affecting XML and REST services within an SOA? In the case of XML, there have been several publicized attacks such as XML Entity-Expansion, and SQL Injection.

SQL Injection

In a SOA, SQL Injection attacks involve the insertion of SQL fragments into XML data to return inappropriate data, or to produce an error which reveals database access information.

A successful SQL Injection attack in SOA has two prerequisites:

- Data received by a Service in the SOA is inserted directly into a SQL statement

- The SQL Statement is run with sufficient privileges to execute the attack.

To counter this attack, it is important to ensure that data received from untrusted users is not directly placed into SQL statements. This can be achieved by enforcing content-validation and threat-detection rules over incoming content.

Capture-replay attacks

Imagine this scenario: a service in an SOA is protected by a policy which ensures that service requests are digitally signed. This seems secure, but is it? The answer is that this system is vulnerable to a replay attack which simply replays a valid signed message, thus gaining unauthorized access.

The solution to this problem involves the usage of timestamps. The WS-Security standard includes support for timestamps, and WS-Policy can be used to mandate that a signed timestamp is present in incoming messages. A replayed message will therefore be detected based on its "stale" timestamp. The timestamp trust interval must be decided carefully. It must be short enough so that an attacker will not have time to capture, decrypt, and replay a valid message. But it must be long enough so that slight discrepancies between the system clocks of the Web Service and the Web Service requester do not result in valid messages being blocked. [Editor's note: For more on the critical role of system clocks, see Simson Garfinkel's Right on Time?]

Be careful not to confuse replay attacks with brute-force "flooding" Denial-of-Service (DoS) attacks. Although both involve a message being replayed, the DoS attack is designed to overwhelm and disable the target system, whereas the replay attack exploits a flaw in the target systems authentication scheme.

XML External Entity Attack

The "XML External Entity" attack which takes advantage of the fact that outside data can be embedded into an XML document via a DTD [Document Type Definition] entry. By specifying a local file, some XML engines could be made to access unauthorized information from the local file system. Note that SOAP is not allowed to use DTDs.

XPath Injection

It is likely that XPath Injection, which is analogous to SQL Injection, can be used to "harvest" information from an XML database. XPath injection can be blocked by ensuring that data passed into an XPath expression does not itself contain XPath.

XML Denial-of-Service (XDoS)

This attack exploits a feature of DTDs, namely the ability to pull in entities which are defined in a DTD. By pulling in entities recursively, an attacker can make an XML message which explodes in memory (hence the term "XML bomb") and causes a denial-of-service.

Harmful SOAP attachments

Just like email messages, SOAP messages may contain attachments. These attachments may be threatening if they are very large and difficult to process (e.g. a "clogging attack"), or if they harbor viruses. The solution is to ensure that SOAP attachments are either (a) blocked, (b) filtered based on MIME-type, or (c) passed through a virus scanner.

XML Signature dereference attacks

An XML Signature includes a "Reference" element pointing to the signed data. The parsing application must "dereference" (i.e. pull down) the reference URI. The XML Signature standard states that: "XML signature applications MUST be able to parse URI syntax. We RECOMMEND they be able to dereference URIs in the HTTP scheme." [RFC3075 - XML-Signature Syntax and Processing ]. However, this introduces a vulnerability, if the referenced data is bogus, or simply a way to waste recipient system resources pulling down a large file.

REST, Web 2.0 and SOA

Although SOA was originally associated with the triumvirate of SOAP, WSDL, and UDDI, many developers preferred to use more lightweight REST services which are closer to how browsers interact with Websites. The Web 2.0 movement contributed to this, because Rich Internet Applications (RIAs), make use of REST services to pull data from Web servers to the browser. The technology which enables Web 2.0 includes JavaScript on the browser side, for the most part calling REST Web Services at the server side. For example, the Flickr website includes JavaScript which runs in the browser which calls a server-side Web Service to rename a photo. In "AJAX" (Asynchronous JavaScript and XML), the client-side JavaScript calls back to Web Services on the server in order to pull down XML or JSON (JavaScript Object Notation) data. This happens asynchronously, without the user being required to browse to a new Web page (hence the A in AJAX is "Asynchronous").