SOA Security: The Basics

Mark O’Neill is CTO at Vordel and author of the book Web Services Security

.

In this article, we examine how security applies to Service Oriented Architecture (SOA). Before we discuss security for SOA, let’s 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 professional’s 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“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.

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:

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”).

In the Web 2.0 world, it is the back-end Web Services which become a key point of attack. This is sometimes termed the “large attack surface” of Web 2.0. An attacker can try to attack an application through its client interface, or they can simply bypass the interface and simply go straight after the back-end Web Services instead.

Wait: Is this a solved problem?Cross-site scripting (CSS) is a possibility if an attacker is able to insert JavaScript into the data sent down to the browser to be rendered. Since many Web 2.0 “mash-up” scenarios depend on JavaScript being served down to the client, the possibility of malicious JavaScript slipping through occurs. This must also be detected and blocked.

At this point, some readers may be thinking “this is not all that different from traditional Web applications, so why is it secured differently?” After all, in Web 2.0, Web browsers are used, Web Servers are used, and a user is involved. Indeed, when data is being sent between a Web Browser and a Web Server, it does make sense to scan the data for evidence of attempts to perform attacks like SQL Injection or cross-site scripting. Also, when XML is on the network, it does make sense to scan it for attacks such as XML Denial of Service or XPath Injection. In addition, secure coding practices still apply here. Rich applications on browsers present enhanced secure coding responsibilities.

“Freemium” and the risk of data harvesting

So-called “Freemium” Web Services involves basic services being offered for free, while charging a premium for advanced or special features. The word “freemium” itself is a portmanteau which combines the two aspects of the business model: free and premium.

Allowing some services in a SOA to operate in the freemium model is compelling, since it offers a path to a paying commercial model. However, the practicality is more complex. The model presupposes a SOA security framework which detects overuse and enforces payment for premium service usage. Usage must be authenticated so that the over-use of the service by a particular user is detected, and results in the user being asked to pay the premium fee. Usually this is achieved using so-called “developer tokens”. These are tokens which are embedded into the Web Service invocations sent up to the service which is being offered. So, for example, a user can use a search service up to a certain point, but they cannot data-mine search terms without being detected, and then required to pay the premium fee.

When implementing the freemium model for services in a SOA, an organization has the choice of writing custom code to implement it, or to use an off-the-shelf product such as an XML Gateway. An XML Gateway provides advantages by allowing changes to be made to the parameters in the model without a requirement to change actual code. The XML Gateway also scans for the attacks which we have discussed earlier, such as malicious code injection.

Identity and Standards

It is important to know who is using the services of a SOA, and to use this information to control access and to maintain information within an audit trail. The task of controlling access to the services makes use of a variety of standards, some established such as X.509 certificates, and some new such as SAML and WS-Security. It is important not to be blindsided by the standards, especially when they are composed together in a complex manner.

The old and the new: Passwords, X.509 Certificates, and WS-Security

Passwords have been around since time immemorial. They are still widely used within SOA Security. In many cases, it is simply a case of HTTP Authentication, sent over SSL so that the password is not sent in the clear. Indeed, even if Digest Authentication is used, where the password is not sent in the clear, SSL should still be used in order to block certain capture-replay attacks. Even though HTTP Authentication over SSL is “old” technology, it still is widely used for point-to-point authentication within an SOA.

X.509 certificates are used in the context of SSL authentication, where a Web Service can prove its identity to a client, or, in the case of two-way SSL, the client also proves its identity to the service. In this case “identity” is amorphous, since Web Services interactions often involve applications talking to applications, without a human being involved. So the “identity” is the identity of an application. And, as is the case in all usage of X.509 certificates, the trust is based on the issuer of the X.509 certificate (a Certificate Authority, often abbreviated to “CA”).

As well as SSL, X.509 certificates are often used in the context of digital signatures. XML Signature is a standard which defines how XML data can be digitally signed using the private key which corresponds to an X.509 certificate, so that anyone who holds the signatorys X.509 Certificate can validate the signature.

XML Encryption is a standard which, as you may guess, defines how XML data may be encrypted. You may ask “what is different about encrypting XML data, versus encrypting any other kind of data?” The answer is that XML data can be selectively encrypted, allowing for scenarios such as selectively encrypting a patient name in a medical record. Since the messages in an SOA are mostly XML (with the exception of REST and JSON for Web 2.0 services), XML Encryption is very useful in order to apply privacy rules.

Kerberos is also a mature technology, which continues to be used within SOA Security. In particular, Kerberos is often used in a Windows environment, since it continues to underpin authentication and single sign-on in Windows networking.

All of these pre-existing security technologies continue to be used for SOA security.

WS-Security

WS-Security is a newer technology which was standardized in 2004. It builds on what has come before. It defines how XML Encryption and XML Signature apply to SOAP, so that a SOAP message may be encrypted and/or signed. Additionally, it defines where passwords and X.509 Certificates are placed in a SOAP message, and how SOAP may operate with Kerberos. This allows for interoperability between different applications which use WS-Security.

Platforms such as Suns Glassfish and Microsofts .NET incorporate WS-Security. These allow processing of signed XML (using XML Signature with WS-Security), authentication (using passwords, Kerberos, or certificates), and encryption (XML Encryption with WS-Security). XML Gateways

XML gateways provide security for SOA by providing security processing on the network, using hardware acceleration. The XML gateway applies security policies to the services in the SOA which it protects. It presents “virtual services” which sit in front of the actual Web Services themselves. These virtual services are accelerated, and may include transformation which occurs before the actual SOA services are called. For example, an XML gateway may present a REST interface in front of an actual SOAP Web Service. In this way, XML gateways often provide protocol mediation, transformation, and acceleration as well as security.

The future of SOA Security—to the Cloud

Once defined only in terms of internal application-to-application networking, SOA is now finding links with cloud computing. In many ways, the services offered by Amazon, Force.com, and Google are like a “global SOA”. They provide many Web Services, generally accessed by REST and AJAX interfaces, which may be incorporated into applications.

The predominant approach is the “hybrid model”, whereby services in a local SOA are augmented by services in “the Cloud”. For example, a local application may already pull sales data from a database and then put it onto a TIBCO Rendezvous queue. However, it can be augmented by calling out to a Force.com service [Force.com is Salesforce.coms cloud service]. The data retrieved from Force.com may then be used to “enrich” the data before it is put onto the Rendezvous queue. Another example would be if a local application uses Amazons S3 Cloud service for storage.

In the hybrid model which links a local SOA with the cloud, it is important to ensure that no private data is sent up to the cloud. This can be achieved by selectively encrypting the data as it goes to the cloud service. Additionally, it is important that a network outage, or a failure of the Cloud service, does not unduly impact local applications. This can be achieved by using an XML gateway as a local “Cloud Broker” which controls the connection to the cloud from the local SOA.

Cloud services promise to add to the current usage of SOA, joining local SOAP and REST Web Services.

Mark O’Neill is CTO at Vordel, the XML network management company. He is also author of the book Web Services Security

and contributing author to Hardening Network Security

from McGraw-Hill/Osborne Media. O’Neill is responsible for overseeing Vordel’s product development roadmap and also advises Global 2000 firms and governments worldwide on their tactical and strategic adoption of XML, Web Services and SOA technologies. He holds a degree in mathematics and psychology from Trinity College and graduate qualifications in neural network programming from Oxford University.