R307 – An XML value has not been assigned from FIELDVALUE (WMB)

An XML value has not been assigned from FIELDVALUE (WMB)

XML Field Referencing:
The following guidance is now accepted as mandatory when working with XML. The issues highlighted here are risk-based – they may never occur within your organisation, though they are known to be an issue with certain industry standard performance testing tools. Complete mitigation results in code that is aesthetically compromised.

References to XML structures are exposed to an IIB vulnerability that is not commonly understood. IIB allows a developer to be “lazy” / implicit with regards to field type references. You do not have to be explicit about the type of field you are referencing, be it an element or an attribute etcetera.

This can lead to unexpected processing issues when a new tool or application is introduced. See the worked example below.

Consider this XML excerpt…
<sampleStructure>
<elementA>hello</elementA>
<elementB>world</elementB>
</sampleStructure>

Consider the following anonymous field references using the XML excerpt above:
inRef.sampleStructure.[1] inRef.sampleStructure.[<] inRef.sampleStructure.[>]

A reference to the first-child of “sampleStructure” should point to “elementA”, similar assertions can be made for the other anonymous field references above.

Consider also the following field references:
inRef.sampleStructure.elementA
inRef.sampleStructure.elementB

You might, correctly, expect these field references to return the values “hello” and “world” respectively.

Now consider this XML excerpt…
<sampleStructure xmlns=””>
<elementA xmlns=””>hello</elementA>
<elementB xmlns=””>world</elementB>
</sampleStructure>

Some applications add default namespace attributes to all XML elements, even those without a namespace defined, hence “”. This revised excerpt is 100% equivalent to the excerpt above and a perfectly valid, though arguably a little odd / an inefficient, alternative.

Now reconsider the field references reviewed above. Not all of them will return the same result:
• Some will latch onto the attribute / attribute value rather than the element / element value
• Some, if used to copy an element value to a new target destination, will take the attribute as well as the element value, whereas previously only the element value would be copied across

Either of these alternative behaviours could cause Message Flow operations to fail unexpectedly, the supplier of the alternative XML cannot be blamed – the XML is valid, and they may have no choice regarding the format / style of XML that is used.

All of the ESQL field references above are commonly used to reference XML structures, but all of them are vulnerable because they are not explicit about what they refer to / what is required.

Where an anonymous ESQL field reference is used to refer to an XML element – be explicit regarding the field type required.

For example:
inRef.sampleStructure.(XMLNSC.Attribute)[1] inRef.sampleStructure.(XMLNSC.Field)[1]

Where an ESQL field reference is used to refer to an XML element value, be explicit that this is the case.

For example:
FIELDVALUE(inRef.sampleStructure.elementA) (element value only)
inRef.sampleStructure.elementA (whole element / structure)

These examples might be useful:

https://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/ac67241_.htm
https://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/ak05141_.htm
https://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/ac67193_.htm