cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geissel, Adrian" <adrian.geis...@ecb.int>
Subject RE: [RT] Towards a new/another Forms Framework
Date Wed, 02 Apr 2003 14:32:10 GMT
What I was thinking of was vulnerability to a potential hack attempt. Such
vulnerability can take many forms, ranging from buffer-overruns to
inconsistent record data. I am not an expert on web-security, but know that
providing a solid data-validation boundary is a good first step in securing
my applications.

I appreciate that for _normal_ users, the duplication is superfluous, but
for a live application with external access, the regular data submission
cannot be assumed. HTML forms are much too easy to hack.

What I was getting at was that a generic (and presumably easy to use) forms
framework will be used in a wide variety of situations and if it only relies
on client-side validation, it is exposing a potential security weakness. I
feel that if this can be designed-out, then that would be much better.

Subsequent inspiration: although most population browsers now support some
version of JavaScript (the presumed client-side validator), a server-side
validation would allow for broader (and backward-compatible - real-worlder
:( ) browser support (and possibly lighter devices as well).

/Adrian


-----Original Message-----
From: Robert Koberg [mailto:rob@koberg.com]
Sent: Wednesday 02 April 2003 16:17
To: cocoon-dev@xml.apache.org
Subject: RE: [RT] Towards a new/another Forms Framework


Hi,

Thanks for your comments. What is an example of something dangerous? 

During a preview view, the submitter would not be able to access the file,
but through the CMS tool, which would perform a server-side transformation
on the XML (or fail). How could some dangerous content piece be used in this
situation?

During an editing view the file is sent to the client from a request to
simply return the file. How would this be potentially dangerous?

The file is in no way accessible from the outside. It is only accessible
through the tool by an authorized member of a group. The group lives in a
chroot jail.

Sorry if I am showing some basic naivete!

-Rob


> -----Original Message-----
> From: Geissel, Adrian [mailto:adrian.geissel@ecb.int]
> Sent: Wednesday, April 02, 2003 5:51 AM

> Hi,
> I've been watching this thread for a while now, and as a regular Cocoon
> power-user, I am keen to see a good forms framework. Rob's comments have
> prompted an important consideration for such a framework.
> 
> Where client-side validation is used, it *must* be matched but a second-
> pass
> server side. This is fundamental to security (also on another thread) -
> otherwise anyone can hack a HTML form to submit potentially dangerous
> content to the server. JavaScript (or similar) should be seen as a
> usability
> enhancement, not as the defacto solution.
> 
> One other [R]Thought regarding a X??Form framework is that data-form-
> layout
> separation needs to be considered. I am concerned with the way that XForms
> is integrated into the HTML - relatively poor SoC :( But thankfully
> nothing
> a good stylesheet can't cure!
> 
> FWIW
> /Adrian
> 
> -----Original Message-----
> From: Robert Koberg [mailto:rob@koberg.com]
> Sent: Wednesday 02 April 2003 15:27
> 
> Hi,
> 
> > -----Original Message-----
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > Sent: Wednesday, April 02, 2003 3:25 AM
> > To: cocoon-dev@xml.apache.org
> 
> 
> > But I also want to point out something that I'll need a lot in the
> > future: the XML datatype in a form.
> >
> > I would like to be able to submit an entire XML island into a form
> > textarea and have the server-side form handler be able to validate it
> > against a particular schema.
> 
> But that would be invalid markup. It would be better to use a PUT (I am
> still using a POST with a hidden INPUT...). We do the XML Schema
> validation
> client-side and just send the updated XML back to the server for storage.
> 
> >
> > That would be *KILLER* for serious content management solutions where
> > all the data aggregation from the document can be done via javascript on
> > the client side directly (and it's pretty dead easy also to make
> > transparently portable for 6th generation browsers!).
> 
> I am confused. In the previous paragraph you say you want to submit it to
> the server for validation. But in the above para you talk about client-
> side
> validation?
> 
> Why not use some schema dialect (XML Schema seems to have achieved
> critical
> mass???) and add a form namespace that indicates the widgets. You get
> datatyping for free.
> 
> ?
> -Rob



Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither
be binding nor construed as constituting a commitment by the ECB except where provided for
in a written agreement.
This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised
disclosure, use or dissemination, either in whole or in part, is prohibited.
If you have received this e-mail in error, please notify the sender immediately via e-mail
and delete this e-mail from your system.


Mime
View raw message