The emergence of Web services introduced a new paradigm for enabling the exchange of information across the Internet
using open industry standards and standards-based technologies. Adoption of a Web services architecture and adherence to its standards facilitates the building of a service-oriented architecture (SOA) and on-demand applications that can be discovered, subscribed and consumed over the Internet. The clients invoking these services do not need to be aware of their target service provider system environment and its underlying implementation model.
Due to their flexibility of using platform-neutral standards, such as XML and adopting Internet-based protocols, the clients expose application components such as services and make them accessible by any application, platform or device -- and at any location.
Enabling XML Web services also allows interoperability among applications developed using a heterogeneous environment such as Java EE, Microsoft .NET, CORBA and C++. With the overwhelming adoption, acceptance and availability of Web services application infrastructure tools, increasingly Web services are used to enable inter-enterprise communication, workflow, collaboration and integration of business applications over a network.
Applying security and establishing trust among Web services or between a Web service provider and its consumer has introduced newer challenges, some of which remain unaddressed by traditional security mechanisms and technologies.
Because Web services can be dynamically located, subscribed to and consumed using a wide range of platforms -- including handheld devices -- the Web services provider must facilitate a standardized security mechanism that can be accessed by the service requesters using heterogeneous platforms and devices.
For example, customers viewing stock quotes via Web services should not be constrained or impacted by whether they use a Web browser client, a browser-capable device or a stand-alone application as long as the service requester client on which customers view their stock quotes uses an industry-standard message transport and message format and apply relevant security mechanisms with the Web service provider.
When using Web services for multi-partner business process workflow, message-level access control must be enforced, requiring only selected portions of the message be viewed or modified based on participant privileges. For example, in a healthcare workflow scenario that involves multiple participants, such as physicians, lab specialists, pharmacists and insurance providers, it is critical to establish access control and privacy of medical records to meet regulatory compliance requirements. The core problem is that each workflow participant may require access to only a selected portion of the medical record so that the confidentiality and integrity of the patient's health record is not compromised by unintended recipients.
As you can see, it's critical to ensure that exposed Web services–based business transactions and processes are secure, reliable and available to the service consumers.
Known threats and vulnerabilities
As Web services have evolved, they have offered some compelling benefits over other Web-based applications. However, these advantages come with known security threats and risks. These risks involve threats to the entire host network, including Web services providers, consumers, intermediaries, data, users, applications and systems infrastructure. While developing Web services architecture, it is important to proactively investigate and pinpoint these known security loopholes. Let's take a look at those known threats, vulnerabilities and risk factors that will influence how you secure a Web services architecture and implementation.
Denial of Service (DoS)/XML Denial of Service (XML-DoS)
Denial of Service (DoS) attacks are attempts by an unauthorized user or a hacker to disrupt a Web services provider and its exposed services by flooding them with useless traffic that consumes host system resources such as CPU, memory and network bandwidth. These are fake service requests that are designed to take a long time to process XML messages, to generate faults or to prevent authorized users from accessing the service. DoS attacks result in significant losses due to outage of provider resources and exposed services. These attacks usually exploit the weaknesses in the application architecture and the host systems' infrastructure.
XML Web services were designed to use standard TCP/IP ports for XML traffic, port 80 for HTTP, and port 443 for SSL. Traditional firewalls are ineffective for inspecting XML traffic because they do not provide support for detecting content-level threats. XML-DoS attacks are typical to content-level vulnerabilities where an attacker makes use of malicious XML messages, manipulates parts of an XML document, or sends an oversized XML payload that can cause load-intensive operations at the target Web services endpoint. This causes those systems to crash or to consume an excessive amount of system resources, both of which result in the inability to respond to further requests or perform operations.
A man-in-the-middle (MITM) attack is an attack where the hacker acts as a Web service intermediary that intercepts the communication and then accesses and modifies the messages between two communicating parties without the communicating parties knowing that the messages have been intercepted.
Message injection and manipulation
Message injection and manipulation is an attack on message integrity between a Web service provider and the consumer. This is carried out by hackers who insert, modify or delete parts of messages or attachments, which can push an XML parser into endless loops or transaction commit failures. The attacker also makes use of recursive elements or XML expressions (based on XPATH or XQUERY) or unrelated message attachments to perform unintended processing functions that lead to an endpoint failure. This attack usually comes after a MITM attack where the intruding intermediary generates forged service requests or sends forged server responses.
Session hijacking and theft
Some Web services providers rely on session identifiers during communication to identify service requesters. This usually leads to a potential security hole where a hacker can steal and use the session identifier information to hijack a session between the services provider and the consumer. In this attack, the hijacker sniffs the conversation or uses packet-capturing capabilities to obtain the session information from the communicating client peer. Based on the session identifier, the hijacker constructs forged service requests that affect the operational efficiency of a Web services provider or a requester.
Identity spoofing is an attack where a hacker uses the identity of a trusted service requester and sabotages the security of the services provider using forged service requests with malicious information. In this case, the services provider finds status normal and no security breach in the system. From a business perspective, spoofing can cause significant losses due to false identity claims, refunds and related issues.
The threat to message confidentiality comes from eavesdroppers or after an intrusion attack by unauthorized entities. It is important to use appropriate mechanisms to protect message confidentiality throughout the life cycle of Web services operations, including messages in transit or in storage. If these mechanisms are not used, messages will be available for viewing and can be intercepted by unintended recipients and intermediaries.
A message replay attack is a form of DoS attack where an intruder forges a service request that has been previously sent to the service provider. In this case, the intruder fraudulently duplicates a previously sent request and repeatedly sends it to get the target Web services endpoint to generate faults that can cause failure and shutdown of and the target's operations. Hackers usually use this attack as a first step in accessing the services provider in order to generate a fake session or to obtain critical information required for accessing services.
Message validation abuses
Most Web services security functions rely on XML–schema-based message validation for XML encryption/decryption, XML Signature validation and security token verification. These tasks generally require resource-intensive XML processing. Hackers abuse message validation mechanisms by sending malformed messages or an abnormal payload of encrypted content or non-compliant messages that can cause endless loops that compromise service performance and contribute to transaction failures.
XML schema tampering
In a Web services scenario, XML schemas play a vital role in defining XML vocabularies in an XML message. They help verify that an XML message is well-formed and valid. XML schemas are vulnerable to attack because they are usually publicly accessible. Using that as a potential loophole, the attacker alters the externally referenced XML schemas with erroneous and inconsistent information. This affects the Web services endpoint with processing overheads and failures related to message validation and verification.
WSDL and UDDI attacks
Web Services Description Language (WSDL) descriptions and public Universal Description Discovery Integration (UDDI) registries provide most service-related information in a self-describing XML format that reveals the service location and its exposed operations. The attacker makes use of publicly accessible UDDI or WSDL information to identify the service provider location and then performs a number of operations with arbitrary input and output parameters using malformed data. The attacker may also inflict changes by tampering with WSDL descriptions that affect the creation of client-side artifacts to support service requesters.
The complexity of these known security threats and vulnerabilities makes tasks such as user authentication, access control rules and policies, non-repudiation, identity management and service provisioning more difficult. It is essential to address these known security challenges so that they do not interfere with the promised benefits of Web services adoption.
Core security requirements
The key factors contributing to the above security challenges must be mitigated with appropriate countermeasures in the Web services architecture as core security requirements. This provides the ability to deliver a secure execution environment for conducting business transactions, processes and collaboration. In addition, it is important for Web services security to build on existing application security infrastructures and to integrate with them. Let's take a look at those key requirements and their roles in designing a Web services architecture.
Authentication enforces the verification and validation of the identities and credentials exchanged between the Web services provider and the consumer. The initiating service requester must be authenticated to prove its identity with reliable credentials. The credentials may be username/passwords, X.509 digital certificates, Kerberos tickets, biometric samples or any security token that can be used to validate the identity of the service requester.
Depending on the security requirements, you also need to deploy mutual authentication mechanisms where both the service requester and the service provider exchange their credentials and validate them before initiating the communication. Using authentication mechanisms alleviates and mitigates the risks associated with man-in-the-middle attacks, identity spoofing, and message replay attacks.
Authorization and entitlement
After authentication, it's essential to control and monitor access to the service provider resources. Authorization defines the rules and policies associated with the required access control to the resources. Upon successful authentication, a service requester requiring access to business services should be provided with specific access rights, and they should be granted or denied as appropriate.
Auditing and tracing
Auditing and tracing allow the monitoring and recording of relevant life cycle events and transactions taken by the services provider based on the requests made by the consumer. Auditing and tracing ensure that the initiating clients are accountable for their requested operations and provide authentic proof of the originating request or response. The audit trail provides information that can be used to monitor resources, system break-ins, failed logins and breach attempts.
Integrity of the data plays a vital role in ensuring that messages exchanged between the communicating parties are accurate, complete and not modified or altered during transit or while in storage. The use of digital signature mechanisms ensures data integrity by securing Web services-based business transactions from modification. Ensuring data integrity protects Web services communication across endpoints and intermediaries from MITM intrusions and interference that may damage data.
Data privacy and confidentiality assure that the actual data transmitted are protected from the prying eyes of unintended recipients. Data privacy and confidentiality are made possible through cryptographic algorithms that convert the data to an encrypted form of message that unauthorized viewers aren't able to understand.
Non-repudiation ensures that the communicating parties accept a committed transaction. This prevents the service requesters from wrongfully claiming that the transaction never occurred. Ensuring non-repudiation can be done using many approaches, such as enabling logging and recording trails of the transaction exchanged, using timestamps on message requests and responses and using digital signatures to ensure that credentials of communicating parties are authentic.
Availability and service continuity
Availability and service continuity are mandatory requirements to ensure the Web services infrastructure is capable of sustaining operations after a security breach or failure. These requirements can be achieved by introducing high-availability mechanisms such as load balancing, fault-tolerance and failover protection. From a security standpoint, implementing high-availability mechanisms guarantees service continuity after failures.
Single sign-on and single log-out
Single sign-on (SSO) plays a vital role in Web services environments, allowing heterogeneous applications communicate with each other using standards-based technologies. That means it becomes mandatory to facilitate a universal logon and logout mechanism that allows access to multiple applications running on different platforms and domains. In a Web services aggregation scenario, it also becomes important to facilitate global sign-on that allows access to multiple Web services providers. That means all participating service providers share a common SSO token or a trusted credential that ensures global sign-on access and also a global logout for exiting them.
Web services are required make use of identities, trust policies and their access privileges information from internal and external partner applications. This mandates a standardized way for sharing identities and policies information among disparate authentication and authorization systems spread across their trust boundaries. With federated identity management, a Web services provider can make its services available securely to their partners by establishing trusted partnerships and sharing their identities and policies. This ensures an authenticated identity to be recognized by partner service endpoints and enables the user associated with that identity to access privileged services across multiple partner services.
Ensuring and demonstrating security interoperability is another core Web services requirement to guarantee that the adopted security mechanisms and countermeasures seamlessly work together during communication. That means the Web service providers and consumers are using standards-based protocols following security interoperability guidelines established by standards organizations (e.g., WS-I). The Web services and their security providers must ensure security interoperability at all levels, including transport-level security, message-level security, and other supporting security infrastructures.
Java technologies for building Web services security
The Java platform is becoming the de facto environment for running multiplatform-supported Web services providers. Since the release J2EE 1.4, the Java EE platform allows development and deployment of Web services by enabling J2EE components to participate in Web services. Today there is a long list of technology vendors that provide Java-based infrastructure solutions for delivering Web services. The current Java EE5 platform includes Java WSDP (JWSDP), which is a full-fledged Web services environment. JWSDP includes XML Web Services Security (XWSS), which is a security framework that provides support for key XML security standard initiatives such as XML Encryption, XML Digital Signature, WS-Security, WSS SAMLTokenProfile and WS-I Basic Security profile. Many technology vendors and open-source efforts (such as Apache Axis) provide Java API solutions for building Web services security.
XML firewall appliances
XML firewall appliances are becoming a popular way to facilitate high-performance Web services security solutions. They are hardware appliances that reside in the DMZ behind network firewall appliances and operate on the inbound and outbound XML traffic of a Web services provider or requester. These appliances help identify XML content-level threats and vulnerabilities based on message compliance, payload and attachments that are not detected by traditional network firewalls. In addition, XML firewalls offer functionalities that support XML encryption, digital signatures, schema validation, access control and SSL communication.
An XML firewall appliance is often recommended to run XML security processing at wire speeds while comparing to that of the traditional software infrastructure. XML firewalls deliver significant performance gains in Web-services transactions that involve SSL communication, XML filtering, XML schema and message validation, signature validation, decryption, XML parsing and transformation. There is a growing list of XML-aware security appliances available, including XML firewalls and XML processing accelerators. It is worth noting that some security hardware vendors provide support for Web services security standards and specifications.
About the author: Ramesh Nagappan, CISSP, is a Java Technology Architect at Sun Microsystems who specializes in Java distributed computing architectures for mission-critical enterprise applications, Identity assurance and Access Management. Ramesh is the co-author of Core Security Patterns and also three other books on topics related to J2EE, EAI and Web Services. He frequently speaks at industry conferences related to Java, XML and Security. His current technology focus is on Web services security, identity assurance and strong authentication technologies using PKI, smart cards and biometrics.