Be aware of SOA application security issues

Extensible Markup Language (XML), Web services, and service-oriented architecture (SOA) are the latest craze in the software development world. These buzzwords burn particularly bright in large enterprises with hundreds or thousands of systems that were developed independently. If these disparate systems can be made to work together using open standards, a tremendous amount of time, money, and frustration can be saved. Whether or not we are on the verge of a new era in software, the goal alone is enough to make security people cringe. It might be easy to glue System A and System B together, but will the combination be secure?

Today, most discussions about Web services security focus on standards: from WS-Security and SAMLdown to SOAP and even XML. While the standards are important, measuring the security of a Web service requires looking past the standards and considering all of the ways the system might fail. Attackers focus on a system's weak points, and a security assessment should do the same. Consider the following:

• Complex protocols might seem bloated or redundant. Skipping or changing steps might not create any problems for normal operation, but it could but jeopardize the security guarantees the protocol offers.
• Application platforms that support Web services are incredibly flexible. In practice, that means they have incredibly complex configurations. Mistakes in these configuration files become vulnerabilities in the service.
• Services are often built on top of legacy software that was not originally designed to operate as a service. Vulnerable code that's never been exposed to the network before offers attackers new opportunities.

· Eliminating problems like those is part of any comprehensive approach to SOA security. We'll take a look at an example of each and then talk about the business software assurance techniques you should use to prevent them.

· Most people know better than to make up their own cryptography, but a surprising number of programmers are still willing to try their hand at a home-brewed authentication protocol. Last month Google found out just what a bad idea that is. The single sign-on protocol they used for Google Applications was derived from SAML, but it left out a few seemingly unnecessary pieces of information from two protocol messages. The result was a severe security flaw that allowed a dishonest service provider to impersonate a user at another service provider. The moral to this story is if you adopt a standard, don't stop at "good enough." Subtle vulnerabilities creep in where standards compliance falls off.

· Web service containers such as WebSphere, WebLogic, or .NET WSE are amazingly versatile when it comes to Web services support, but what at first might seem a blessing quickly turns into a nightmare for the people who have to configure these systems. People stitch together configurations from sample projects or flail until somehow their service starts working. The result is service configurations that don't do exactly what the author intended. The example below shows an Apache Axis 2 Rampart client configuration that does not require inbound messages to be encrypted (since the tag does not contain an Encrypt directive).

·         

·         ...

·          

·           

·            Timestamp Signature

·            ...

·           

·          

·         

· When this configuration is buried in an enormous configuration file, the mistake is hard to catch. The result is a Web service that doesn't offer all of the security guarantees its author would.

But there are a tremendous constellation of security errors that aren't related to standards or to configuration. In fact, Web services don't introduce new types of security concerns as often as they provide new opportunities to make old mistakes. If a legacy system gets a brand new Web services interface, all sorts of problems that used to be buried deep in the system might now be able to find their way out. By exposing what used to be the internal workings of a program directly to the network, programmers may inadvertently bypass input validation or access control mechanisms, expose too much access to the internal workings of the program, or provide a new forum for making session management mistakes.

The situation is exacerbated by the fact that the security requirements for a Web service are at least somewhat ambiguous. Web services are supposed to be flexible so that they can be used by other programmers to assemble applications that the creator of the Web service may not have envisioned, but this makes it difficult for a Web service to understand the security needs of its callers. What sort of output validation should a Web service perform? If the Web service is intended to be used directly by a Web browser, then it should take precautions to prevent cross-site scripting (XSS). But if the author of a Web service doesn't know how it will be used, then it is hard to make the right security decisions.

Consider the code below. It's a method taken from DionySOA, a project that advertises itself as a Reseller/Broker service platform built using SOA and Web services. The method is exposed through a Web service. (You get a hint that it might be externally accessible when you see that it throws java.rmi.RemoteException. Knowing for sure requires looking at the application's configuration files.) The method contains a blatant SQL injection vulnerability. It takes its attacker-supplied parameter, concatenates it into a SQL query string, and executes the query. Although it is possible to make this kind of mistake without any help from Web services, we can't help but believe that the Web services setup made it easier to forget about input validation.

public supplier.model.SupplierProduct[ ]

searchName(java.lang.String in0) throws 

      java.rmi.RemoteException {

System.out.println("searchName("+in0+")");

    String query="SELECT * FROM products " +

               " WHERE name like '"+in0+"'  ";

  return this.doSQL(query);

}

Similarly, if a newly exposed method used to rely on another part of the application to perform access control checks, the Web services interface might now bypass those checks, making it easy to lose track of the trust boundary.

There's nothing fundamentally wrong with making it easy to create a Web service, but creating a good Web service is really not so easy. The Web services frameworks we are aware of do not give a programmer any guidance about the security implications that might be involved in exposing the insides of a program.

We don't mean for these examples to discourage the use of Web services, XML, and SOA frameworks, but rather to make users aware of the missteps that can occur when deploying these technologies. These examples will hopefully be a catalyst for taking security into account as part of the software development process. Business software assurance requires building security into every step, rather than trying to tack it on at the end. Just as quality assurance is the operational solution for managing product quality, business software assurance is the operational solution for managing software risk. The following activities should be part of any software project:

• Think like a bad guy. How would you attack this system? What would you hope to gain?
• Automated vulnerability detection -– source code analysis and dynamic security testing -– to identify vulnerabilities before the code is deployed.
• Real-time monitoring and active protection to defend the code once it's in production.

As companies become increasingly dependent on software to run the business, and as new technologies enable old applications to find fresh new uses, companies must make security a priority. A more proactive and systematic approach towards software security will be -- in the end -- less costly and more predictable than an ad-hoc security strategy.