Content area
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 "xsdistring" 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.
Full text
Think your Web services environment is safe? Think again. XML-based Web services are subject to the same malicious attacks that exploit XML. With XML increasingly becoming the lingua franca for online business transactions, the threat of these attacks intensifies.
The popular Web Services Security (WSS) 1.0 standard addresses authentication and authorization, but not SQL Injection and other attacks. The three basic threats to Web services and XML are conventional identity-based attacks, malicious content attacks and operational attacks.
Identity-based attacks are germane to any exchange over HTTP. Although Web services aren't restricted to riding atop HTTP, most SOAP (Simple Object Access Protocol) traffic is implemented this way. WSS 1.0 provides a set of authentication and authorization standards for preventing conventional identity attacks.
Existing XML security-focused standards, such as XML-Encryption and XML-Signature, secure against these attacks at the application layer. Transport layer security-SSL for HTTP and TLS for SMTP-can alleviate the potential for eavesdropping. But Web services can't rely on these methods because they sometimes require a SOAP intermediary node to process the document before forwarding it to the endpoint. As with intrusion-detection systems and load balancers, transport-layer encryption interrupts these devices, so it can't function as your total security solution. Encryption services and identity verification must occur at the application layer.
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," page 79).
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 on page 63). So it's up to the security gateways, sitting at the edge of the network, to prevent malicious attacks.
An Ounce of Prevention
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," page 80).
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 "xsdistring" 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," below).
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]. Post a comment or question on this story at www.nwc.com/go/ask.html.
Copyright CMP Media LLC Jun 10, 2004