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 ""
>
> 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
>
>
>
>
> 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.
<xmlform:input type="text"/>
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