Web Services Security

Malicious content attacks, meanwhile, try to force a SOAP endpoint (server) to do something it wasn't meant to do--such as retrieve data it's not authorized to access, or even destroy data through SQL Injection and manipulate content within a SOAP message. The result: The receiving endpoint consumes excessive resources and crashes or becomes unresponsive.

Operational attacks produce a denial of service. Like malicious content attacks, they typically manipulate the XML message or the schema to tie up server resources.

Token Security

Several standards address application-layer security, which extends to Web services and SOAP:

» XML-Encryption provides full- or partial-message encryption.» XML-Digital Signatures let a sender cryptographically sign messages, which can then be used as authentication credentials or a way to check data integrity.

» XML-Schema can be used to define an XML message's appearance. It also can guard against some content-based attacks, such as buffer overflow and SQL/XQuery Injection.

Both XML-Encryption and XML-Digital Signatures allow for partial message signing and encryption, letting you use SOAP intermediaries, such as management, logging or routing nodes. Because transport-layer security makes intermediate processing difficult if not impossible, you need these standards to protect data within a SOAP message.

WSS, recently ratified by OASIS (Organization for the Advancement of Structured Information Standards), combines several standards for securing SOAP messages. WSS defines two profiles that address authentication and authorization: the UsernameToken Profile and X.509 Certificate Profile. Each provides the same information: an identity that is verifiable by an edge security device or by the application.

The UsernameToken specifies a method for passing a user name along with a security token. The security token is often a password, but it doesn't have to be (even though the tags within the element use the term password). The password can be clear text--in which case the Type value of the Password node is PasswordText--or a hash, indicated by the type PasswordDigest (see "UsernameToken Element in the WSS Header").

The Nonce node is useful for detecting replay attacks and it's Base64-encoded, unless otherwise specified. The Created node is a time stamp showing when the UsernameToken was created.

WSS helps determine whether access to a service is permitted, and it verifies the identity of the requesting user. Web services security gateways from Check Point Software Technologies, DataPower, Forum Systems, Reactivity and Westbridge Technologies all support WSS, as do Web services management products from Actional, Digital Evolution, Infravio and Oblix.

But Web services management products don't protect against malicious attacks. Most provide basic schema validation and sometimes data-scrubbing (see our review of these products in this issue). So it's up to the security gateways, sitting at the edge of the network, to prevent malicious attacks.Limiting access to corporate Web services is the first step in implementing a strong security policy. The second step is understanding the potential vulnerabilities in XML communication so you can protect your Web services environment from them. SQL Injection attacks embedded in an XML message are similar to those embedded in HTML forms or passed via the URI to a Web server. The difference is that XML can be manipulated to cause a server to go into a tailspin.An XML document must be parsed before a server can process it. XML parsers are notoriously CPU- and memory-intensive because the entire XML document must be parsed and stored in memory before it can be passed off to the appropriate service. Each parsed element is also validated to ensure it complies with the associated schema (document format). This is an easy target for an attacker creating a denial-of-service attack or degrading application performance.

Attempting to parse an XML document containing recursive XML entity declarations or large payloads can cause the server to shut down with an out-of-memory error. Or the XML parser can consume a huge amount of CPU time, depending on the XML API that's used.

To prevent this type of attack, preprocess and validate incoming SOAP messages against the expected schema. This includes confirming that data types are consistent and ensuring a minimum/maximum length for all string-based content. A well-defined XML schema provides mechanisms for defining this. Make sure the external security devices and the application can validate incoming data against the specification (see "Restricting Data To Prevent Some Content-Borne Attacks,").

SQL Injection is a common Web application attack, and XML is vulnerable to it as well. Validating your incoming XML documents against XML schema doesn't necessarily prevent this attack. That's because the type "xsd:string" does not preclude special characters and specific SQL keywords that are, after all, of the correct type. To prevent ISO character sets from being exploited, declare the ISO character set you're using for translating Unicode input into ASCII. That way, you'll minimize the chances of a mismatched character set from delivering executable strings through your schema validation filters.So how do you prevent SQL Injection? Further specify the content of each element by using a pattern facet in the schema, or deploy a WSS product that can detect these attacks. A pattern is a regular expression that defines the exact format of a specific data type (see "Defining a Data Type,").

A pattern uses a regular expression to define the allowed format and specific characters for this element. The pattern, which is for a ZIP code, allows five numeric characters and is optionally followed by a dash and four numeric characters.

Web services are here to stay--and so are the attackers and threats. Don't leave security as the last item on your deployment list. Create well-defined schemas early in the Web services development cycle. You can retrofit them later with security gateways, but it makes more sense to implement security from the start. Keep your app servers patched and up to date, too. Putting in place security measures means a little additional work up front, but it can save time, money and a lot of headaches.

Lori MacVittie is a NETWORK COMPUTING senior technology editor working in our Green Bay, Wis., labs. Write to her at [email protected].Coercive Parsing Sending valid but malicious XML documents to a SOAP/XML endpoint so it will consume all its resources.

External Entity Attack Injecting recursive elements, jumbo payloads or XQuery/SQL commands into an otherwise valid document.

Jumbo Payloads These payloads consume resources (memory and CPU) by forcing a parser to examine excessively large XML documents.

Malicious Morphing Manipulating XML documents into a form not intended by the designer.

Recursive Elements Parts of a relatively small XML document that can easily expand to gigabyte-size ranges, forcing the parser to consume all available resources.Routing Detours Routing information inserted into a SOAP message, forcing traffic to be routed through an intermediary before going to its final destination.

Schema Poisoning Modifying an externally referenced schema document.

WSDL Enumeration The Web Services Definition Language is read by an unauthorized client to get information about a Web Services-based organization's operations and schema.

XML Encapsulation System commands embedded into an XML payload to gain remote access using the CDATA tag, which is designed to allow backward compatibility.

XQuery Injection SOAP endpoint is forced to perform unintended functions on an XML document. -- Pete Lindstrom, Spire Security1. Deny by default. It's all about attitude. Because Web services exposes your business' most sensitive assets, apply the tightest security filters possible. That way, if an incoming message's authentication, body, timing or anything else doesn't look quite right, your systems will deny it and send an alert.2. Fine-tune your schema. Ensure that schema definitions have minimum and maximum lengths when possible, and set size limits for incoming documents so oversized payloads don't hog server resources. The extra time spent implementing restrictions may prevent unwanted downtime and those annoying 2 a.m. phone calls.

3. Scrub your data. Implement an external Web Services Security gateway that validates incoming XML documents against a well-defined schema. Enforcing the schema at the edge of your network can alleviate attacks as long as the gateway can accurately detect and prevent SQL Injection and restrict the size of incoming documents.

4. Authenticate. Only allow authenticated users access to servers. A WSS 1.0-compliant product is best, but at a minimum, use HTTP Basic Authorization.

5. Authorize. Only allow authorized access at the operational level. An authenticated user is not necessarily authorized to access every operation. This may require that developers get involved if you don't deploy an external solution.

6. Log, Log, Log. Log incoming messages and implement a management strategy that alerts an administrator when attacks are detected. This is the last resort against attacks; then an attack can be traced and, at a minimum, the offender blocked by source IP at the firewall or security device.0