> > 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?
<snip/>
> > But we encounter this problem (not only SQL related) everywhere. That's now
> > even worse since be provide an easier way to incorporate external variables
> > into the sitemap. That's exactly where the Filter proposal was aiming at!
>
> I agree with you in that validation should be done. As for the filter
> proposal, it is not necessary IMO because you could just implement
> such a filter as input module and stack that on top of others. I've
> recently cleaned up the "meta" module stuff, making it more apparant
> what goes on and how to write additional "meta" modules.
>
> Fictious example:
>
> <component-instance name="my-app-request-param" src="org....MyFilterModule">
> <filter-rule ......>
> <input name="request-param"/>
> </component-instance>
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.
> > We could even filter at Request level! But that's kind of problematic since we
> > the Request has almost a per page page context of what is allowed and what is
> > not.
> >
> > page1.html - request accepts attribute "sid" being a number
> > page2.html - request accepts attribute "aid" being a regexpr [...] (but not
> > sid)
> > ...
> > and even combinations!
>
> One could apply the usage pattern other already use: every pipeline
> starts with the request generator and everything else is done through
> transformations.
...sorry, could you elaborate a bit more. I couldn't think how this
could help.
> > So I that's why I though the InputModules are now the preferred way to include
> > such facility. If every external variable would come from an input module we
> > could easily force security with them.
> >
> > Of course the closer to request the saver it is... since then there is no way
> > around it. But this would need incompatible changes - which most likely a
> > blocker.
>
> What change do you have in mind?
Well, forcing security through input modules is fine as long as they are
easily reachable and used throughout the whole system. Which is not
(yet) the case. Transformers might use the request, logicsheets directly
access the request or XSP pages can access the request. Since we cannot
deny those accesses we could filter them in our HttpRequestWrapper. But
the problem is the configuration of the valid request parameters. They
are only valid for a certain URI space. So probably they should be
defined in the sitemap. (I have not specific syntax in mind yet)
...
<map:match="/">
<map:request-parameter name="id" filter="number"/>
...
So only explicitly defined parameters are available. But this collides
with any more complex form and all form validation approaches we have
yet. As well it adds another layer of complexity which is not very
desirable. It's just plain ugly :-/
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.
What do guys think?
Please don't take all this stuff as a proposal but more as RT!!
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
