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