[
Lists Home |
Date Index |
Thread Index
]
On Thursday, Jun 12, 2003, at 19:32 US/Central, Mayne, Peter wrote:
> I didn't mention it for simplicity, but I would use a string, a loop,
> *and* an xmlEncode() function.
That's a very common approach, but I don't like it. My reason is that
it's much, much too easy to forget the xmlEncode() just once...and
that's enough. This is a specific case of a broader problem of doing
things incorrectly by default. It causes:
- SQL insertion vulnerabilities
- Cross-site scripting vulnerabilities
- Shell execution vulnerabilities (system())
- Shell script problems with spaces/special characters in filenames.
(Apple's original iTunes installer that ate hard drives)
- etc
In each case, there's a fairly simple solution. Respectively:
- Bind variables
- SAX (characters() quotes for you) and similar
- Invoking exec() directly or using a safer wrapper like Perl's
multi-argument version of system
- Using a safer language like Perl/Python/whatever. If you have to put
quotes around every variable reference to keep it from trying to be
overly clever, something's wrong.
I think SAX is really the correct approach. If it's too
difficult/wordy/whatever, there's the option of using something like
XSP, which adds lots of goodness while keeping the correctness. I'm
plugging my software twice today - I've got a project at
http://www.slamb.org/svn/repos/projects/framework/ that does this.
(Warning: very early/buggy release. I'm trying to plug the concept
here; my implementation is not so hot yet.) It's very similar to XSP
without the complication of Apache Cocoon. In other words, a JSP-like
thing with several advantages:
- It gets variable inclusions right _by_default_. If you want to pass
along the XML without escaping, you tell it to parse it and pass the
SAX events. That's not hard, but you have to think about doing that
instead of thinking about doing the other. Much better. The other way,
it's _inevitable_ that you will forget once. Here, it's not. There are
no cross-site scripting vulnerabilities in my messageboard. I'm sure of
it.
- It's essentially an XML document with Java code thrown in and XML
code in that. If your tags aren't balanced, it won't parse. If you
still want to do something really clever (and potentially dangerous),
you can - just deal with the ContentHandler yourself. But the common
stuff is guaranteed to be correct.
- If you are passing the output through an XSLT stylesheet, this way is
more efficient than JSP. Specifically, there's a serialization and
parsing step it skips because its output is a ContentHandler, not a
stream.
- Hmm, other advantages that aren't occurring to me at the moment.
Scott
|
