[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Extra headaches of securing XML

• To: Rich Salz <rsalz@d...>
• Subject: Re: Extra headaches of securing XML
• From: Bob Foster <bob@o...>
• Date: Tue, 30 Mar 2004 14:06:25 -0600
• Cc: Tim Bray <tbray@t...>,"Bullard, Claude L (Len)" <clbullar@i...>,"'Hunsberger, Peter'" <Peter.Hunsberger@s...>,xml-dev@l..., Gerben Rampaart <VisualBasic@H...>
• In-reply-to: <4069B802.9050302@d...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE03F9F547@h...> <B264C3DB-8272-11D8-A66F-000A95A51C9E@t...> <4069B802.9050302@d...>
• User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

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

• References:
  • RE: Extra headaches of securing XML
    • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • Re: Extra headaches of securing XML
    • From: Tim Bray <tbray@t...>
  • Re: Extra headaches of securing XML
    • From: Rich Salz <rsalz@d...>

• Prev by Date: SAX2: When to resolve System Ids
• Next by Date: xml databases
• Previous by thread: Re: Extra headaches of securing XML
• Next by thread: Re: Extra headaches of securing XML
• Index(es):
  • Date
  • Thread