Dive Carefully

The problem is, SSL is not--and should never be considered--a security panacea. Although SSL and similar transport-encryption protocols protect your content in transit, the vulnerabilities against which those protocols protect are not peculiar to Web services. These mechanisms do not begin to address the real insecurities inherent in Web services.

By Invitation Only

Because XML is human-readable, if it's intercepted in transit, it can provide a wealth of information, not only from the data being exchanged, but from the structure of that data. Although both HTML form data and XML comprise name-value pairs, XML is hierarchical and often models an internal database schema, making relationships between the data more readily apparent compared with data encoded in an HTML form. Enabling XML output directly from IIS results in the same vulnerabilities: A schema, and resulting output, are pulled directly from the database and can be used to map tables and columns, giving great insight into the internal workings of your organization.

Most Web services development tools and platforms promise rapid development of services, but do so without worrying about pesky details like, say, the exposure of sensitive corporate structures easily abstracted from the generated WSDL and XML schema necessary to build a Web service.

Also exposed in a Web services architecture are the specific methods, or functions, being called. Generally, the methods documented in the WSDL are pulled from code and rarely obfuscated, as is the case with Web-based form submission. The granularity required by a service-oriented architecture means that your internal business process could be abstracted from its associated application code. An HTML form may pass information back to an application, but the underlying function calls--often meaningfully named--are not exposed.

You may be thinking, what's the big deal? After all, anyone can view the source of an HTML page and find all sorts of goodies that we'd prefer the bad guys not see. Hidden fields are hidden only in the sense that they are not displayed within the browser; they still exist in the page and can be read easily. The submission point for a form must be present in the page and can be extracted from the source without much effort. Cookies are stored as plain text and can be viewed as easily as the source of a Web page.

The big deal is that, in most cases, you won't be able to get at information regarding other functions via a conventional Web-based application because the application ensures that you see only what you're authorized to access. Web services, on the other hand, are regular floozies, serving up every function available--regardless of whether the person on the other end is authorized for access.

Bottom line: Most Web-based applications restrict access proactively, while Web services are reactive. And herein lies the problem. To secure Web services during development, you must fix it so that each and every function performs due diligence to ensure that only authorized access is allowed. Although it's practical and desirable to require your developers to validate user input, validating authorization for every function is not only impractical, but it will degrade performance to the point of making the service unusable.

To provide effective security for Web services, we need to move to a proactive model of authentication and authorization. It's much easier, and safer, to require an invitation at the door than to throw crashers out of the party once they've gotten inside. A proactive model provides a centralized security architecture that is not only easier to manage but also enforces policies consistently across the enterprise. WS-Security and SAML (Security Assertion Markup Language) provide a mechanism for establishing trust between a consumer (client) and a producer (the Web service). Both specifications are flexible and offer myriad options for verifying the credentials of the consumer--user name-password pairs, X.509, e-mail addresses and tokens, as well as digital signatures for identity verification and authorization. Because Web services are open by nature, it is imperative that you require client credentials to be verified and trusted by the Web service. "Integrity is far more important than confidentiality," says Dr. Phillip Hallam-Baker, editor of SAML and co-author of the WS-Security spec. "It's not just the security; it's the trust." Amen.

Some products are capable of deriving user credentials from elements within the XML document. But your method of credential verification is not nearly as important as ensuring that this process is part and parcel of your Web services security strategy. WS-Security is widely supported, as is SAML. In fact, SAML is designated within the WS-Security specification as one method of passing credentials from the consumer to the producer. Because SAML support is offered by a large contingent of identity-management system providers, including Computer Associates, Netegrity, Novell and Oblix, it can be integrated into your infrastructure easily and lets you take advantage of existing infrastructure investments.In addition to validating the credentials of a consumer, producers must validate the document structure against the expected schema. Web services are as vulnerable to data-layer attacks, such as SQL injection, as were their form-based predecessors. Most well-designed XML schemas not only specify the format of the document, but detail the type of data expected. If the schema specifies an integer as the type for an element, for example, only numeric data should be allowed. If the length of string input is designated, documents with nonconforming elements should be rejected. Validation of user input should be a requirement for any application, and Web services are no exception.

If a document, or elements thereof, has been digitally signed, it is further expected that the certificate is validated and a CRL (certificate-revocation list) consulted. If the certificate is not found in a CRL, it is wise to verify the certificate through the chain of issuers, all the way to the CA (certificate authority). Encrypted elements must be decrypted and, again, validated. Once the request has been found to be acceptable, you should use the consumer's credentials to determine whether the client is authorized to access the service and operation being requested. Only then should the request be processed.

Note that validation of input and certificates should be integral steps in secure application development in any Web environment, not just Web services.

The Bodyguards

Securing Web services is a team effort--a dual-pronged attack is needed. A well-designed Web services architecture will include both a single point of entry at the network level and a fine-grained level of control at the service level.A WS-Security gateway, sometimes called an XML gateway, XML firewall or SOAP proxy, can give you the network security features you need to prevent unauthorized access and transport- and application-layer attacks. (We tested these devices in our NWC Inc. labs. Our review, "Enemy at the Gateway," begins here.)

The Web services producer, typically an application server from a vendor such as BEA Systems, IBM, Microsoft or Novell, can provide control over authorization to specific operations based on consumer credentials and the specific data requested or submitted. A WS-Security gateway should provide message-level security, such as for authorizing operations, but there are situations in which this is impractical--for example, when you're securing third-party services. CRM, ERP and HR applications may offer Web services as a method of integration, but they sometimes use internal, proprietary methods of authentication and authorization. In such cases, you should insist that the application provide operation-level authorization.

The producer should also verify the data as it is prepared for processing and that the consumer is authorized to access the operation in question within the supplied parameters. Consider, for example, your Web services-enabled HR system: It's likely that all employees have access to this system, but each employee's right to view data within that system is limited, based on his or her role in the organization. In a Web services scenario, Bob from shipping would be granted access to the "employeeInformation" service and allowed to make a request of the "getSalary" operation, but only for himself.

This two-tiered security architecture is your best bet for Web services for several reasons:

• Performance: Encryption, decryption, signing and verification of signatures are CPU-intensive tasks. Although cryptographic-acceleration hardware from Accelerated Encryption Processing, Broadcom Corp., nCipher and Rainbow Technologies can ease the CPU burden, it's better to perform these tasks at the edge of the network. Doing so provides integration with your other security devices, such as IDSs and load balancers. Also, at the edge, the application server can devote the bulk of its resources to processing requests, and the cost of managing multiple acceleration cards and certificates is alleviated.• Single point of entry: A WS-Security gateway provides not only a single point of entry for Web services into the enterprise, but a single point of policy enforcement across the enterprise, improving consistency in the application of security policies and lowering the cost of management. Auditing and logging also can be consolidated at the gateway, ensuring that requests and responses are tracked accurately. Your integration costs--specifically when taking advantage of third-party identity stores--can be mitigated by the need to integrate only one or two devices, rather than multiple servers across the enterprise.

• Vendor neutrality: Embedding security policies within application logic could tie you to one vendor. By moving security to a separate device, you remove dependence on a specific implementation. This move also offers better interoperability: Because WS-Security gateways must play nicely with a variety of vendor implementations, they are more likely to interoperate and integrate with a variety of Web services and identity-management platforms.

The idea of using an intermediary as a security mechanism is not new. A WS-Security gateway operates on the same principles--and provides the same financial and operational benefits--as other security intermediaries, such as proxies, firewalls and Web application security gateways. But don't be fooled into thinking that these other devices will provide you with the level of security necessary to protect your Web services. None can provide the validation, authentication and authorization features found in a WS-Security gateway.

WS-Security gateways also provide outbound security, a necessity when engaging in B2B endeavors, and can digitally sign and encrypt outbound documents, as well as insert the security headers necessary for automating business processes via Web services. ROI models for security products are always difficult to compute because they are based primarily on the premise that implementation will mitigate risk and the costs associated with it. These are bound to be guesstimates, however, unless you have empirical evidence of the costs associated with specific risk scenarios. As an example, for an organization such as NWC Inc., which uses its Web services as a method of earning revenue, these costs can be closely associated with the effects of an attack or fraud on our revenue stream.

NWC Inc. earns approximately $4,375 per hour through its Web services. If an attack on those services caused downtime of 24 hours, the company would lose roughly $105,000. If the attack were to affect the integrity of its mission-critical databases, as, say, a SQL injection attack can, the cost of the attack would increase with the need to recover the database and bring it back online. If even 1 percent of all orders are fraudulent, we'd lose $230,000 annually. Comparing this with the anticipated cost of a WS-Security gateway shows a quick payback (see chart at left).Fine print: This scenario does not take into account the possibility of regulatory compliance issues, nor does it consider expenses associated with the loss of reputation, legal fees or the multitude of additional costs related to attacks or unauthorized access to data via Web services.

Also, consider the costs associated with implementing a single-tier solution, one in which Web services platforms provide all the security for exposed services. Given the degradation in performance likely to occur due to the additional burden of encryption, signatures and policy enforcement, you'll need to provision at least two servers to provide the same level of performance as a single WS-Security gateway. Factoring in the additional cost of SSL certificates, application software and hardware proves that a WS-Security gateway will provide a measure of cost savings in addition to its security features.

Lori MacVittie is a Network Computing technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].

Post a comment or question on this story.Web Services Security

Given the arcane attack types--including request canonicalization, structure/schema misvalidation, XML External Entities and signed integer comparison attacks--it's no wonder some business-line managers haven't a clue why you go ballistic about casually deployed Web services.You do go ballistic, right?

If you don't, or if you do but you're not sure how to explain it to your co-workers, you've come to the right place. We expose the dark side of Web services, from the inherent insecurity of SOAP and XML to the inability to restrict function access to only authorized users. We also see some light at the end of the tunnel in the form of SAML and the WS-Security standard.

In "Enemy at the Gateway" we test WS-Security-compliant gateways from DataPower Technology, Forum Systems, Reactivity, VeriSign, Westbridge Technology and Xtradyne Technologies. All were integrated into our NWC Inc. applications lab and subjected to tests covering interoperability between .Net and J2EE, performance, encryption at document and subelement levels, XML validation, and authorization and authentication functions.

Although none of these products inspired us to do the happy dance, Forum Systems' Forum Sentry did make us sit up and take notice--and its rivals should pay attention as well: The 1U appliance met most of our expectations, and we'll be keeping our eye on future revs. If this device stays on track, it should grow into the archetype of what we believe a WS-Security gateway should be.Many software components are required to host a SOAP service. And just as with any other computer application, more components mean more lines of code, which means more opportunities for security vulnerabilities. To protect yourself, you must know the probable avenues and methods an attacker may use.

The first path is through the server that implements the transport protocol, be it FTP, SMTP or HTTP. In the case of SOAP, this will be a full-fledged Web server, potentially open to a number of Web server attacks, including buffer and format string overflows, request canonicalization and denial of service.The request is then passed from the Web server to the SOAP application server, though in some cases the application server may implement the Web server component internally. Once the request reaches the application server, another round of attacks is possible. Eventually, the body content of the SOAP request is pushed through an XML parser, which, depending on how the parser is implemented, could fall prey to XML structure attacks, structure/schema misvalidation and other vulnerabilities, such as an XML External Entities (XXE) attack.

Depressed yet?

Once the SOAP XML body content is finally parsed, the data can be interpreted to figure out which SOAP service to invoke and what parameters to pass to it. During this phase an attacker may attempt to invoke services not usually accessible or allowed. Or, an attacker may try to pass service parameter data that is invalid or unexpected. This usually is prevented by validating the attacker's data against the WSDL for the target SOAP service--but the validation can only be as thorough as the WSDL file that describes the service. Some WSDL-generation tools do not produce WSDL files that include security-specific attributes, such as maximum length restrictions on string parameters.

If the WSDL doesn't contain the specifics on how to best secure the SOAP service, the XML firewall could allow malicious data to pass. The WSDL file also cannot describe the specific contents of the actual parameter data, which leads to the last level of exploitation: the SOAP services.

The same gamut of vulnerabilities found in normal CGI/ Web applications still exists, in varying degrees, in SOAP services. All the custom code that actually implements the logic of the SOAP service is vulnerable to attacks, including buffer overflows, signed integer comparison attacks and SQL tampering.