- Public Key Encryption
- XML Security Standards
- Digital Signatures
- The XML Encryption Standard
- XML and Web Services Attacks
- Forewarned Is Forearmed
- Summary
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
XML and Web Services Attacks
Understanding how to work with encryption technologies to do message validation, guarantee authenticity, and keep things secret is necessary but not sufficient in the wild world of the Web. Many people out there in Web land are trolling for data and happy to bring servers to their knees with denial-of-service (DoS) attacks (also known as distributed denial-of-service, or DDoS). A typical DoS attack is carried out by flooding a server with more requests and/or data than it can handle. Most commercial servers have defenses in place to guard against DoS attacks. However, the increasing popularity of XML in the payload of an HTTP web request opens up new opportunities for enterprising attackers. To give you a sense of how XML adds new twists to some common attacks, let’s look at several network attacks that target XML and its processing model.
The Oversized Payload Attack
When using a web form for online ordering, form data is sent to the server as part of an HTTP packet. Early on, hackers learned that, by programmatically loading web forms with megabytes of bogus data, they could force a server to run out of memory. One fix for DoS attacks is to monitor the size of incoming packets and drop the packet if size exceeds some predefined limit, before data is committed to memory. For most servers, this expected limit can be set at some moderate level, as most forms typically don’t deliver significant quantities of data.
With XML, though, it’s a new game. XML files can be huge, often in the megabyte range. And, while HTTP requests are not expected to be large, XML files are. This situation creates new opportunities for hackers looking to engage in denial-of-service attacks for the "pure joy" of slash and burn. For a server trafficking in XML, it’s difficult to tell whether a large incoming XML file is legitimate or represents a hacker trying to bring down the server.
To combat this type of attack, network management needs to be informed about XML application requirements and adjust network defenses accordingly. If large payloads are expected, it may be possible to configure the server to allow large data transfers only from trusted IP addresses, thus limiting the ability of attackers to deny service.
The DOM Parser Attacks
A variant of the DoS attack is the DOM parser attack, which targets DOM parsers by forcing them to construct extraordinarily large DOM trees in memory. If the tree exceeds memory capacity, the DOM parser will crash, perhaps bringing the server down with it.
An interesting variant of this attack is the DOM deep element attack, based on the fact that well-formed XML has no predefined limit on element nesting. With XML, it’s possible to write perfectly well-formed XML two elements deep or thousands of elements deep. While deeply nested XML is not the norm, it does provide an attacker with an opportunity to stress-test parsers by forcing the creation of an extraordinarily deep DOM tree whose construction may crash both parser and server. The best defense for all these "size attacks" is to keep network management apprised of the nature of your XML applications.
External Entity Attack
Entities allow us to define text substitutions for reuse in multiple documents. Entity definitions may be defined internally or referenced through an external URI. In an external entity attack, the attacker gains control over the external entity file, allowing substitution of his entities for yours. Depending on the application, this substitution can create serious problems, since the XML, even if sent over a secure channel, will be compromised by malicious entity data stored on the server over which the attacker has gained control.
Web Services Attacks
Web services provide additional opportunities for hackers. SOAP and WSDL, while powerful tools for the enterprise, present new attack possibilities, including WSDL scanning and parameter tampering.
WSDL Scanning
The Web Services Description Language (WSDL) allows a web service to advertise its capabilities by describing operations and parameters needed to access the service. As discussed in step 5 of this series, WSDL is often generated automatically, using utilities such as Java2WSDL, which takes a class or interface and builds a WSDL file in which interface methods are exposed as web services.
Because WSDL generation often is automated, enterprising hackers can use WSDL to gain insight into the both public and private services. For example, an organization converting legacy application functionality to a web services framework may inadvertently pass interfaces not intended for public consumption to a WSDL generation tool. The result will be SOAP interfaces that give access to private methods.
Another, more subtle WSDL attack occurs when an enterprising attacker uses naming conventions to guess the names of unpublished methods that may be available on the server. For example, a service that offers a stock quote and trading service may publish query methods such as requestStockQuote in its WSDL. However, similar unpublished methods may be available on the server but not listed in the WSDL, such as executeStockQuote. A persistent hacker with time and a library of words and phrases can cycle thru common naming conventions (get, set, update, modify, and so on) to discover unpublished application programming interfaces that open doors into private data and functionality.
Parameter Tampering
Both REST-based and SOAP-based web services use parameters that affect how a server responds to requests. Instructions on how to use parameters are explicit in a WSDL document. These descriptors give a malicious user the opportunity to experiment with various parameter values as a means to gain insight into how the application responds. After studying the application, it may be possible to acquire unauthorized data or gain unauthorized access. For example, submitting special characters or unexpected content to a web service can cause a denial-of-service condition or provide illegal access to database records.