>> > As you say - it's crucicial. I think we should force this in any way.
>>
>> I can't think of a one-size-fits-all solution. There are areas where
>> input validation is impossible and unnessary, too.
>
> What areas do you have in mind? I could think of the whole webapp/forms
> area. Anything else?
I for one would prefer not to have it "forced" on us. We use EJB's that use
prepared calls, the front end has standardized error pages. We count on
being able to access all request parameters unadulterated. We've got enough
heavy lifting that I don't want any additional overhead.
> That way is ok. But it doesn't really *enforce* security. It will just
> give user that are already aware of the security hazards an easy way of
> securing their system.
> But IMHO that's the not the best way. We should enforce security as
> default and only explicitly remove it for certain cases. But as you
> said: it's really hard to come up with an over-all-solution that also
> holds the balance between additional work and additional security.
Making it optional would be ok, but somehow this seems to beg a larger
architectural (almost philosophical) question: to what extent can Cocoon
enforce security of any kind? At some point any developer using any tool to
build any application has to become aware of the best practices for security
for their particular domain...
> Another option would be to add a new method to our request where you can
> specify one or more filters:
>
> String p = request.getParameter("id","id-filter");
>
> So filtering would be very easy and as close as possible to the request
> but not really forced - it would be an option we should document and
> promote very well.
This is a complex area. It seems a start, but there are other attacks that
such an approach doesn't help.
Let me give a only slightly artificial example; we build databases for
medical information these are subject to all kinds of government
requirements for privacy and security (FDA, HIPPA etc.). This means that in
some circumstances a researcher may not be able to know the identity of a
patient that he is studying. However, our patient population for certain
diseases is so small that if you can determine just a few unique identifiers
then you can determine the identify of the patient. For example, zip code
and year of birth might be sufficient. Thus, for us, security means not
just filtering certain request parameters but also filtering certain
combinations of searches in conjunction with each other. In theory we should
"remember" if a user has ever done a search to reveal a certain number of
unique identifiers and not allow any more searches that would reveal another
unique identifier when a certain threshold is reached. In this example, the
researcher might be allowed to do the geographic search for all patients
having the given disease, but they would not then be allowed to do the
demographic search for all patients in a certain age range.
We obviously cannot write such logic as simple input parameter scanning. We
need to know complete histories of usage patterns, we need to understand
statistical trends and we need to know what privacy waivers apply for any
given query. This is obviously a unique problem domain, but where does our
problem leave off and the problems that an enforced filtering solution would
address begin? I for one think application developers have to be
intelligent enough to have a handle on the issues surrounding their
particular application.
Now, that doesn't mean we can't help them! Generalized filtering
capabilities and generalized validation capabilities for Cocoon seems like a
good idea. However, I think the capabilities need to be very extensible and
very flexible. We've see on the list several discussions on validation and
leveraging DTDs and XML schema. I think we should try and head in that
direction; provide default strongly typed schema for some generally useful
XML standards (in particular XForms!) Build good tools to support
standardized XML handling. Make those tools easy to use. Cocoon specific
types might be necessary for some cases such as quote conversion, but user
defined types shouldn't be a big issue?
Adding yet another bit of semantics and complexity to the sitemap each time
we hit a problem is starting to strike me as a bad way to go. Next thing you
know we'll be promoting having a eXtensible Sitemap Language as a feature of
Cocoon and there will be entire books devoted on just how to write a Cocoon
sitemap (maybe that's not such a bad idea even now :-)...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
