Market Analysis for Infrastructure Software from Lustratus Research Limited

SOA security exposure?

Published June 7, 2007 | By Steve Craggs

I was talking to my colleague, Dr. Ronan Bradley, the other day and I suddenly got worried about a potential SOA security hole.

As we all know, SOA systems tend to operate with XML data streams, for example when invoking web services. XML is a self-defining mechanism for data, with pointers and references to ensure the data format can be understood by anyone else. However, it is possible to cross-refer to different parts of the XML stream in such a way that the process becomes recursive. In other words, the parsing process to decode the XML information will loop.

My concern here is that this might offer an opportunity for a Denial of Service (DoS) attack. That is, a malicious party might deliberately send a message containing recursive XML, in the hope of causing the XML parser to loop, thereby blocking any other activity. I am not technically up-to-date enough on the various parsers available in the industry to know for sure, but if the parser does not have some sort of fail-safe then this form of attack would definitely seem to be possible.

The standard way to protect systems from outside attack in the case of the internet is to have a security ‘sniffer’ at the boundary of the enterprise that watches incoming data and looks for threat signatures – that is, characteristics that occur in known threats and threat types. But the problem with the XML thing is that the only way to see if the XML is recursive is to parse it, thereby running in to the problem.

Perhaps this is old news, and the industry has already sorted the problem – but if it has, neither I nor my colleagues are aware of it. It is at least worth SOA adopters, and web services users for that matter, assuring themselves that they are protected from this potential SOA security exposure.

Steve

Posted in Imported, SOA

3 Responses to SOA security exposure?

Ronan Bradley says:

June 7, 2007 at 2:09 pm

Steve raised an interesting point – most discussion around XML on the network focuses on the problem of network overloading due to the typically larger size of XML messages. In comparison, security issues such as the risk of DoS have been (relatively) ignored. The lack of general interest in the problem can be seen in the repositioning of most of the XML firewall vendors into XML acceleration (Vordel – http://www.vordel.com being one notable exception).
The first question is why has it been ignored? Clearly the existence of XML firewall products shows it hasn’t been entirely ignored and a quick search throws up some discussion of the issues (http://lists.xml.org/archives/xml-dev/200508/msg00150.html) but it has never really made it into mainstream thinking. I suspect that this partly related to the close connection between html and XML which leads people to assume that if you cover one, you cover the other one as well. While the risk can be dealt with by taking each incoming document and validating it against well-defined schemas that do not allow rogue documents capable of infinite recursion. However, the complexity inherent in many XML schema (take a look at XBRL for financial reporting or FpML for financial derivatives) inevitably increases the chance of deficiencies in the schema definitions (assuming that the schema designer was even aware of the risk in the first place).
The second question is does it matter? I suspect that the main defence at the moment is probably ignorance – which as any security consultant will tell you – is no defence. And as SOA drives up the number of XML messages being sent around the enterprise the level of exposure is likely to increase. The solution is really two-fold: Implement good policy around schema definition and enforce good policy around document validation.
Ronan
Anil John says:

July 4, 2007 at 10:02 pm

Defending against schema poisoning attacks, as you noted, as well as XML DoS attacks are precisely how a properly configured XML Security Gateway deployed as a centralized Policy Enforcement Point in your perimeter network should be used.
Steve Craggs says:

July 5, 2007 at 9:43 am

Agreed, Anil.
and thanks for the information.
My point is that I think people are using SOA without realising that they need to make sure the appropriate security measures and configurations are in place.
Steve