Best Practices: avoid descendants!

Regarding my Action-643 and ISSUE-212 I drafted a new Best Practices
paragraph, to insert between 2.1.3 and 2.1.4:

========================================
2.1.4 Example: XPath selection that causes denial of service in
streaming mode

When an XML Signature is to be verified in streaming mode, additional
denial of service attack vectors occur. As an example, consider the
following XPath expression that is conforming to the [XML Signature
Streaming Profile of XPath 1.0]: "//A//B". This XPath is intended to
select every occurrence of <B> elements in the document that have an <A>
element ancestor. Hence, on streaming parsing the document, every
occurrence of an <A> element will trigger a new search context for the
subsequent <B> element. Thus, an attacker may modify the XML document
itself to contain lots of nested <A> elements, i.e.
"<A><A><A><A><A><A><A><A><A><A>....". This will result in n search
contexts, with n being the number of <A> elements in the document, and
hence in O(n^2) comparisons in total. Even worse, if an attacker also
manages to tamper the XPath expression used for selection itself, he can
trigger an even more rapid Denial of Service: an XPath of
"//A//A//A//A//A..." causes the number of search contexts to explode to
O(2^n).

Hence, besides following Best Practice 1, it is strongly recommended to
reduce the use of "wildcard" XPath axes (such as "descendant",
"following" etc.) in XML Signatures to a minimum.

------------------------------
Best Practice 6: Avoid using the "descendant", "descendant-or-self",
"following-sibling", and "following" axes when using streaming XPaths.

The evaluation of such "wildcard" axes may cause an excessive number of
evaluation contexts being triggered concurrently when using a
streaming-based XPath evaluation engine. Since this may lead to Denial
of Service, it is essential that an attacker can not alter the XPaths
prior to evaluation (see Best Practice 1), and that the valid XPath
expressions reduce the use of these axes to a mimimum.
------------------------------
========================================

This should close my Action-643.

cheers

Meiko

-- 
Dipl.-Inf. Meiko Jensen
Chair for Network and Data Security 
Horst Görtz Institute for IT-Security 
Ruhr University Bochum, Germany
_____________________________
Universitätsstr. 150, Geb. ID 2/411
D-44801 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// www.nds.rub.de

Received on Monday, 6 September 2010 14:58:44 UTC