XML attacks

XML XDoS attacks

• recursive payload
  
• attribute explosion
  
• dangling XML

The only thing we've run into are the DoS attacks, and those were resolved by coding in a timestamp

SOAP and XML Web services are liable to:

• cross-site scripting vulnerabilities,
  
• cookie poisoning attacks and
  
• changes to URL parameters.

"XDoS attacks are DTD [document type definitions] external entity attacks," O'Neill said. "They rely on an XML parser supporting DTD. They're generally called SOAP bombs. They expand hugely."

XML can expose data contained in Web services messages, and attackers can use available inspection tools to their advantage

The modular nature of XML allows elements, like large attachments, to be embedded in Web services requests.

The WSDL itself may expose structure such as file directories or open ports of a server

Schema not reflecting business rules.

• Integers that are not constrained to positive values when they logically should be
• Sequence numbers that don't increment
• Contamination of stored data or DOSes
• No robust set of validations - usually "this node is a string", which is insufficient.
• Adding additional nodes or the same node (YMMV as to *which* node will be selected in XPath queries for a given XML parser)
• Insufficient validation, leads to inject bad strings with impunity (i.e. javascript)
• Validation is rarely turned on, and even it is ... how many times has the DTD not been available to the XML processor?
  

Recursive definitions of elements are a security risk. This causes reduction of performance and complication in the implementation of validation runtimes, especially when implemented in hardware. Ability to restrict the recursion depth, either locally for a given element or globally could prevent potential security attacks.

Another issue is validating canonicalized version of XML messages, where the XML Schemas was written for the non-canonical form of the XML message.

In XML Schema 1.0, we cannot define or restrict the values of datatypes based on some condition. For example, attribute 'a' in element 'x' can have values < 10 when element 'y' has and attribute 'b' = 3.

As schemas are auto generated, support for multiple targetNamespaces in a single schema, without using imports, could be a great addition. We always ran into the issue of applying a schema to a part of the message.

Most of the times, schemas do not define facets, such as maxLength, on the datatypes. This causes security concerns such as denial of service attacks. Users should be made aware of their benefits and the XML Schema could have support for parameters/policys for such facets that have global effects across all datatypes in a schema (even though proper usage of inheritance does address this).




In the grand security schematic, an external Web service call should enter through an XML security gateway for vetting, be passed to the Web services manager for policy adherence and distributed to the host system Web services via the agents provided by the management tool.

Powered by ScribeFire.