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.