--- Torsten Curdt <[EMAIL PROTECTED]> wrote:
> On Wed, 2002-11-06 at 01:00, Carl Mäsak wrote:
> > These are a few things in the "SQL Injection"
> thread that ring true to me
> > (I here take the liberty of rephrasing people's
> opinions in my own words,
> > but try to give due credit to the first one to
> bring up each topic):
> >
> > 1. Functionality for making a pretty secure SQL
> interface in Cocoon
> > already exists today. Using PreparedStatements is
> a good example of this.
> > (Christian Haul)
>
> true - for SQL
Use of request parameters in sitemap and elsewhere
still has holes - for instance, the sitemap ** matcher
allows complete directory traversal IIRC. A pipeline
with a reader ending in ** would allow one to read
../../../../../../../../../../etc/passwd for example.
...
> > 3. SQL Inj:s really is an issue. It's easy to
> write (say) a login script
> > that doesn't check against SQL Injections. (Geoff
> Howard)
The point was that it's a cocoon provided login script
that already has a vulnerability.
>
> we should fix this by using a prepared statement in
> the login action.
right.
>
> > 4. Some users don't want additional protection.
> They are happy with the
> > current level of (lack of) protection, and add
> their own as needed. (Peter
> > Hunsberger)
>
> AFAIU some would also like to have a centralized
> management...
I think the suggestion of overloading
request.getParameter with convenience methods
performing basic type-level validity is really a
strong one. Even better, exposing them in
xsp-request. What would the objections be?
other ideas are:
request.getParameterAsInt
or even
request.getParameter("foo","^[a-zA-Z0-9]$")
I realize this is strictly off the topic of SQL
injection.
Geoff
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
