Default values in XML Schema - why should we bother?

Hi all,

as the default elements/attributes issue of XML Schema turned out to be
a stumbling stone, I checked the XML Schema spec to see what problems we
might face.

Default attributes:
A Schema may declare a default value for an attribute. If that attribute
is not present in the XML document to be validated, a validating parser
will add the attribute with the default value. If the attribute was
present already, it is not modified.

Default elements:
A Schema may declare a default value for an element. If that element is
*not present* in the XML document to be validated, it is *not* added to
the doument. If the element *is present* in the XML document to be
validated, but does *not* have a text content, *that text content* is
set to the default element's value from the XML Schema. If the XML
document to be validated already contains that element with a text
content, that content is kept unmodified.

Hence, using an XML Schema can only result in adding an attribute or
text node that was not present before. I found no other defaulting
option (so there seems to be *no way* to add element nodes themselves).

Why should we bother?

If signature application, verification, and processing all stick to the
same approach (i.e. either all or none of them validates XML Schema) we
are fine. However, if---for the sake of a bad example---only the
processing logic does validation, but neither signature application nor
validation, an attacker is capable of setting such default values that
appear to have been signed to the processing logic. Depending on the
scenario, this may have severe impacts (e.g. think of setting
soap:actor="somebodyElse" or some:dataHasBeenVerified="true" as defaults.).

However, all of these attack vectors rely on that the attacker is
capable of modifying the XML Schema used for validation at the
recipient's side. I'm not sure it is possible to embed a full XML Schema
e.g. in a SOAP message and convince the recipient to use that one for
validation. Maybe we should put a short text regarding this in the best
practices document?

best regards

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. IC 4/150
D-44780 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// www.nds.rub.de

Received on Wednesday, 5 May 2010 10:28:01 UTC