| As the vast majority of Global 2000 organizations are transitioning pilot projects into production, the hype over XML Web services might finally be turning into reality. Web services usage has varied from simple data information sharing between two applications to corporate-wide, service-oriented architecture (SOA) initiatives.
There are many reasons why Web services are gaining traction, including ease-of-use, their loosely coupled nature, and effectiveness in application integration with the lowest cost and least effort required. Yet the use of Web services is not without challenges. Security continues to be a top concern, and with good reason, as Web services interfaces are different than Web site pages and cannot rely on the same mechanisms to protect them.
Security as Top Priority
Security has taken a priority role in organizations as the threat of breached assets and downtime is compounded with regulatory requirements, including HIPAA and Gramm-Leach Bliley. Chief security officers (CSO) are now commonplace and are charged with maintaining not only digital integrity, but physical security as well. As these C-level executives are pulled in two opposite directions, it is up to internal developers, QA staff, internal operations, and compliance officers to be aware of their company's security and auditing requirements.
With regards to XML security, Web services interfaces are generally much more complex, expose more functionality, and have a more sophisticated level of interactions than Web site pages. Though network firewalls do a good job of stopping network-level attacks, they do not provide the granularity or the proper rule sets to handle complex application attacks. Implementation of Secure Sockets Layer (SSL) and other existing technologies is useful but hinders value in scalability and interoperability costs.
The majority of early Web services projects have been conducted internally, behind the firewall, yet a common misconception is that communication hidden behind a firewall is safe from both internal and external attackers. While external attacks are better known, internal attacks can be just as costly, if not more so, than external attacks. Though it is unlikely that an internal employee will mount a distributed Denial of Service (DOS) attack to bring down systems, an employee with inside knowledge may break privacy rules or perform illegal transactions.
Security represents only a subset of problems related to the overall management of Web services. When breaking up the typical application paradigm into an SOA with loosely coupled endpoint applications, security, monitoring, interoperability, and reliability become important concerns. While security continues to be a prevalent and visible concern to end users, these other problem areas should be addressed, preferably by the same solution.
Malicious Attack Scenarios
This article will focus on security risks associated with malicious attacks on XML Web services. There are plenty of other security problems not associated with intentional attacks, including access control where security may be inadvertently breached. Many of the protections recommended will solve both problems.
Denial of Service
Protecting Web site technologies from standard DOS activities is well understood. Web service interfaces are much more heterogeneous and require more knowledge and granularity to protect. For instance, a Web service that provides simple information may be able to comfortably handle 1,000 requests per second; however, a loan approval application may only be able to handle at most 5 requests per second. Sending a loan approval interface 10 requests per second may constitute a DOS attack but be undetectable by normal means, such as firewalls. Collecting and understanding profile data on each service provides the necessary information to identify such attacks. Other forms of DOS can be achieved by sending overly large messages that clog up the system being attacked. Detecting and blocking invalid message sizes per interface can help prevent system downtime.
Similar to DOS, Replay attacks involve copying valid messages and repeatedly sending them to a service. Techniques similar to those for detecting and handling DOS can be applied to Replay attacks. In some ways, Replay attacks are easier to detect with Web services because payload information is more readily available. With the right tools, patterns can be detected more easily even if the same or similar payload is being sent across multiple mediums like HTTP, HTTPS, SMTP, or across different interfaces.
Message of application buffer overflow
With XML Web services, information about data parameters is exposed. In addition, much more data is likely to be sent between systems, creating the opportunity for Buffer Overflow attacks.
For example, an attacker can send a parameter that is longer than the program can handle, causing the service to crash or the system to execute undesired code supplied by the attacker. A typical method of attack is to send an overly long request, for instance, a password with many more characters than expected. Many legacy systems that will be Web service enabled are designed for controlled, well-behaving requests and may not be prepared to handle unusual requests.
Similar to Buffer Overflow attacks, hackers often send malformed content to produce a similar effect. Sending in strings such as quotes, open parentheses, and wild cards can often confuse a Web service interface.
Many systems have weak password protection, and Web service interfaces are no different. However, unlike portals, XML Web service interfaces are heterogeneous in nature, with each system having its own authentication system and methods for deterring undesired behavior. Dictionary attacks, where a hacker may either manually or programmatically attempt common passwords to gain entry into a system or multiple systems, are common. Administrators should ensure that passwords are difficult to guess and are changed often. Unlike standard user credentials, application credentials are determined by the administrator. Password-strengthening rules that are desirable for users should also apply to administrators of Web service interfaces. Some solutions offer a "lockout" feature once a certain number of failed attempts have been reached.
SQL Injection attacks involve adding special characters or terms to cause SQL statements to return unintended data. For example, strings that may end up in a WHERE clause of a SQL statement may be tricked into including more information. For instance, a parameter value of:
X' OR 1=1
may cause the whole table to be returned because 1=1 is always TRUE. Other types of SQL Injection attacks can enable an attacker to execute any SQL command.
Virus or malicious payload
One challenge with encryption is virus detection. Web service traffic may include attachments. When content is encrypted, viruses that may be a part of the message are also encrypted. This makes it difficult for a virus-checking program to detect malware. When using encrypted data, virus checking can be performed at the destination or by an intermediary that can decrypt the data to be virus scanned and reencrypted for transport.
These represent just a few well-known attacks common with XML Web services interfaces. Other attacks can involve "hijacking" the WSDL file or taking advantage of some XML-specific characteristics such as external entity attacks. Hackers, of course, are highly creative and come up with new ways of attacking so solutions must continue to innovate to keep pace.
Top 10 Requirements in Securing Web Services
While many current pilot projects have only a handful of security requirements, ensuring that these networks are secure as they grow in usage is essential to creating a cost-effective and secure environment down the road. There are a number of requirements that are essential to build into the system early in the development process to ensure that security is an enabler of secure communications rather than a hindrance to the project.
Authorization and access control.
Encryption via SSL, XML encryption, or dedicated lines.
Signature support, XML Signature.
Malicious attack protection for Web service interfaces, including content filtering. Consider third-party products that keep pace with new hacker innovations.
Automated exception-handling and threat-containment capabilities for quarantining bad messages and blacklisting attackers.
Auditing of every transaction and change to the system.
Schema validation for message well-formedness.
Hiding complexity and back-end internal resources through service virtualization or service views.
Building security in the abstraction layer versus at each endpoint. Analysts agree that building security at each endpoint results in higher costs. Developers should focus more on business logic than on application security.
Of course, existing standards such as LDAP, PKI, and SSL play an important role in securing Web services. To handle the special needs of security for Web services, numerous additional standards are being introduced, some of which are covered here.
Security Assertion Markup Language is being developed by the W3C and is a protocol for asserting authentication and authorization information. SAML-compliant servers can be accessed for authentication and authorization data in order to enable single sign-on.
The XML Key Management Specification is a protocol developed by the W3C that describes the distribution and registration of public keys.
Web services can access an XKMS-compliant server to receive updated key information for encryption and authentication.
XML Encryption is a protocol developed by the W3C that describes the encryption of digital content. The XML Encryption standard includes protocols for encrypting sections of XML documents. XML Encryption enables end-to-end encryption because the actual message is encrypted. Session-level encryption can only provide data privacy between two servers.
XML Signature is a protocol developed by the W3C that describes the signing of digital content. The XML Signature standard includes protocols for signing sections of XML documents. XML Signature enables capabilities such as message integrity.
WS-Security was originally developed by Microsoft and IBM and is now being shepherded by OASIS. WS-Security is used to provide core facilities for protecting the integrity and confidentiality of a message as well as mechanisms for associating security-related claims with the message. Currently, WS-Security describes how to attach signature, encryption, and security tokens to SOAP messages
XACML is a standard used to describe access rights policies and is being driven by OASIS. XACML represents authorization and entitlement information.
Liberty Alliance Project
The Liberty Alliance Project is an alliance formed to deliver and support a federated network identity solution for the Internet that enables single sign-on for consumers as well as business users in an open, federated way. The Liberty Alliance is led by Sun and other industry players.
.NET Passport is a Microsoft-based initiative that provides a suite of Web-based services that help make Internet and purchasing online easier and faster. .NET Passport provides users with single sign-in (SSI).
Security can be implemented in a cost-effective manner for XML Web services using a combination of the new technologies available as well as existing infrastructure. The use of WSM solutions enables a one-stop shop for security and other critical management and monitoring capabilities. Using these solutions, many organizations are already reaping the benefits of secure Web services today, cutting costs, increasing information sharing, and gaining a competitive advantage.
CIO Council XML Working Group: www.infoworld.com/article/03/09/01/34NNxml_1.html
Schafer, Scott Tyler. "XML Exposes Rich Network Data." InfoWorld.
Jabber Technology Overview: www.jabber.org/about/techover.html
Web Services Policy Framework (WS-Policy): http://xml.coverpages.org/ws-policyV11.pdf
This article was authored by Andrew Yang, Senior Director of Marketing of Westbridge Technology. If you would like a PDF version of this document, please contact firstname.lastname@example.org.