Dr Adam Kolowa (pictured), Founder & CEO of Parasoft and panelist at SYS-CON Events'  "SOA Web Services Power Panel" at SOA Web Services Edge Conference & Expo - June 5-6, 2006 - in New York City, writes:

Security has the inherent nature of spanning many different layers of a Web Services system. Web Services vulnerabilities can be present in the operating system, the network, the database, the Web server, the application server, the XML parser, the Web Services implementation stack, the application code, the XML firewall, the Web Service monitoring or management appliance, or just about any other component in your Web Services system.

Therefore security testing, which is important for any software application, is even more crucial for Web Services. This article explores security issues specific to Web Services and illustrates the engineering and testing best practices required to ensure Web Service security throughout the Web Services development life cycle.

Step 1: Determine a Suitable Web Services Security Architecture
Web Services security architecture not only depends on the required security measures, it also depends on the service scope and scale of deployment. For instance, security can either be enforced in the application server itself, or as a separate security appliance (such as an XML firewall) that can virtualize the service by sitting in the middle between the service and its consumers. Most Web Service architects recommend decoupling the security layer from the application server to achieve better maintainability, flexibility, and scalability. However, using a security appliance as an intermediary may not be necessary for simple end-to-end Web Service deployments.

Another architectural decision to make is whether to implement the security on the transport layer or on the message layer. TLS (Transport Layer Security) is a mature technology so both standards and tools have already been developed. It also provides a good transition path for engineers who are somewhat familiar with transport-level security but are new to Web Services. On the other hand, TLS has inherent limitations that make it inappropriate for some situations. Fortunately, message layer security provides an alternative solution for situations where TLS's limitations are troublesome.

Transport Layer Security
The security of the transport that's being used for the Web Service can be used to protect the Web Service. For example, for HTTP one can enable Basic Authentication, Digest Authentication, or SSL. When JMS API is used to transmit SOAP messages, then JMS Authentication can be used.

The main benefit of using TLS is that it builds on top of existing Web application experience to implement the security. Many developers know SSL and it's easy to enable it in common Web and application servers. SSL is a particularly ideal choice for end-to-end Web Service integrations. SSL can enforce confidentiality, integrity, authentication, and authorization, thus protecting the Web Service from capture and replay attacks, WSDL access, and scanning.

The drawback of SSL is that it's an all-or-nothing protocol. It doesn't have the granularity to secure certain parts of the message, nor can it use different certificates for different message parts. Besides, all intermediaries on the message path would have to have the proper certificates and keys to decrypt the entire message to process it then resend it over SSL again, which can be difficult or even impossible in some cases.

Message Layer Security
Currently, there's a lot of activity in the area of message level security and it's fair to say that it's not nearly as mature as TLS. With that disclaimer, here are the message layer security technologies that may become important because they address some of the same concerns as TLS (privacy, authentication, and message integrity) at the message level instead of the transport level:

• The XML Signature provides a mechanism for digitally signing XML documents or portions of XML documents. The signature doesn't have to be in the document that's being signed, so you can also use XML Signature to sign non-XML documents.
• XML Encryption provides a mechanism for encrypting portions of the XML documents. Encrypting a complete document is pretty easy; just treat it like a text document. There are some subtleties involved in encrypting portions of a document, however, these are what XML Encryption addresses.
• WS-Security is perhaps most easily understood as a specification that defines a standard way of securing a single message by applying Username Tokens, XML Signatures, and XML Encryption to a SOAP envelope. The Username Token profile provides a simple way to describe authentication data, i.e., usernames and passwords.

Step 2: Adhere to Technology Standards
As in other security fields, adherence to standards is a necessary practice for Web Services. There's a consensus among security professionals that publicly available, commonly used, well-analyzed cryptographic algorithms are the best choice, simply because they've already undergone a great deal of research and scrutiny since they were adopted by the industry. The same principle applies to Web Services security.

For example, compliance with the WS-Security specification from OASIS will likely be safer than developing your own custom security implementation because it's been developed by experts in the field with threat protection in mind. Furthermore, you can reduce development time by using a readily available implementation of the specification and your service would be able to interoperate with other implementations of the same standard.

Another issue to consider with regard to adherence to standards is compliance with the Basic Security Profile (BSP) from WS-I. The BSP is intended to address interoperability, but in some cases it restricts the W3C and OASIS specifications in a manner that favors stronger security practices. Moreover, section 13 or "Security Considerations" of the BSP lists a number of useful security considerations that should be taken into account when deploying secure Web Services using WS-Security.

Step 3: Establish an Effective Web Services Testing Process
Understanding security threats isn't enough. It's necessary to have a mature engineering process that makes security vulnerability detection and testing an indivisible part of the Web Services development process so the threats are mitigated to the maximum extent. Thinking about security as early as possible throughout the Web Service lifecycle is key to achieving the best results in the most efficient manner.

A common pitfall that companies encounter is their attempt to use the same human and technological resources of Web QA and testing for Web Services without implementing the proper training, processes, and technology changes that can leverage such resources successfully. The same resources used for Web QA and testing can't be used for Web Services for the following reasons:

• Web Services testing requires a different skill set in XML, SOAP, WSDLs, and other WS standards, let alone experience in security issues unique to Web Services
• Web Services testing can be better implemented with specialized tools rather than tools that are designed for traditional Web testing. The features of these tools need to support Web Services standards and have the ability to design tests along these standards.
• Web Services security testing requires the facilitation of tools and practices that can exercise the tests for exposing vulnerabilities that are general to Web applications and specific to Web Services alike.

Tier-One Testing: Static Analysis
Knowledge of unsafe coding practices is crucial when developing secure software, but detecting such practices can be a tedious, time-consuming process unless it's automated as much as possible.

Static analysis tools are proving to be very effective in exposing dangerous method calls, insufficient validations, or poor code quality. Although manual code inspections can expose some of these problems, such problems can be subtle and difficult to find manually. Static analysis doesn't eliminate the need for code inspections completely, but it can significantly reduce the time and effort required to do them since static analysis tools can scan the entire source code to identify unsafe coding patterns then the code reviewer can analyze these instances to verify their severity. Without such automation, much more time would be spent in finding the unsafe coding patterns in the first place.

For example, in Java using "PreparedStatement" is recommended over plain "Statement" to prevent SQL injections. A static analysis rule that searches for Statement.executeQuery() invoked with a dynamic string can pinpoint an engineer to this statement and provide a first line of defense against SQL injection problems. Other common insecure code patterns that can be found with static analysis include XPath Injections, uncaught exceptions that cause improper error handling, and some denial of service conditions caused by resource intensive operations.

Suspicious code patterns can also be identified with static analysis. Some security bugs result from programming negligence. However, more dangerous code can come from malicious programmers who hide Trojans, easter eggs, or time bombs in their code to provide discreet access at a later time. Such code often relies on random numbers or date/time checking to avoid detection, and it can change the normal security settings to allow surreptitious access. Static analysis rules that find all random objects and time date objects, called "triggers," that find custom class loaders and security managers, can help a code reviewer identify and inspect suspicious code pattern.

Besides detecting vulnerable or suspicious code, it's important to keep in mind that coding best practices play a role in producing secure code. There are also several different types of coding standards that can be enforced through static analysis that have general, rather than specific security relevance, and can improve the overall security posture of an application. For example, if code is found that has a synchronization problem, such a problem impacts security because synchronization problems tend to have unexpected effects. Indeed, coding practices should be considered during security testing.