[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-user
Subject:    RE: escaping xml characters
From:       "Jeff Schnitzer" <jeff () infohazard ! org>
Date:       2002-05-31 23:00:05
[Download RAW message or body]

> From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
> 
> On 5/31/02 5:47 PM, "Jeff Schnitzer" <jeff@infohazard.org> wrote:
> 
> > IMHO, *no* solution which requires explicit effort by template
designers
> > is appropriate.  In order to be safe, XML escaping must be implicit.
> 
> Didn't you suggest explicitness in your first post?
> 
> Oh - that was just the thing to turn it off...

Right :-)

Basically, I think people who use Velocity to build predominantly
XML-like documents will want xml escaping to default to on.  People who
build predominantly text-like (code generators, etc) will want escaping
off.

> You are vulnerable to this if you take form data from people and don't
> check
> it, right?

Form data is just one possible (and most likely malicious) source.  Data
comes from all over the place, from EDI systems to GUI clients to direct
database imports.

> Someone is going to argue that you might want to check the data on the
way
> in...

Cross-site-scripting vulnerabilities are specific to the nature of
presenting XML data, and thus should be addressed in the XML-based
presentation system.  If you try to massage data on the way in, people
using Swing clients are going to be very puzzled by all the '&lt;' junk
in their listboxes.  Data interchange systems may just break entirely.

I hope this is convincing:  Data should not be stored in a format that
is web-specific.  It's just not appropriate for an N-tiered environment.
It's also almost impossible to guarantee - sure, you can filter web
forms, but what about all the other sources of data input... rich
clients, database imports, etc.

Also, what are you going to do if some future version of XML/HTML adds
additional characters which need to be escaped?  Reprocess your entire
database?  It sounds implausible now, but on a timeline of 50 years?
Software changes, but data lives forever.

> If you are going to take the side of security on this one (a side I
> empathize with) *and* suggest it has to be foolproof to ensure those
of us
> doing output design that don't understand all the vulnerablities (like
me)
> don't make a mistake, then I think you can't also demand the  $:woogie
> bypass (or whatever the syntax.)

I have found that (when working with XMLish data) while cases where XML
escaping needs to be off are rare, they do exist.  Sometimes you have a
string that you *know* contains XML data.  It's not as common as
"normal" strings, they must be accommodated...

I think it's ok to turn the "safety" off, but template designers should
have to do it explicitly.  This is the route that JSTL and Struts took,
and I think it makes sense.

> First, patches always welcome.

I'll start working on this next week (after the Maverick 2.1 release :-)

> Second, I've been thinking about this one all day. A few thoughts :

Yup, the case of $foo.blah.bar() definitely needs to be handled.  A
custom context wouldn't be enough...

Thinking about the syntax, how about something like this:

$woogie:noescapexml,optionfoo,optionbar

And then options would have a shell/vi-like format (clobber vs noclobber
kind of thing).  Other options could be "quiet" for those that don't
like the (somewhat cryptic) ! syntax... what else?

Of course, this is not strictly backwards-compatible...

Jeff Schnitzer
jeff@infohazard.org

--
To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>

[prev in list] [next in list] [prev in thread] [next in thread]