Submitted by Sridhar Guthula, QuickTree Inc.
I have been working on solutions that enable network equipment like Firewalls, SSL VPN devices and Load Balancers to inspect and secure Web Services traffic.
Web Services communication is typically sent over HTTP. In most networks today, HTTP messages are unchecked by traditional firewalls that operate at the IP layer. This leaves server vulnerable to external attacks and erroneous traffic. At QuickTree, I developed a SOAP Security Module that enables existing network equipment vendor to provide Web Services security.
While working on this project, I realized couple of things:
I want to contribute further to the development of XML Schema and its wider adoption.
Along with my experience with Web Services security, I have ten years of experience in enterprise software development. Since 1998, I have focused my efforts evangelizing XML and related technologies.
Functionality of XML Schema was exploited in implement many features of the security module. Some of these features are:
We needed a mechanism to prevent invalid and corrupt SOAP requests from reaching the server and limit messages to the once defined WSDLs. To achieve this, we developed an application that converted given WSDL into an XML Schema which when applied on the SOAP messages reports messages that do not conform to the WSDL definition.
This feature limits a user's access to particular services or operations defined in the WSDL file. In addition converting WSDL into a XML Schema, our schema runtime had the ability to register callbacks on any element in the XML Schema. This was used to implement ACLs for operations in the WSDL.
Detect and block command injection attacks, commonly hidden as valid parameters. XML Schema facets support for regular expressions was exploited to prevent SQL and Command injection.
As performance is critical for network devices, we had to provide different levels of support for XML Schema. When validation XML messages against XML Schema, we provided options to do only structural validation or structural and data-type validation. This was useful as data-type validation was too much of a performance hit for some applications.
Some of the features if supported either by the XML Schema or the validation engines could have made our development much easier.
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).
These are bunch of other issues that are related to optional flags that could speed up the validation process, by (optionally) relaxing the validation.