[
Lists Home |
Date Index |
Thread Index
]
Rich Salz wrote:
>> and I'd bet a zillion bucks that there are awful vulnerabilities
>> lurking in the cracks where nobody could possibly have thought to
>> look. -Tim
> There are some that are inherent in XML itself: entities for example,
> and the fact that there are no size limits (element name with 1e6
> characters, or 1e6 attributes, or a document 1e6 elements deep). This
> makes XML inherently more "dangerous" than classic binary formats like
> ASN.1/DER.
>
> There are some dangerous corners when you mix and match various XML
> technologies. For example, just because the incoming message
> schema-validates doesn't mean that (a) you have the right schema (does
> your verifier just blindly trust xsi:schemaLocation attributes)?, or (b)
> that it's really secure (does your schema limit xsd:string such that SQL
> injection atttacks are prohibitied).
>
> There are areas to be concerned when exposing (transactional)
> back-office systems to the looser mix of XML and Web technologies,
> causing trade-offs to perhaps be made in the "wrong" direction. Len
> alluded to this in his usual elliptical style. :)
>
> Hope this helps.
It is so much more helpful than FUD. Some are things an XML processor
can actually do something about, e.g., by allowing an application to
impose constraints on incoming documents in addition to those imposed by
XML, by allowing an application to override schema locations, etc.
Others, e.g., preventing SQL injection, must be handled at the
application level, but might benefit from better validation tools.
In some cases, the XML recommendations themselves value interoperability
over robust processing (the ability to gracefully survive both
unintentionally and malevolently malformed documents). Can an
implementation limit the size of identifiers and strings, or the maximum
length of a document? Is it allowed to ignore a SYSTEM id identifying an
external DTD, or to report as errors attempts to redefine declarations
in an external DTD? Fixing the recommendations might take a long time,
might never happen. In the meantime, the community might reconsider its
usual knee-jerk negative reaction to "XML subsets" intended to address
security-related issues.
Discussing these issues out in the open, raising the level of awareness,
is essential to moving the community forward. Most XML processors (or
standards) aren't built by the secret society of "security experts".
Bob Foster
|
