Just the fact that XML is used opens this up to a lot of attacks. Programmers tend to use XML poorly. Depending on how they've configured the XML library, it may be possible to do something like run JavaScript within the context of the response message. Or, fuzzing responses might find a buffer overflow on the iPhone.
Eh? I've so far not seen an XML parser (or any library) that runs JavaScript. And while buffer overflows are always a possibility in C based software, using a well tested XML parser is probably a better safeguard than hacking your own parsing code, and comparable to using any other parsing library.
Not that there aren't any problems with XML default parser configurations (system entities, the billion laughs), but this is just bogus.
There are some other things that are reasonably likely to cause buffer overflows in the XML-parser-user even if the XML parser is perfect, mostly involving very large numbers of elements (<b><b><b><b><b><b>... etc), a tag with thousands of attributes, tags with very large attributes, etc. XML really does have some characteristics attack vectors. However, I am not aware of anything that doesn't; JSON has very similar vectors, as does any recursively-specified serialization format, and of course we all know the joys of binary specifications and screwing with length headers.
As you quoted, "Programmers tend to use XML poorly", but then, "Programmers tend to use serialization poorly" would work just as well. I've only recently really started internalizing just how much of a minefield serialization is in general and I'm 12 years into my career.
Eh? I've so far not seen an XML parser (or any library) that runs JavaScript. And while buffer overflows are always a possibility in C based software, using a well tested XML parser is probably a better safeguard than hacking your own parsing code, and comparable to using any other parsing library.
Not that there aren't any problems with XML default parser configurations (system entities, the billion laughs), but this is just bogus.