XOM API for Processing XML with Java

[Wolfgang Hoschek <wolfgang.hoschek AT mac.com>]

On Dec 12, 2006, at 10:30 AM, Elliotte Harold wrote:

> Wolfgang Hoschek wrote:
> > Whitelisting  (conservatively preventing a feature such as CDATA  
> > unless it's  explicitly known to be secure) may be excessive in  
> > one risk  management situation and prudent in another. Your  
> > mileage may vary.
>
> While I accept your point about different code paths for CDATA that  
> might have different buffer overflows, I do not believe it is ever  
> reasonable for a security department to attempt to black list  
> particular code paths, absent a a demonstrated threat.

It's the equivalent of "all incoming ports closed by default", a  
successful strategy, it appears.

> Taken to its logical conclusion, this would involve inspecting each  
> if statement, and ruling in some paths through the application and  
> ruling out others. This is simply ridiculous.
>
> There are a few domains in which security is so important that only  
> carefully vetted code is allowed in, and indeed every line of the  
> code is checked. Possibly you even work in one such. However, there  
> are very few of these environments. For instance, I don't think any  
> installation that uses Microsoft Windows would qualify as such  
> under an honest assessment.
>
> In such an environment, you might choose to reject a particular  
> library such as XOM or Xerces. You might even choose to reject XML  
> completely if none of your fully-vetted applications could handle  
> it. However you still wouldn't sensibly choose to allow XML without  
> CDATA sections and forbid XML with CDATA sections unless you knew  
> of a specific attack.
>
> Ruling out particular code paths because *maybe* they have an  
> unknown buffer overflow or other critical security flaw is too  
> extreme. That standard would require us to eliminate all code  
> paths. It is simply too hard and perhaps impossible to prove that  
> *any* code path does not have such a flaw. *Every* code path fails  
> to meet this standard.
>
> Whitelisting is properly done at the library and application level,  
> not at the code path level.

It's often unrealistic to carefully vet code, yes. Now, the overall  
complexity of a system tends to be a useful estimator for the number  
of flaws. Less complex systems tends to have a lower probability of  
flaws, at all levels of granularity, including app, library and code  
path level. Throwing away nonessential stuff tends to improve  
security. CDATA could be considered nonessential. John, yes, if  
necessary, one could appply that kind of reasoning also to attributes  
and namespaces et al...

Wolfgang.